[chadaustin]

Hello, author here (16 years ago). I don't think that component existed then. In hindsight, we would have either used WER or initiated crash dumps from outside of the process via a watchdog. It is quite problematic to attempt to capture your process state from within a failed process.

That said, we did have a bunch of hand-rolled state capturing (including Python thread stacks) so maybe WER wouldn't have been as useful anyway.

[muststopmyths]

WER has been in the OS for about 20 years. Vista for sure, maybe even before that.

Writing your own minidump uploader in the unhandled exception filter is/was a very common practice in games, while obviously not ideal.

I think Unreal Engine might still do that. So I think that the claim that Direct3D captures exceptions is suspect.

It may trap them and return EXCEPTION_CONTINUE_SEARCH to pass it on to the next handler, but I have a hard time coming up with a reason why it would trap them in the first place. I have personally never seen Direct3D trap an exception in my long career.

Maybe you were expecting C++ exceptions to be caught, but these APIs are only for SEH.

Now Flash, I have no experience with.

Yes, I know it's a 16year old post. But I must stop myths.

[ack_complete]

Direct3D doesn't, but the kernel can eat exceptions if 32-bit code triggers an exception from a user mode callback on a 64-bit system. Rendering code is vulnerable to this when triggered from a WM_PAINT message. The call SetProcessUserModeExceptionPolicy() is needed to override the default behavior:

https://code.google.com/archive/p/crashrpt/issues/104

It was introduced in a Windows 7 update and documented in a knowledge base article that has since been removed instead of the regular Win32 docs, so information on it is harder to find these days.

[chadaustin]

WER existed on XP but the APIs needed to customize dumps didn’t. And IMVU’s crash reporting code dated back to 2005.

> So I think that the claim that Direct3D captures exceptions is suspect.

I would think that too - but I based my claims on a stack trace captured at the time in the overridden SetUnhandledExceptionFilter. Now, computers were the Wild West then, and who knows where those DLLs actually originated, and any further details are lost to time.

> Maybe you were expecting C++ exceptions to be caught, but these APIs are only for SEH.

The distinction was clear then. And very well-documented by Microsoft. We caught all C++ exceptions before SEH.

> Yes, I know it's a 16year old post. But I must stop myths.

Your goal is laudable but I don’t love comments that discount a concrete history that I lived (and documented!). I call this out mostly because it’s happened before in discussions of old Windows APIs. I wish it were easier to get a snapshot of MSDN circa Windows XP, etc.