baldurk / renderdoc

RenderDoc is a stand-alone graphics debugging tool.
https://renderdoc.org
MIT License
8.98k stars 1.35k forks source link

Crash on resetting command list in WrappedID3D12Device::GetNewList when calling swap chain's present. #3418

Closed Alegruz closed 1 month ago

Alegruz commented 2 months ago

Description

Unhandled exception thrown: read access violation. ret was 0xFFFFFFFFFFFFFFFF.

I launched my game using RenderDoc, and it crashes when the swap chain is presented. This happens anytime, but normally this occurs in the middle of the gameplay. The call stack is as follows:

* WrappedD3D12Device::GetNewList() Line 4273 * WrappedD3D12Device::Present(ID3D12GraphicsCommandList * pOverlayCommandList, IDXGISwapper * swap... * WrappedD3D12Device::Present(IDXGISwapper * swapper, unsigned int SyncInterval, unsigned int Flags) Line 1... * WrappedIDXGISwapChain4::Present(unsigned int SyncInterval, unsigned int Flags) Line 564 * MyGame.exe! ... Internal commands had three free command lists, but the last one seemed broken for the first two command lists showed the contents of `WrappedID3D12GraphicsCommandList`, while the last one did not. The error message says that `ret` was -1, but when I saw the `ref` in the debugger, it was not -1. However, just like the last free command list, it only showed the `ID3D12GraphicsCommandListX` part, not the wrapped one, so I am assuming that this command list and the last free command list are corrupted. ## Steps to reproduce The application is proprietary, so I cannot provide any .exes, ;( I don't think it always crashes because I managed to successfully launch the game without crashing just once. ## Environment the application uses two swap chains each with a window. * RenderDoc version: 1.34 (both installed version and built version crashes) * Operating System: Windows 10 * Graphics API: Direct3D 12 * GPU: RTX 3060 * NVIDIA driver version: 551.61
Alegruz commented 2 months ago

It doesn't crash when using PIX on Windows 08.09 version

baldurk commented 2 months ago

Unfortunately as you might guess without being able to reproduce this there's not much I can do to investigate it. Would it be possible for you to share your program with me privately, even if not publicly?

Your conclusion that something has corrupted the next free command buffer seems reasonable - the error about the invalid pointer is because I believe VS will print 0xFFFFFFFFFFFFFFFF for any invalid pointer that doesn't point to legal address range (not just unmapped memory but invalid bits set in the pointer) so that just means it's corrupted at the time it tries to access the vtable.

If you can't share your program would you be able to do further debugging to narrow down the problem? E.g. eliminating parts of your rendering path for testing to try and narrow down what might be leading to the crash? Have you run your program with the D3D12 validation enabled and fixed any issues it identifies?

Alegruz commented 2 months ago

I guess I have no choice but to debug the issue further myself. Validation returned nothing(D3D12 and Vulkan), but I suspect the swapchain issue. Running the app with an editor crashes, but running the app without an editor doesn't.

baldurk commented 2 months ago

Yes I'm sorry but without something more solid to investigate or ideally a reproducible test case there's not much I can do to help beyond the suggestions in the reply above. If you do want to debug it you can get in touch over email and I can try to help guide debugging on the RenderDoc side - I'm not sure what you mean by "the swapchain issue". I saw that the callstack of the crash is in Present but if a list has gotten corrupted at some earlier point that call doesn't necessarily have anything to do with the cause of the bug.

baldurk commented 1 month ago

Unfortunately as mentioned above, without a reproducible test case or more information e.g. via pair debugging over email there's nothing else I can do here to help with the crash. Closing this issue now - if anyone else runs into this and is able to provide more information in future please open a new issue.