Silverlight Developers: You need to Learn WinDbg and SOS!

There is no Yellow Icon (Exception) in my Internet Explorer when running Kompas ePaper, but my Visual Studio Output Window throws out these exceptions:

01

I tried hunting down the FileNotFoundException for 2 weeks without success. I thought I can get the exception message by catching exceptions and using Debug.WriteLine (well it works for some – see the message “Loaded Fonts1,2,3,15”)

Alas, it seems Visual Studio is not good enough for Silverlight Debugging, so I loaded up the mother-of-all debugging tools: WinDbg.

Here are the steps I did to find out what the FileNotFoundException refer to:

1. Download Windows Debugging Tools

IMPORTANT: Even if you’re running Windows Vista x64 and Windows 7 x64, you will need to download the 32-bit version!

This is because you will most likely run the Internet Explorer 32-bit version, not IE 64-bit. So to debug 32-bit apps you need to use 32-bit debuggers, eventhough you’re running 64-bit operating system. In future post, I will share my painful story of debugging Biztalk x64, SQL x64, SAP x64 and Visual Studio (hint: Visual Studio is a 32-bit app)

2. Find the Process ID that’s loading Silverlight (agcore.dll). Do not use Task Manager because since IE supports Tabbed-Browsing, there will be multiple IE processes. I used SysInternals’ Process Explorer:

00 

3. Run WinDbg and press F6 (attach debugger to process) by choosing the correct PID of iexplorer.exe

4. Set the Debug Symbols Path for debugger by typing this command:

.sympath SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

 

5. Reload symbols by typing this command:

.reload

 

6. Load SOS extension for Silverlight, so you can debug managed programs:

.load C:\Program Files (x86)\Microsoft Silverlight\3.0.40818.0\sos

 

(Silverlight’s SOS.DLL is installed when you install the Silverlight Tools)

 

7. Check for Exceptions thrown into the heap (use !dumpheap command):

02

8. Note the Managed Pointer Address, and use !dumpheap again to find the real memory address:

04

9. Use the !pe command to Print Exception on the Memory Addresses:

05

06

Cools, now I know why the FileNotFoundException was thrown (Image_220.JPG) and where was it thrown (in the Constructor of IsolatedStorageFileStream)

So there… Visual Studio is not enough for Silverlight Developers… you need to learn WinDbg and SOS too.

On a bright side, learning WinDbg will make you a special programmer different from the rest :)

Oh and I heard rumors that in Redmond, Microsoft engineers use WinDbg to debug and not visual studio (except the VS team maybe).

Power to the SOS!

Share this post: | | | |
Published Wednesday, October 7, 2009 2:23 PM by zeddy

Comments

# re: Silverlight Developers: You need to Learn WinDbg and SOS!

Thursday, October 8, 2009 1:00 PM by ronaldwidha

You're a sick sick man mr. zeddy!

sickeningly cool.

debugging using windbg seem to be verging to working in an unmanaged environment. Is this just another instance of  leaky abstraction? Shouldn't the exception contains the 'right' inner exception in the first place?

# re: Silverlight Developers: You need to Learn WinDbg and SOS!

Thursday, October 8, 2009 9:07 PM by Rahmat Sobari

I'm just thinking.

If you said WinDbg is mother-of-all debugging tools then SoftICE will be the grand-mother-of-all debugging tools -:)

Anyway, good article. Thanks

# re: Silverlight Developers: You need to Learn WinDbg and SOS!

Friday, October 9, 2009 7:40 AM by zeddy

@rahmat: nope.

1) WinDbg is a user-mode debugger and also kernel-mode debugger. You boot windows with /debug options, and WinDbg can catch and suspend all Windows system calls (useful for driver debugging).

2) SoftICE is a discontinued product by Compuware (who bought it from NuMega) since 2006. So SoftICE might not run well with future Windows OS, whereas WinDbg and KD (windows kernel debugger console mode) rill always be updated for latest Windows OS.

SoftICE is...dead.

# re: Silverlight Developers: You need to Learn WinDbg and SOS!

Friday, October 9, 2009 7:52 AM by zeddy

@ronaldw: yes, the inner exception should contain which file is not found, but for some freaking reason it's not caught up by vstudio.

That's where SOS.dll comes in, according to MSDN, SOS is "The SOS Debugging Extension (SOS.dll) helps you debug managed programs in the WinDbg.exe debugger and in Visual Studio by providing information about the internal common language runtime (CLR) environment." link: msdn.microsoft.com/.../bb190764(VS.80).aspx

So yes WinDbg was designed to debug 1) drivers and other low-level apps using kernel-mode debugging,  2) native apps using user-mode debugging,  and 3) managed apps using user-mode debugging + SOS.dll

Leaky abstraction indeed... but how else do Silverlight programmers check for Memory Leaks (next post maybe)?

# re: Silverlight Developers: You need to Learn WinDbg and SOS!

Friday, October 9, 2009 10:49 PM by ronaldwidha

Interesting remark about using sos and windbg to check memory leaks.

Side note, Ayende mention he was having memory leaks on his wpf app (NHProfiler). I was wondering how he debugged it, and just assumed he was testing through trial and error binary chopping the possible culprit.

Looking forward for that post Zed

Powered by Community Server (Commercial Edition), by Telligent Systems