Recently I had to debug a situation where application was crashing during start-up. This issue was not reproducible so I had to use production debugging techniques to find root cause of problem.
At the time of crash, all I was getting from Event logs is that it was a .NET exception but no call stack or anything that can provide any idea of what part of code is faulting. Given the size of project and code base, there could be hundreds (if not thousands) of places in code that could raise an exception. This post describes a very useful technique that you can use in this type of situation. There are several ways of getting information about what part of code is throwing the exception. The one I find quite effective is by putting a breakpoint at KernelBase.RaiseException.
Let’s say our test code is as follows.
Launch the application and setup breakpoint using command below. Its always a good practice to make sure breakpoint has been added by using bl command.
Now whenever an excpetion is raised by application, this break point will hit. At this point, you can inspect the native and managed stack traces to find out what method is causing the exception.
You can even disassemble the code, to find out which line witin that method is potentially causing that exception.
Until next, happy debugging.