I believe I mentioned this in another thread, but we usually set up a separate launcher that starts the game and attaches itself as a debugger so it can catch the exceptions and write the mini dumps. It's a little more work to get up and running, but being able to catch those extra tricky bugs where the game itself is indeed in a bad state, is totally worth it. Plus you prevent someone from attaching their own debugger to the game, which isn't a huge deterrent for a determined hacker but it's low-hanging fruit that comes for free with the crash dump collector
But doesn't attaching a debugger do a hit on your game's performance? Also wouldn't the end user need to have the debugger installed. I think I'm misinterpreting you and your talking about a custom watchdog like process. Even still how does it know if the game crashed?
It won't work in OSX or Linux because they don't use Windows executables. (Well, they can if you are using WINE, but it still works the same.)
It is almost as easy as you wrote.
Create your exception handler with the signature: LONG WINAPI MyCrashHandler(EXCEPTION_POINTERS * ExceptionInfo);
You can put whatever popups and useful information you want, but make sure it calls MiniDumpWriteDump(). That function will write your minidump file.
Then in your main function, register your function with ::SetUnhandledExceptionFilter(MyCrashHandler);
That will capture most stuff, but there are a few situations where the system terminates your program without calling it, like fatally corrupting your heap.
Linux and OSX have their own equivalents right? Or on Linux and OSX you need a custom dump?
Would it be better to write my own custom crash dump? Where it does not use OS API methods like MiniDumpWriteDump.
Something that catches exceptions like in my above post?
Or would that be a "bad way" to handle things, becuase itsn't that what the MiniDumpWriteDump and SetUnhandledExceptionFilter calls basically do?
