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.
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.
Cool solution, but I'd assume/hope Windows currently has sufficient memory protections to not allow applications to rewrite their own memory - especially if the function was already in a DLL to begin with and not JIT-generated code?
Code segments are not writeble by default on Windows, like on any modern OS, but you can make any memory segment in your own process writable using VirtualProtect. That is not unique to Windows as well, on Linux you could achieve the same with mprotect.
As sibling notes, executable memory is not by default writable. If desired, you can also further disallow any executable memory to me allocated or modified by your process, even via the normal APIs, by calling SetProcessMitigationPolicy with ProcessDynamicCodePolicy.
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.
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.
The most insidious version of this I experienced was when a library changed the FPU settings.
Fortunately, it was sufficient to reset the FPU settings after initializing the library. But it sure took a long time to figure out what happened!
Cool solution, but I'd assume/hope Windows currently has sufficient memory protections to not allow applications to rewrite their own memory - especially if the function was already in a DLL to begin with and not JIT-generated code?
Code segments are not writeble by default on Windows, like on any modern OS, but you can make any memory segment in your own process writable using VirtualProtect. That is not unique to Windows as well, on Linux you could achieve the same with mprotect.
As sibling notes, executable memory is not by default writable. If desired, you can also further disallow any executable memory to me allocated or modified by your process, even via the normal APIs, by calling SetProcessMitigationPolicy with ProcessDynamicCodePolicy.
https://learn.microsoft.com/en-us/windows/win32/api/processt...