Hacker News Reader

Comment by Const-me | Hacker News Reader

Cool trick, but I wouldn’t do that for the use case.

The use case they had is saving minidumps when the app crashes. Windows error reporting OS component is flexible enough to support the feature without hacks, they just need to write couple values to registry in the installer of their software. See details on per-application settings in that article: https://learn.microsoft.com/en-us/windows/win32/wer/collecti...

If they want better UX and/or compress & uploads the dump as soon as the app crashes (as opposed to the next launch of the app) – I would solve by making a simple supervisor app which launches the main binary with CreateProcess, waits for it to exit, then looks for the MainApp.exe.{ProcessID}.dmp file created by that WER OS component.

View on HN

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.

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.

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.

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.

The Registry keys for WER, even the per-application ones, are all under HKEY_LOCAL_MACHINE. They cannot be set without elevation. WER is also useless if you want to capture contextual in-process data about the crash.

This problem is so rampant that even Office hooks SetUnhandledExceptionFilter.

Requiring elevation wasn't uncommon for games or most applications back then. Installing to local app data is somewhat new, though platforms like Steam smartly modified the NTFS permissions in their own app dir to prevent elevation specifically for binary deployment; other components like C runtime, etc. during game install would require elevation.

Office is a poor example of 'what to do'. The title bar is a hack. It only supports ~214 character path length even though Win32 API has been lifted to 32k, etc.

Sure, if an application uses an elevated installer -- but as you note, not all do. It does look like WER may support options being set in HKCU (per-user) as well as HKLM (machine-wide), which would be a way of handling local installs.

I wouldn't characterize Steam's world-writable folder strategy as smart, compared to a more secure model using an elevated downloader and installer.

I fail to see what Office's title bar rendering has to do with its exception handling strategy. As for path length handling, Office also hosts a large in-process plugin ecosystem, so it has to be conservative with such application-level policy changes.

Reply on news.ycombinator.com