Home/ Questions/Q 8472609
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-10T17:07:24+00:00

In order to track down memory leaks, I have been using Visual Studio and

  • 0

In order to track down memory leaks, I have been using Visual Studio and SOS.dll to provide dumps of the object heap, and to see what is GCRooting a particular object in place.

I started automating this process using AutoIt to control my mouse and keyboard. Here is an approximation of the first part of my script:

In Visual Studio, press F5 to start execution
Let the program fully load
Switch to Visual Studio and break execution

Switch focus to the immediate window
Load SOS.dll
Call !dumpheap -stat
Copy the result of the dump to the clipboard
Paste in notepad and save as dump1.txt

Resume execution
Perform the leaky action a number of times
Switch to Visual Studio and break execution

Switch focus to the immediate window
Clear the output
Call !dumpheap -stat
Copy the result of the dump to the clipboard
Paste in notepad and save as dump2.txt

Run a Python script which compares the two dumps and locates leaked objects

I have a few concerns with my current method, though. Not only am I dependent on an installation of Visual Studio, but while the script is running I cannot use the mouse or keyboard without throwing the automation out of sequence.

Is there a way to use SOS.dll within a C# program rather than Visual Studio? Ideally this solution would attach to a specified process and output the result of !dumpheap -stat to a text file without the need for automating Visual Studio.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Below I will present some different approaches you can use to find your leaks.

    (there are commercial “leak” detectors available should you not wish to follow the DIY approach).

    Link to my answer detailing lots of debugging tools/resources

    Load SOS.DLL into WinDBG

    You actually don’t need Visual Studio to use SOS.DLL….it’s a debugger extension so can be used in WinDBG too.

    You can get the WinDBG Debugger free as part of the Debugging Tools for Windows.

    You could then write a WinDBG script to automate your “dumps”.

    Also be aware, there are enhanced versions of SOS.DLL available…look for SOSEX, PSSCOR2 (for NET 2), and PSSCOR4 (for NET 4).

    CLR Profiling API

    You can use the CLR Profiling API.

    There’s an application called CLRProfiler which is an actual .NET profiler that makes use of it….so a good bit of code to see how it’s used.

    One of the things CLR Profiler can do is allow heap dumps to be made and then compare those dumps made at different time periods, to find the differences…and thus help find leaks.

    You could provide similar functionality to your application when in a “test” mode (either embedded in the application, or as a companion utility to monitor it).

    Process Dumps

    Another technique you can use is to take periodic “dumps” of your process, which you can then analyze offline via WinDBG with SOS/SOSEX (or any other WinDBG plugin).

    You can use DebugDiag (you can set up rules and actions to control when .dmp files are created) to automate the creation of .dmp files….or a tool called ProcDump.exe (from SysInternals).

    ProcDump is particularly useful because it is able to take the “process snapshot” very quickly because it uses a technique called “Process Reflection”….this enables your process to be interrupted less aggressively e.g.

    (create 3 dumps with 5 seconds gap between each one)

    procdump -s 5 -n 3 notepad.exe notepad.dmp

    Post-Mortem Analysis

    After you have a set of .dmp files you can then analyze them to find leaks, monitor handle usage, etc.

    You can manually load the .dmp files in WinDBG and then issue debugger commands, or you could write a WinDBG extension or maybe a script which took the set of dump files and processed them in turn (i.e. ran the !dumpheap stat command on them).

    Debug Analyzer .NET

    This is a tool aimed at analyzing .dmp files and doing post-mortem analysis.

    It lets you write scripts in .NET so is maybe more accessible than WinDBG.

    It also has a plugin model if you want to extend it.

    And it lets your write/use Visualizers to view the data in unique ways.

    (currently only supports CLR 2.0 memory dumps…not CLR 4.0)

    • 0