Debugging Process Crashes

 

Did I tell you Windbg is a great tool to debug native processes ? However, we still have to know how to approach the problem. Today, I wanted to debug user mode process crash. When I see a crash, I generally start the process under windbg and run the following command from debugger command window:

sxe eh

This enables the windbg catching first chance exceptions. Normally, first chance exceptions don’t cause a crash so you may not need this command at all but I like seeing what’s going on during execution. If first chance exceptions could not be handled, a second chance exception occurs and now you are in trouble. If you don’t have debugger attached to your process, you see that Window’s pop-up message saying that your process died…

Anyway, catching second-chance exceptions are easy. Windbg does this for you. However, today I encountered with another type of crash. The process just died. No crash message, no dump file, no nothing…. As usual I launched my dear lover, windbg, and attached to the process. I run the process and it died again and I didn’t receive any exception message from the debugger output. I then tried to put breakpoint to ExitProcess function and launched process monitor to see what was going on during crash. Still no luck…

Later, I happened to remember that some windows APIs call invoke_watson when an exception occurs. If you also register your unhandled exception filter, your filter can get called during invoke watson call. After a quick bing, I found the API that’s responsible for executing the filter and put a breakpoint to the API:

bp kernel32!UnhandledExceptionFilter

I let my process go again and voila! The breakpoint hit and I checked the call stack. In my case, the error was coming from swprintf_s API. It tends to validate parameters and call invalid parameter handler if buffer is not allocated in enough size. So, at the end of the day I was happy because I could debug my case and I used a different method to debug a process crash…