Memory Leak Issue in .NET/C# Application
Hi @everyone,|
I’m running into a problem with memory leaks in my .NET/C# application. Over time, the app’s memory usage keeps increasing, and performance drops until it eventually slows down or crashes.
I suspect it might be related to unreleased resources like open database connections, file streams, or event handlers not being unsubscribed properly.
Has anyone faced a similar issue?
13 Replies
Yes. You'll want to use a tool like Process Explorer to look at things like handle count, and take a memory dump (or live debug it) to see if there are a lot of allocated objects not getting GC'd, etc.
Memory going up does not necessarily indicate a problem (GC will hold onto memory and not release it back to the OS until there is true memory pressure), but if performance is dropping and it crashes, that indicates a bug for sure.
I would use a tool like
windbg personally but if you aren't familiar with it it has kind of a steep learning curve. (https://learn.microsoft.com/en-gb/windows-hardware/drivers/debugger/)Install WinDbg - Windows drivers
Start here for an overview on the Windows debugger and installing WinDbg.
That makes sense - thanks for clarifying! I didn’t realize GC might retain memory until there’s actual pressure, so that helps explain part of what I’m seeing.
Since the app’s performance still drops before crashing, I’m thinking it might be a real leak or object retention issue.
Would you recommend checking GC heap snapshots or using something like dotMemory / WinDbg to confirm which objects aren’t getting released?
Also, is there a good way to tell from the memory dump whether it’s GC delay behavior vs. an actual leak?
I’ve heard of WinDbg but never really used it in-depth. I’ll look into it and maybe start with some tutorials to get familiar.
I've been using it since the 90s 😄
It has some very useful extensions for debugging managed code via the sos.dll add-in.
You can also use Visual Studio, it's probably more user-friendly - I am just used to windbg personally.
Nice, good to know about the sos.dll extension! I’ll probably start with Visual Studio first and then move to WinDbg once I get the hang of it.
Is there a specific scenario where WinDbg gives you insights that VS can’t?
There are some things I only know how to do in windbg. For instance, dumping the current GC settings with:
There's probably a way to do that in VS but I don't know how.
There are other extensions like
!finalizequeue that I don't know how to inspect in VS.Oh wow, that’s cool - didn’t know about that command! I’ll definitely give it a try once I get WinDbg running.
Do you mostly use it to spot objects stuck in finalization, or just to get a clearer GC picture overall?
The main ones I use to start investigating are:
...that gets you your managed heap info into a text file for later inspection.
and then
That gets all of the mixed managed and native call stacks across all threads into a separate file.
I start with that and then go from there.
Awesome!
That last one is specialized for finding issues with finalization, honestly I don't use it much. I just know it exists.
Ah, that makes sense
Mario Hewardt, an ex-colleague of mine, wrote a very good book called Advanced .NET Debugging that covers a lot of this. It's a little long in the teeth these days and was focused on .NET Framework, but it's still an excellent resource if you want to dig into more hard-core debugging of these kinds of things.
Thanks for the recommendation!
I really enjoyed our discussion today