I’m having an almost 100% crash under DX12 with aftermath 1.3 and driver 387.92, on 970 gtx. I stick to these “old” drivers because newer drivers also crash with our engine (I could see a crash on kepler in starwars battlefront 2 in the release notes for 388.31 iirc - maybe it’s related). Anyway, here’s the error and callstack, if it can help:
Exception thrown at 0x00007FFF900FFA64 (nvwgf2umx.dll) in x64_appframework_r.exe: 0xC0000005: Access violation reading location 0x00000000000000A0.
On a side note, I’ve also tried aftermath 1.3 with driver 388.31 to check the extended page fault result . I could get a device in “Page fault” status (which I don’t have with 397.92, see above) but the call to GFSDK_Aftermath_GetPageFaultInformation() would still fail.
please note that it’s also crashing under DX11, on quit, with heap corruption.
This middleware really needs perfect stability to be usable. It won’t help me understand rare gpu crashes if it crashes everywhere on the cpu side, at a much higher frequency.
8 months later, the access violation is still there with driver 398.82:
Exception thrown at 0x00007FFA8450E4FF (nvwgf2umx.dll) in x64_appframework_r.exe: 0xC0000005: Access violation reading location 0x00000000000000A0.
I’ve finally found the bug, which is in our code. Due to very convoluted command list management, we could use an aftermath handle on a command list it does not belong to. If you want to an error return value for that case…
The crash on quit still exist though, once an aftermath handle is created. I could repro this in our engine, and in Microsoft MiniEngine.