The Silverlight Common Language Runtime
When debugging desktop CLR bound applications, we typically attach the debugger to an executable (for example, a GUI or command-line application). Debugging Silverlight applications, on the other hand, requires us to understand in which process the Silverlight application is hosted. Most of the time, a Silverlight application runs in the context of a browser (Internet Explorer, Firefox, etc.), so the key lies in finding the correct browser process to attach the debugger to.
In this article, I will use Internet Explorer (version 8), and the corresponding process is called iexplore.exe. Using the sample application associated with this article, we can simply launch TestPage.html, which launches Internet Explorer, initializes the Silverlight CLR (also known as CoreCLR), and executes our Silverlight application, as shown in Figure 1.
Figure 1 Launching the sample Silverlight application under Internet Explorer.
As you can see, the sample application is pretty straightforward. It contains a simple button (Click Me) that is centered in the browser window. As mentioned before, once a Silverlight application is launched in the browser, we need to figure out which underlying process hosts the application. We already know that the Internet Explorer process is called iexplore.exe, but because there can be many instances of IE open at the same time, how can we find out which exact process hosts our Silverlight application? The answer to that question lies in finding the process that hosts our application DLL (SampleApp.Dll). We can then use the tlist.exe command (part of Debugging Tools for Windows) with the –m switch to list all the processes that have that DLL loaded:
C:\> dbg\tlist -m CoreCLR.dll c:\Program Files\Microsoft Silverlight\3.0.40818.0\coreclr.dll - 15200 iexplore.exe SysFader
The output of the tlist.exe command shows that the iexplore.exe process with a process identifier of 15200 has the CoreCLR.dll module loaded from the Silverlight version 3.0 folder.
Before we jump into the actual process of debugging this application, let’s see what happens when we click the button. Figure 2 illustrates the result.
Figure 2 Clicking on the Click Me button.
In the bottom-left corner of the browser window, we can see a status message that states Error on page. Furthermore, if we click on the status message, a dialog appears, as shown in Figure 3.
Figure 3 Error message dialog.
The error dialog clearly shows that an exception was thrown as well as the detailed stack trace. While it’s nice to be able to see more extensive details on the error, most of the time it is not enough for definitive root cause analysis, and a debugger has to be attached for further analysis. The next section describes the process of using the debuggers to focus in on the exact problem.