DOTNET: Understanding Memory leaks and Debugging using dotMemory

I’ll give you:

1. One self-contained Program.cs you can drop into a new project
2. How to run it from command line
3. Step-by-step: how to use dotMemory to detect the leak
4. How to read dotMemory results & locate the leak
5. How to fix it (clean version of the code)

1️⃣ Create the demo app

dotnet new web -n MemoryLeakDemo
cd MemoryLeakDemo
Code language: JavaScript (javascript)

Now replace the entire Program.cs with this:

This is self-sufficient: one file, no extra classes, no extra projects.

2️⃣ Run the app (command line)

From the MemoryLeakDemo folder:

dotnet run

It will listen on something like:

• http://localhost:5000
• https://localhost:5001

(Use the HTTP one for simplicity: http://localhost:5000)

3️⃣ Generate the leak

In another terminal (or browser / Postman):

A. Start leaking memory

Run a loop (PowerShell):

1..50 | ForEach-Object {
    curl "http://localhost:5000/leak"
}
Code language: JavaScript (javascript)

Or Git Bash:

for i in {1..50}; do curl -s "http://localhost:5000/leak" > /dev/null; done
Code language: JavaScript (javascript)

Then check stats:

curl "http://localhost:5000/stats"
Code language: JavaScript (javascript)

You should see Total stored MB growing (e.g. 250 MB).

B. Compare with non-leaking allocations

1..50 | ForEach-Object {
    curl "http://localhost:5000/noleak"
}
curl "http://localhost:5000/gc"
curl "http://localhost:5000/stats"
Code language: JavaScript (javascript)

• /noleak allocates memory but does not store it → GC can clean it.
• /leak allocates memory and keeps it in a static list → cannot be GC’d.

4️⃣ Profile with dotMemory – step by step

Assuming you have dotMemory GUI (Rider/Standalone):

Step 1: Start the app

Make sure dotnet run for MemoryLeakDemo is running.

Step 2: Open dotMemory

• Start dotMemory
• Choose “Profile Running Process” (or similar wording)
• Select the dotnet.exe / MemoryLeakDemo.dll process
• Click Run / Attach

Step 3: Take a baseline snapshot

In dotMemory:

• Click “Get Snapshot” (or “Get Snapshot #1”).
• Name it “Baseline (before leak)”.

Step 4: Generate the leak

Back in terminal:

1..100 | ForEach-Object {
    curl "http://localhost:5000/leak"
}
curl "http://localhost:5000/stats"
Code language: JavaScript (javascript)

You should see big total MB stored.

Step 5: Take snapshot after leak

In dotMemory:

• Click “Get Snapshot” again.
• Name it “After leak (static list)”.

Step 6: Optionally, force GC and snapshot

Back in terminal:

curl "http://localhost:5000/gc"
curl "http://localhost:5000/stats"
Code language: JavaScript (javascript)

Then in dotMemory:

• Take Snapshot #3: “After GC”.

5️⃣ Understanding dotMemory results (how to spot the leak)

Now the fun part: reading dotMemory.

A. Compare snapshots (Baseline vs After leak)

1. In dotMemory, select “Baseline” and “After leak” snapshots.
2. Click “Compare Snapshots”.

Look at:

• Heap size increased a lot
• New objects count is huge
• Top types by size will likely show System.Byte[] (byte arrays)

B. Drill into byte[] and find retention

Click on System.Byte[] and open:

• “Retention Graph”
• or “Shortest Paths to GC Roots”

You should see a path like:

Static field → LeakStore.Buffers → List<byte[]> → byte[]
Code language: CSS (css)

This tells you:

• The byte[] objects are alive because they are referenced by a static list.
• That static list is LeakStore.Buffers.

This is your memory leak.

C. Check what happens after GC

Compare “After leak” vs “After GC” snapshots:

• If byte[] objects are still around in large numbers/size → GC cannot free them.
• Why? Because they’re still referenced by LeakStore.Buffers.

That is exactly how dotMemory exposes real leaks:

Objects survive GCs and are retained by long-lived references (statics, singletons, caches, events, etc.).

6️⃣ Common real-world patterns similar to this leak

• Static lists/dictionaries that grow but never shrink
• Caches without eviction policies
• Event handlers where you forget to -= unsubscribe
• Long-lived singletons holding request-scoped data
• Task or Timer callbacks closing over large objects
• In-memory queues that never get drained

dotMemory will show all of these as:

• Big retained size
• GC roots pointing to static fields, singletons, or event tables

7️⃣ How to fix this leak (clean code version)

Here’s a fixed version of the leak part:

Option A: Limit the cache

static class LeakStore
{
    private const int MaxBuffers = 10;
    private static readonly Queue<byte[]> Buffers = new();

    public static void AddBuffer(byte[] buffer)
    {
        Buffers.Enqueue(buffer);
        while (Buffers.Count > MaxBuffers)
        {
            Buffers.Dequeue(); // old buffers become eligible for GC
        }
    }

    public static int Count => Buffers.Count;
}
Code language: PHP (php)

Then in /leak:

var buffer = new byte[bytes];
// ...
LeakStore.AddBuffer(buffer);
Code language: JavaScript (javascript)

Now dotMemory will show:

• Heap size not growing unbounded
• Byte arrays being collected over time

Option B: Don’t use static leaks at all

• Use scoped dependencies
• Avoid unbounded global collections
• Use proper cache with TTL / LRU (e.g., MemoryCache)

8️⃣ In-Code Metrics (like we did for TLS)

For this example, /stats already gives:

• Number of stored buffers
• Total MB stored
• Number of leak calls

You can show this in the terminal while dotMemory shows heap graph growth → this connects code behavior + profiler view.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.