- Prerequisites
- The Silverlight Common Language Runtime
- Setting Up a Silverlight Debugging Session
- Debugging the Exception
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Setting Up a Silverlight Debugging Session
There are a couple of different ways in which to do debugging in general. One is known as live debugging and involves attaching the debugger to a live running process. The other is known as postmortem debugging and involves attaching the debugger to a snapshot taken from a live process. The primary difference between the two modes of debugging is that with a live debug session, you are able to do a lot more than with a snapshot (for example, tracing the actual execution of the code, setting breakpoints, resuming execution, etc.). In this article, we illustrate how to debug our faulty Silverlight application via live debugging.
In the previous section, we identified the unique instance of iexplore.exe that hosts our Silverlight application. In order to attach a debugger to that instance, we use the –p switch and specify the process identifier, as follows:
C:\> dbg\ntsd –g -p 15200
This command launches the ntsd debugger attached to process identifier 15200. The –g switch simply states to ignore the default initial breakpoint. Once the debugger has launched, we go back to our Silverlight application and click the button once again. This time you see the following debug spew output:
(3b60.3b84): CLR exception - code e0434352 (first chance) (3b60.3b84): CLR exception - code e0434352 (first chance)
As a matter of fact, each time the button is clicked, the same sequence of debug spew is output. What is happening here is that a first chance exception is thrown (with exception code 0xe0434352 which indicates that it is a CLR exception), which is subsequently caught (hence no second-chance exception). In order for the debugger to stop execution when the exception is thrown, we have to explicitly tell it to do so by using the sxe command:
0:015> sxe e0434352
The next time we click the button, we can see that the debugger did indeed stop as shown here:
(3b60.3b84): CLR exception - code e0434352 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=0208f538 ebx=00000001 ecx=00000005 edx=00000000 esi=0208f5bc edi=00000005 eip=75c89617 esp=0208f538 ebp=0208f588 iopl=0 nv up ei pl nz ac po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000212 KERNELBASE!RaiseException+0x58: 75c89617 c9 leave
At this point, we have successfully stopped the debugger at the point of failure, and we can use the powers of the debugger to help us understand the root cause. As with desktop CLR debugging, there is a debugger extension specifically for the CLR called SOS. The same debugger extension exists for the Silverlight CLR and is also called SOS. The debugger extension can be found under the Silverlight installation folder. For example, on my computer, it is located here:
Directory of c:\Program Files\Microsoft Silverlight\3.0.40818.0
08/17/2009 10:09 PM 494,392 sos.dll
1 File(s) 494,392 bytes
0 Dir(s) 21,796,585,472 bytes free
In order to use the SOS debugger extension, we must first tell the debugger to load it by using the .load command, as shown here:
0:004> .load c:\Program Files\Microsoft Silverlight\3.0.40818.0\sos.dll
Once the debugger extension is the last task we have to perform before we can actively debug the process is to ensure that the symbols are loaded and available by using the .symfix and .reload commands respectively as shown below:
0:004> .symfix 0:004> .reload Reloading current modules
Now that all the required preparatory work has been completed (attaching to the process, loading the SOS debugger extension, and loading the symbols), we turn our attention to the debugging the actual failure.