Debugging Silverlight applications with WinDbg

To use WinDbg to examine a dump…

1)      Make sure that the dump file is 32bit if it was running under a 32bit Silverlight runtime. Process Explorer creates 64 bit dumps on 64bit machines even for 32 bit applications. These will not work in WinDbg. You can use the Sysinternals procdump tool to create a 32 bit dump: procdump –ma sllauncher.exe mydump.dmp

2)      Make sure you are using the 32 bit version of WinDbg (for 32 bit dumps).

3)      Configure symbols in windbg: .sympath SRV*c:\symbolcache*http://msdl.microsoft.com/download/symbols

4)      Load the dump file in WinDbg (File, Open crash dump)

5)      Load SOS and the CoreCLR for Silverlight. The .loadby command seems to be broken so you’ll have to use .load and enter the complete paths:


.load C:\Program Files (x86)\Microsoft Silverlight\5.1.10411.0\sos.dll
.load C:\Program Files (x86)\Microsoft Silverlight\5.1.10411.0\coreclr.dll

If you’re using the 64 bit Silverlight runtime I believe you just need to use the 64bit WinDbg and load the dlls from C:\Program Files\Microsoft Silverlight\5.1.10411.0 instead.

You should be ready to go, for example:

0:000> !clrstack
OS Thread Id: 0x45dc (0)
Child SP IP Call Site
0014f3c0 03aa025f SilverlightApplication2.MainPage..ctor()
0014f3cc 03aa0215 SilverlightApplication2.App.Application_Startup(System.Object, System.Windows.StartupEventArgs)
0014f3e4 7b316fa3 MS.Internal.CoreInvokeHandler.InvokeEventHandler(UInt32, System.Delegate, System.Object, System.Object)
0014f410 7b2f5239 MS.Internal.JoltHelper.FireEvent(IntPtr, IntPtr, Int32, Int32, System.String, UInt32)
0014f460 7b390969 DomainNeutralILStubClass.IL_STUB_ReversePInvoke(Int32, Int32, Int32, Int32, IntPtr, Int32)
0014f510 02e017a7 [ContextTransitionFrame: 0014f510]

Sometimes, for example if your Silverlight application uses managed .NET COM components, WinDbg will try to load the wrong CLR debugging module. The quote from the deep dark depths of the WinDBG help file:

“To debug a managed application, the debugger must load a data access component (DAC) that corresponds to the CLR that the application has loaded. However, in some cases, the application loads more than one CLR. In that case, you can use the I parameter to specify which DAC the debugger should load.”

In this case the following two commands should sort things out:


.cordll -u
.cordll -I coreclr -lp "C:\Program Files (x86)\Microsoft Silverlight\5.1.10411.0"

This article also may also be useful:

http://www.codeproject.com/Articles/331050/Assembly-Helps-Debug-NET-Applications

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s