Have you ever been presented with a memory exception? See Figure 13-9. Of course, I am sure this exception occurred while you were using an application that someone else wrote. As a kind gesture, you volunteered to help diagnose the problem and make an unstable application robust.
Managed exceptions start life as native exceptions. To raise an exception, the CLR calls mscorwks!RaiseTheException. RaiseTheException then calls RaiseException, which is a system-level API. RaiseException assigns all managed exceptions the E0434F4D exception code. Because all managed exceptions are raised with this same exception code, it is difficult to distinguish between managed exceptions. Fortunately, the first parameter of the RaiseTheException function call is the managed exception object. You can dump that object to ascertain the specific exception objection.
The Exception application is modified to raise an exception when the Add Transactions button is clicked. The object of this walkthrough is to determine the type of exception.
Start the Store application. Open WinDbg and attach to that program.
Set a breakpoint on the RaiseException API and resume the application:
0:004> bp Kernel32!RaiseException; g
Click the Add Transaction button. The exception is raised and the breakpoint is hit in WinDbg. Display the call stack.
Use the !dumpobj command to dump the first parameter of RaiseTheException, which is the managed exception object. You now have the details of the exception, including the exception type.
There are two other ways to trap managed exceptions.
sxe clr This command breaks on all unhandled managed exceptions. You can then perform a back trace for the details of the exception, which exist on the call stack. This is an alternative to breaking on RaiseTheException API.
!soe exceptiontype This is the Stop On Exception command and an SOS command. A breakpoint is set on the type of exception specified. Before issuing the command, switch to the thread on which the exception is expected.