How to handle DirectX 11 driver crash

Question

First off, I'm sorry if this question has been asked many time, but I could not find any proper answer on the web.

I'm developing a game that use DirectX 11.1. I've been using for quite some time a crash reporter using the Google's Crash-Pad library witch upload Minidumps to a server that can be later opened with Visual Studio or de-symbolicate and print a stack-trace of each of the threads at the time of the crash.

I've always been spammed with some wired stacktrace that goes really deep into drivers dll (that can of-course could not be de-symbolicate) and I have always considered theses stack-trace to be associated with driver crash.

Thread 10224 Crashed:
0   igd10iumd64.dll                 0x7ffbddcb4cba      <unknown>
1   igd10iumd64.dll                 0x7ffbddcae78e      <unknown>
2   igd11dxva64.dll                 0x7ffbaef99377      <unknown>
3   igd10iumd64.dll                 0x7ffbddcae2f9      <unknown>
4   igd10iumd64.dll                 0x7ffbddd89e17      <unknown>
5   igd11dxva64.dll                 0x7ffbaef73c5c      <unknown>
6   igd11dxva64.dll                 0x7ffbaef7314d      <unknown>
7   igd11dxva64.dll                 0x7ffbaef3efcf      <unknown>
8   igd11dxva64.dll                 0x7ffbaeff158a      <unknown>
9   igd11dxva64.dll                 0x7ffbaefe8cf6      <unknown>
10  igd11dxva64.dll                 0x7ffbaefe96b8      <unknown>

My question now is, how in a typical DirectX application you handle such crash and make sure that your app is robust and will not crash? (Even if I need to recreate the whole D3D11 Device)

I am already handling the standard DXGI return codes in case of device removal and reset (DXGI_ERROR_DEVICE_REMOVED && DXGI_ERROR_DEVICE_RESET) following MSDN guide

Thanks

EDIT: I don't mind having to quit my app, I just want to explain to the user that my app encountered a fatal error and will now exit (as properly as possible)

Answer 1

Easiest method for catching a crash and terminating is to use a Structured Exception Handler around the entirety of your main function. This will catch access violations, divide by zeros, and other hard errors that would cause a crash. From there, you can display a popup that states the nature of the crash before terminating the process.

Note that SEH does not allow for destructors to run. Normally, this is a bad thing, but here you're killing the process anyway, so it isn't as much of an issue. However, any locks that were taken in the constructor of an object are not going to be released upon execution of the SEH handler. Not only that, but the objects themselves will no longer exist if they were allocated on the stack, preventing any sort of real cleanup.

Again, the above is not an issue here, as your process is in the middle of crashing. Data corruption is irrelevant now, as the process is already FUBARed. All you need to do is pop up a message box saying you crashed, save off whatever info you absolutely need (use no locks here, since the lock state is now indeterminate), and terminate (not exit) the process (if you exit, process/thread detach notifications are sent, which may cause deadlocks).

This can be extended to all other threads you explicitly create by having the threads start at a common entry point, enter an SEH frame, and branch off to their respective tasks afterwards.