{"id":2321,"date":"2019-06-26T10:33:08","date_gmt":"2019-06-26T17:33:08","guid":{"rendered":"http:\/\/devblogs.microsoft.com\/directx\/?p=2321"},"modified":"2019-06-26T10:33:08","modified_gmt":"2019-06-26T17:33:08","slug":"debugger-extension-for-dred","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/directx\/debugger-extension-for-dred\/","title":{"rendered":"Debugger Extension for DRED"},"content":{"rendered":"

Microsoft recently announced<\/a> the release of DRED (Device Removed Extended Data) for D3D12 in the Windows 10 May 2019 Update (previously referred to as the Windows 10 19H1 Preview).\u00a0 Buried in that post is a mention that Microsoft is working on a debugger extension to help simplify post-mortem analysis of DRED.\u00a0 Good news, that debugger extension is now available on GitHub<\/a>.\u00a0 D3DDred.js is a JavaScript debugger extension for WinDbg (available here<\/a>). This extension makes it possible to examine the DRED output with clear context and a human-readable layout.<\/p>\n

Why WinDbg? Besides being a powerful, lightweight debugger, WinDbg supports JavaScript extensions.\u00a0 There is no need to configure build tools or run any installers to use D3DDred.js.\u00a0 Simply load the script into WinDbg and you are ready to roll.\u00a0 Using the WinDbg console, type:<\/p>\n

.scriptload c:\\my-windbg-extensions\\d3ddred.js<\/pre>\n
When a TDR occurs in an app with DRED enabled, the runtime preserves the DRED output in the application memory heap.\u00a0 Using WinDbg attached to a process or heap dump with D3DDred.js loaded, the DRED output can be trivially observed by running !d3ddred from the WinDbg console.<\/p>\n
Example:<\/strong><\/h5>\n
The following is an example using a busted version of Microsoft\u2019s D3D12 ModelViewer sample.<\/p>\n
0:000> !d3ddred\r\n@$d3ddred()\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : [object Object] [Type: D3D12_DEVICE_REMOVED_EXTENDED_DATA1]\r\n\u00a0\u00a0\u00a0 [<Raw View>]\u00a0\u00a0\u00a0\u00a0 [Type: D3D12_DEVICE_REMOVED_EXTENDED_DATA1]\r\n\u00a0\u00a0\u00a0 DeviceRemovedReason : 0x887a0006 (The GPU will not respond to more commands, most likely because of an invalid command passed by the calling applicat [Type: HRESULT]\r\n\u00a0\u00a0\u00a0 AutoBreadcrumbNodes : Count: 1\r\n\u00a0\u00a0\u00a0 PageFaultVA\u00a0\u00a0\u00a0\u00a0\u00a0 : 0x29b450000\r\n\u00a0\u00a0\u00a0 ExistingAllocations : Count: 0\r\n\u00a0\u00a0\u00a0 RecentFreedAllocations : Count: 2<\/pre>\n
In this example, there is only one AutoBreadcrumbNode object.\u00a0 Clicking on AutoBreadcrumbNodes shows:<\/p>\n
(*((ModelViewer!D3D12_DEVICE_REMOVED_EXTENDED_DATA1 *)0x7fffee841a08)).AutoBreadcrumbNodes\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : Count: 1\r\n\u00a0\u00a0\u00a0 [0x0] \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0: 0x1e2ed2dcf58 : [object Object] [Type: D3D12_AUTO_BREADCRUMB_NODE *]<\/pre>\n
Click [0x0]:<\/p>\n
((ModelViewer!D3D12_AUTO_BREADCRUMB_NODE *)0x1e2ed2dcf58) : 0x1e2ed2dcf58 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : [object Object] [Type: D3D12_AUTO_BREADCRUMB_NODE *]\r\n\u00a0\u00a0\u00a0 [<Raw View>]\u00a0\u00a0\u00a0\u00a0 [Type: D3D12_AUTO_BREADCRUMB_NODE]\r\n\u00a0\u00a0\u00a0 CommandListDebugName : 0x1e2eceb04a0 : \"ClearBufferCL\" [Type: wchar_t *]\r\n\u00a0\u00a0\u00a0 CommandQueueDebugName : 0x1e2ecead4a0 : \"CommandListManager::m_CommandQueue\" [Type: wchar_t *]\r\n\u00a0\u00a0\u00a0 NumCompletedAutoBreadcrumbOps : 0x1\r\n\u00a0\u00a0\u00a0 NumAutoBreadcrumbOps : 0x3\r\n\u00a0\u00a0\u00a0 ReverseCompletedOps : [object Object]\r\n\u00a0\u00a0\u00a0 OutstandingOps\u00a0\u00a0 : [object Object<\/pre>\n
This implies that queue \u201cCommandListManager::m_CommandQueue\u201d and command list \u201cClearBufferCL\u201d contain the likely suspect operation.<\/p>\n
The ReverseCompletedOps value is an array (in reverse order) of command list operations that completed without error:<\/p>\n
((ModelViewer!D3D12_AUTO_BREADCRUMB_NODE *)0x1e2ed2dcf58)->ReverseCompletedOps\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : [object Object]\r\n\u00a0\u00a0\u00a0 [0x0]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : D3D12_AUTO_BREADCRUMB_OP_CLEARUNORDEREDACCESSVIEW (13) [Type: D3D12_AUTO_BREADCRUMB_OP]<\/pre>\n
This shows that only one operation completed before faulting.\u00a0 In this case it was a ClearUnorderedAccessView command.<\/p>\n
The OutstandingOps value is an array (in normal forward order) of command list operations that are not guaranteed to have completed without error.<\/p>\n
((ModelViewer!D3D12_AUTO_BREADCRUMB_NODE *)0x1e2ed2dcf58)->OutstandingOps\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : [object Object]\r\n\u00a0\u00a0\u00a0 [0x0]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : D3D12_AUTO_BREADCRUMB_OP_COPYRESOURCE (9) [Type: D3D12_AUTO_BREADCRUMB_OP]\r\n\u00a0\u00a0\u00a0 [0x1]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : D3D12_AUTO_BREADCRUMB_OP_RESOURCEBARRIER (15) [Type: D3D12_AUTO_BREADCRUMB_OP]<\/pre>\n
In most cases, the first outstanding operation is the strongest suspect.\u00a0 The outstanding CopyResource operation shown here is in fact the culprit.<\/p>\n
Notice that PageFaultVA is not zero in the initial !d3ddred output.\u00a0 This indicates that the GPU faulted due to a read or write error (and that the GPU supports reporting of page faults).\u00a0 Beneath PageFaultVA is ExistingAllocations and RecentFreedAllocations.\u00a0 These contain arrays of allocations that match the faulting virtual address.\u00a0 Since ExistingAllocations is 0, it is not interesting in this case.\u00a0 However, RecentFreedAllocations has two entries that match the faulting VA:<\/p>\n
(*((ModelViewer!D3D12_DEVICE_REMOVED_EXTENDED_DATA1 *)0x7fffee841a08)).RecentFreedAllocations\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : Count: 2\r\n\u00a0\u00a0\u00a0 [0x0]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : 0x1e2e2599120 : [object Object] [Type: D3D12_DRED_ALLOCATION_NODE *]\r\n\u00a0\u00a0\u00a0 [0x1]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : 0x1e2e25990b0 : [object Object] [Type: D3D12_DRED_ALLOCATION_NODE *]<\/pre>\n
Allocation [0x0] is an internal heap object, and thus is not very interesting.\u00a0 However, allocation [0x1] reveals:<\/p>\n
((ModelViewer!D3D12_DRED_ALLOCATION_NODE *)0x1e2e25990b0)\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : 0x1e2e25990b0 : [object Object] [Type: D3D12_DRED_ALLOCATION_NODE *]\r\n\u00a0\u00a0\u00a0 [<Raw View>]\u00a0\u00a0\u00a0\u00a0 [Type: D3D12_DRED_ALLOCATION_NODE]\r\n\u00a0\u00a0\u00a0 ObjectName\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : 0x1e2ed352730 : \"UAVBuffer01\" [Type: wchar_t *]\r\n\u00a0\u00a0\u00a0 AllocationType\u00a0\u00a0 : D3D12_DRED_ALLOCATION_TYPE_RESOURCE (34) [Type: D3D12_DRED_ALLOCATION_TYPE]<\/pre>\n
So, a buffer named \u201cUAVBuffer01\u201d that mapped to the faulting VA was recently deleted.<\/p>\n
The verdict in this case is that the CopyResource operation on CommandList \u201cClearBufferCL\u201d tried to access buffer \u201cUAVBuffer01\u201d after it had been deleted.<\/p>\n
Symbols:<\/strong><\/h5>\n
Unfortunately, the public symbols for D3D12 do not include the type data needed for the D3DDred.js extension (type information is typically stripped from public OS symbols).\u00a0 Fortunately, D3DDred.js can usually work around this by searching though other loaded modules for the DRED data types.\u00a0 However, since older SDK\u2019s will not have the DRED types this workaround requires building with the Windows 10 May 2019 SDK.\u00a0 The good news is this has been addressed in the next OS release, and we are currently working to update the public symbols for May 2019 with the DRED data types.<\/p>\n
Enabling DRED:<\/strong><\/h5>\n
As of the May 2019 SDK, the most efficient way to enable DRED is by using the DRED API\u2019s.\u00a0 DRED must be enabled before creating the D3D12 Device.<\/p>\n
CComPtr<ID3D12DeviceRemovedExtendedDataSettings> pDredSettings;\r\nif (SUCCEEDED(D3D12GetDebugInterface(IID_PPV_ARGS(&pDredSettings))))\r\n{\r\n\u00a0\u00a0\u00a0 pDredSettings->SetAutoBreadcrumbsEnablement(D3D12_DRED_ENABLEMENT_FORCED_ON);\r\n\u00a0\u00a0\u00a0 pDredSettings->SetPageFaultEnablement(D3D12_DRED_ENABLEMENT_FORCED_ON);\r\n}<\/pre>\n
Thanks for reading:<\/strong><\/h5>\n
If TDR\u2019s are keeping you up at night, you want to use DRED – and you should check out the D3DDred.js debugger extension.\u00a0 As always, we look forward to your feedback and suggestions.<\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
Microsoft recently announced the release of DRED (Device Removed Extended Data) for D3D12 in the Windows 10 May 2019 Update (previously referred to as the Windows 10 19H1 Preview).\u00a0 Buried in that post is a mention that Microsoft is working on a debugger extension to help simplify post-mortem analysis of DRED.\u00a0 Good news, that debugger […]<\/p>\n","protected":false},"author":2473,"featured_media":12651,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2321","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-directx"],"acf":[],"blog_post_summary":"
Microsoft recently announced the release of DRED (Device Removed Extended Data) for D3D12 in the Windows 10 May 2019 Update (previously referred to as the Windows 10 19H1 Preview).\u00a0 Buried in that post is a mention that Microsoft is working on a debugger extension to help simplify post-mortem analysis of DRED.\u00a0 Good news, that debugger […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/posts\/2321","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/users\/2473"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/comments?post=2321"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/posts\/2321\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/media\/12651"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/media?parent=2321"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/categories?post=2321"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/directx\/wp-json\/wp\/v2\/tags?post=2321"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}