Don't use the 64 bit task manager to create a dump of a 32 bit process.

Yeah, that didn't work. The problem and the solution are both in the post title.

VS 2015 wouldn't let me look at the heap and didn't give me enough information about why, so I downloaded WinDbg and tried to get more information. At least with WinDbg I could make some progress.

New command: .cordll -ve -u -l

That gave me some good information, but it didn't work. What I did get from it was a path forward.

I ended up copying mscordacwks from the problem computer to the WinDbg directory on the computer that I was using for debugging. I also had to rename it to mscordacwks_AMD64_x86_4.0.3.319.18034.dll. Then, I did the same thing with SOS.dll.

Then when this didn't work, I found a stack overflow post suggesting the 32 bit Task Manager solution.

Is it leaking?

I wondered if my program was leaking. Here's how I found out:
Using Visual Studio 2012, into the immediate window, I typed:

.load SOS

Then, I investigated my class with this command (still in the immediate window).

!DumpHeap -type

I could see how many objects there were of this type in the heap. I could see their addresses in memory.

!gcroot

This command showed me where they came from and what other objects had references to them.

Finally:

!finalizequeue -allready

This allowed me to verify that although the object wasn't finalized yet, it was due to be whenever the Garbage Collector got around to it and therefore, my program wasn't leaking.

How to load SOS into Visual Studio

How to load SOS debugging extensions into the immediate window of Visual Studio (any version).

.load sos

For some reason, this little gem has escaped me until now. Will I ever use WinDBG again? Do I feel sad or glad about that?

WinDbg

I'm posting some notes from my latest debugging adventure.

The big advantage to WinDbg is easy deployment on a test machine. I don't have to worry about installing remote debugging with visual studio or correctly setting up the permissions.

The notes:

1) Although the download site says that you probably want to run 64 bit WinDbg on a 64 bit machine, the machine architecture is irrelevant. Most apps that I've been writing, and especially those that use legacy COM objects are x86 and WinDbg behaves poorly if you don't get the right version for your architecture. The download page is here.

2) Downloading WinDbg is still annoying. But this is only because I remember the good old days where I only needed to download the Debugging Tools for Windows and not some entire SDK.

3) sxe clr
This breaks the debugger whenever there is a CLR exception. I'm always after some .net bug. This is the first thing that I type in to get going, usually right after WinDbg attaches.

4) .loadby sos mscorwks
This loads the SoS Debugging extensions for .net. I wait until WinDbg breaks after the first CLR error, because this command won't work until mscorwks is actually loaded by the program.

5) !pe
This is short for !PrintException. It outputs information about a .net exception.

6) !CLRStack
This outputs the .net stack trace, ignoring the surrounding native code.

7) !dso
Dump Stack Objects. Helps you figure out what objects in memory are likely to be involved in any current problem.

8) !do
Dump Object. Information about a single object.

A cheatsheet