Sometimes bug happens before you have the chance to attach a debugger to the faulting process. Most of the time it’s because it is launched by another process (a service, the compiler used to create a Xml serializer of a .NET software, a batch script, etc.) and you don’t have the time to get the command line with ProcessExplorer. And even if you can get it, a process may expect some context coming from its parent. And obviously, sometimes you don’t have a clue about how a process is launched, all you know is that it crashes and you need to see what’s inside before it do so.
After a few tryout to pause the process (Process Explorer is your friend) before it crashes, or some tentative to slow down your computer so you have the time to attach a debugger, you’re starting to get frustrated. Hopefully I have some solutions for you.
As usual, I stumble upon a nasty issue while I was writing another post : create a native breakpoint on a function which I don’t have the source code. In Visual Studio 2010. In my case it was on User32.dll!SendMessageW, but you can experience the same difficulty for any other function if you are using symbol files without the path to the source code (as, by instance, public symbols of Microsoft…).
Of course, with WinDbg, nothing (well, almost) could be simpler: just get the name of your function with format <module>!<function name> (if you’re not sure about the name issue a “x <module>!*<part of function name>*” and search into the results), and then type “bu <module>!<function name>“, and you’re done. You can see here that WinDbg was designed to work without source code. It is definitely not the case of Visual Studio. So, how can you achieve this (simple) goal: break on a function without the source code?