As some of you might know, during the day (well... often evenings as well :)) I work at RealDolmen, one of Belgium's biggest ICT companies.  On Tuesday, September 21st we're organizing our very first SimplICiTy day, a free event about innovation in the Microsoft stack.  We've got three different tracks for those willing to attend (a business track, infrastructure track and development track), an expert bar, free food and drinks for the hungry and thirsty, ...  so if you happen to be in the neighbourhood: drop on by! :)

I will be delivering a session on Rich User Interfaces: a Logical (R)evolution.  If you want to learn about why these new technologies are quickly emerging to be the standard way to develop .NET applications, what you can do with them, what you need to start coding them yourself, ... this is the perfect session for you. 

Interested?  Don't forget to register - as said, it's all completely free!

Today (second day after my vacation :-)), I’ve been looking for a solution to a rather nasty memory leak in a Silverlight application.  Typically, you can do this in two ways: by using WinDebug, or through Visual Studio’s Immediate Window.

I’m not going to go into the specifics of both – there are already blog posts about that, you can find a nice overview on how to debug Silverlight apps using WinDBG by Delay, another one by Ning Zhang here, and an overview of using it with the Visual Studio Immediate Window here.

However, I stumbled upon a problem that kept me amused frustrated for a couple of hours.  To be able to debug Silverlight apps this way, you need to load the sos coreclr extension.  Typically, in WinDBG, you’d do this as such:

!loadby sos coreclr

This gave me an “unable to load”-error.  No worries, maybe I had selected the wrong Internet Explorer process?  So I tried the other active processes, and tried loading it again.  Same problem.

Quick check to see if my symbol path was ok:

.sympath

didn’t make me any wiser – everything looked ok

Right.  So I tried debugging through Visual Studio’s Immediate Window (remember, if you’re trying this you need to enable the unmanaged code / native code debugger in your project properties), and loading the sos coreclr extension there.  Same problem.

You don’t even want to know what happened next.  I tried everything again, and again, and again with the exact path to sos.dll instead of through what was loaded in the iexplore.exe process.  And again in WinDebug.  And again in Visual Studio.  And again by having a look at the process with Process Explorer to see if I didn’t miss the correct process for the 70th time.  And again, in a different order.  Et cetera ad infinitum.

Nothing seemed to work.  So I tried some backtracking: what’s different since I last did this?  Well, I’ve now got a 64 bit processor, running Windows 7 – before I had a 32 bit processor running Windows XP.

So I checked if I had installed the 64 bit version of WinDebug.  Which I had.

And then I finally found the solution.  Although IE is 64 bit on my machine, Silverlight is not (simply doesn’t exist yet)!  So maybe I needed the 32 bit version of WinDebug?  I tried installing this (it can be found in the redistributables you get when installing the Windows SDK – which includes WinDebug) and … problem solved!  Magically, everything started to work as it should.

So, if anyone is looking to track down a Silverlight memory leak on a Windows 7 machine using WinDebug: remember to use the 32 bit version of WinDebug. 

Hope this saves some of you from a few frustrations! ;-)