I’m spending a fair amount of time debugging at the moment. The particular application I’m looking at is a suite of related server processes which spawn each other and are very multithreaded.
I’ve been looking for was a way of
getting my debugger “in” right at the start of the one of the servers, even when it was
launched by another server process. Ideally, I’d just put a DebugBreak()
somewhere at the beginning of the server, and use JIT
debugging to attach at that point.
Unfortunately, for some reason that wasn’t working; by the time the debugger had attached, the call stack was out in the uncaught exception handling code. Not very useful.
After some searching around, I found something in Windows I’d never heard of before, which I thought might be the perfect thing. Apparently, with the right registry keys, you can make Windows automatically debug a given executable. The details are on MSDN.
This seemed like a perfect solution. Whenever the server is run, the debugger is launched with the parameters to debug the executable. However, a fresh new IDE is started every time, and the process isn’t started automatically.
By the time I’ve started the process myself — annoyingly forcing a save of the solution file, with all the attendant dialogs that requires — the server which spawned the process has timed it out and started another copy. That timeout, coupled with the plethora of new IDEs popping up everywhere made this approach unusable.
In the end I rolled my own solution, querying the relevant registry key
myself, launching the JIT debugger in code and then awaiting its attachment using IsDebuggerPresent()
.
Matt Godbolt is a C++ developer living in Chicago. Follow him on Mastodon or Bluesky.