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.
Read more: kevin dockx / icecream
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.
Read more: kevin dockx / icecream