8 C# Memory Leaks You Didn’t Know You Were Writing

The Hidden Cost of Memory Leaks in Managed Code

As a senior consultant specializing in .NET performance, I've seen countless production incidents traced back to memory leaks that developers never suspected. The common belief is that the garbage collector (GC) automatically prevents leaks in C#, but the reality is more nuanced. While the GC does reclaim unreachable memory, it cannot free objects that are still referenced—even if those references are no longer needed. This leads to gradual memory exhaustion, increased GC pressure, and eventually application crashes or severe slowdowns. Many teams discover these issues only after deploying to production, where user load amplifies the problem.

Why Developers Miss These Leaks

Most C# developers rely on weak references or assume that once an object goes out of scope, it is collected. However, hidden references—such as captured variables in closures, event handlers, or static collections—keep objects alive indefinitely. In one engagement, a financial trading application experienced a 5 GB memory growth over 48 hours. The root cause was a static list that accumulated event subscribers from short-lived UI windows. Each window opened added a new event handler, and because the list was static, none of the windows could be collected. The team had assumed events were automatically unsubscribed, but without explicit removal, the references persisted.

The Business Impact

The cost of these leaks extends beyond performance degradation. In cloud environments, memory pressure triggers scaling events, increasing infrastructure costs. For on-premises systems, leaks can lead to unplanned downtime, affecting service-level agreements. In one healthcare project, a memory leak caused nightly batch jobs to fail, delaying patient data processing by hours. The fix was simple—unsubscribing from events—but the diagnosis took weeks because the leak was intermittent and only appeared under specific load patterns.

This guide walks through eight specific leak patterns that even experienced developers often overlook. Each pattern includes a realistic code sample, an explanation of why it causes a leak, and a concrete solution. By understanding these patterns, you can proactively audit your codebase and avoid the subtle traps that lead to memory bloat.

Captured Variables in Closures: The Lambda Trap

Closures and lambda expressions are a hallmark of modern C#, enabling functional patterns and LINQ queries. However, they introduce a subtle memory leak when a lambda captures a variable that keeps a large object graph alive. The compiler generates a class to hold captured variables, and the lambda becomes a delegate referencing that class instance. If the delegate is long-lived (e.g., stored in a static field or an event), the captured object stays alive as long as the delegate exists. This is common in caching scenarios, background tasks, and UI event handlers where lambdas are passed to third-party libraries.

A Realistic Example

Consider a method that processes large data sets and uses a lambda to filter results. The lambda captures a local variable referencing a DataTable. If the lambda is stored in a static collection for reuse, the DataTable cannot be collected even after the method returns. In a project for an e-commerce platform, such a pattern caused memory to grow by 200 MB per hour during peak traffic. The team had cached filter predicates to avoid recomputation, but the captured variables included entire product catalogs. The fix was to avoid capturing large objects or to clear the cache periodically.

How to Detect and Fix

Detecting captured variable leaks requires profiling tools like dotMemory or PerfView that can show the size of closure objects. Look for instances of DisplayClass types (compiler-generated) that hold large fields. One mitigation is to move captured variables to a separate class and implement IDisposable to release references explicitly. Another is to use static lambdas that do not capture any variables, which avoids closure allocation altogether. For cases where capture is unavoidable, ensure the delegate's lifetime is limited—for example, by unsubscribing from events or clearing static collections.

In your own code, review any lambda that is stored in a field, passed to an event, or used in a Task that runs indefinitely. Ask yourself: what does this lambda capture? If the captured variables are large or numerous, consider refactoring to a method group or a separate class. This simple audit can prevent a class of leaks that are notoriously hard to reproduce because they depend on runtime closure behavior.

Event Handlers That Never Unsubscribe

Event handler leaks are arguably the most common memory leak in C#. When an object subscribes to an event on a long-lived publisher, the publisher holds a reference to the subscriber through the delegate. If the subscriber goes out of scope in application logic but the event is not explicitly unsubscribed, the subscriber remains rooted and cannot be collected. This is particularly dangerous in UI applications where user controls subscribe to static or singleton events. Over time, every opened window, button, or custom control accumulates, leading to massive memory consumption.

Patterns That Cause Leaks

Three common patterns lead to event handler leaks. First, subscribing to static events from instance objects: the static event holds a reference to the instance, preventing collection. Second, subscribing to events in constructors or initialization methods without a corresponding unsubscribe in Dispose. Third, using anonymous methods or lambdas as event handlers, making it syntactically hard to unsubscribe later. In a desktop application for a logistics company, every time a user opened a shipment detail window, it subscribed to a static DataChanged event. After hundreds of window opens, memory usage exceeded 2 GB and the application became unresponsive.

Best Practices to Avoid Leaks

The most reliable fix is to always unsubscribe from events when they are no longer needed. Implement IDisposable and in the Dispose method, use -= to remove the handler. For anonymous handlers, store the delegate in a variable so you can unsubscribe later. Alternatively, use weak event patterns: the WeakEventManager in WPF or the WeakReference approach allows the subscriber to be collected even if the publisher still holds a reference. However, weak events add complexity and may affect performance for high-frequency events.

Another approach is to avoid long-lived publishers. If possible, use short-lived event sources that are disposed together with subscribers. In ASP.NET Core applications, scoped services can subscribe to singleton events—this is a leak waiting to happen. Prefer using message buses or channels that do not hold strong references to subscribers. Audit your codebase for static events and ensure every subscription is paired with an unsubscribe. This is a simple rule that, if followed consistently, eliminates a major category of leaks.

Static Collections That Grow Without Bound

Static collections are convenient for caching, registries, or singleton services, but they are also a frequent source of memory leaks. Any object added to a static collection is rooted and cannot be collected until the application domain unloads. Over time, the collection grows as new entries are added without a corresponding removal strategy. This is especially problematic when the collection stores large objects or objects that hold references to other resources. Common examples include static List<T> used for event aggregation, static Dictionary for caching user sessions, and static ConcurrentBag for pooling.

Why Developers Use Them

Developers often choose static collections for convenience—they avoid dependency injection overhead, provide global access, and seem harmless for small data sets. The problem arises when the data set size is unbounded. In one case, a team used a static Dictionary<int, byte[]> to cache uploaded file thumbnails. The cache never expired, so memory grew with every upload until the server ran out of memory. The team had assumed the cache would stay small because users only uploaded a few files, but over months, the total grew to millions of entries.

Mitigation Strategies

To prevent unbounded growth, use collections with built-in eviction policies. MemoryCache from System.Runtime.Caching supports absolute and sliding expiration, as well as cache limits. For custom collections, implement a removal strategy: remove least recently used items, limit the maximum size, or clear the collection on a timer. Another option is to use WeakReference collections, such as ConditionalWeakTable, which does not prevent garbage collection of keys. However, weak references have their own trade-offs, including increased GC complexity.

When you must use a static collection, document its expected lifetime and size. Add logging to monitor its count over time. In production, set up alerts for when the count exceeds a threshold. If the collection is a cache, ensure that items are removed when they are no longer needed. In ASP.NET Core, prefer IMemoryCache over static dictionaries, as it integrates with the framework's memory management and expiration policies. Avoid storing user-specific data in static collections; instead, use session state or distributed caches that can scale and evict automatically.

Improperly Disposed DataContexts in Entity Framework

Entity Framework (EF) DataContexts (or DbContexts in EF Core) are designed to be short-lived, but a common mistake is to hold a reference to them beyond their intended scope. A DataContext tracks all entities it has loaded, keeping them in memory. If the context is not disposed, these tracked entities remain referenced, preventing garbage collection. This is especially dangerous in long-running operations such as background services, where a single DbContext instance is reused for many queries. Over time, the change tracker accumulates thousands of entity instances, causing memory to balloon.

The Root Cause

The DbContext's change tracker stores references to every entity it has ever loaded, unless you disable change tracking or use AsNoTracking(). Even if the entities are no longer needed, the context holds them alive. In a web API, if you inject a DbContext as a singleton, it will grow unbounded as requests come in. In a desktop application, a DataContext kept open for the lifetime of a form can cause memory to increase with every data load. A team working on a reporting application saw memory increase by 50 MB per report generation because they reused a single DataContext for the entire application session.

Best Practices

Always use dependency injection to create DbContext instances with a scoped lifetime. In ASP.NET Core, the default is scoped, meaning a new context is created per request. For desktop applications, create a new DataContext for each logical unit of work and dispose it when done. Use using blocks to ensure disposal, even if exceptions occur. For read-only queries, always call AsNoTracking() to bypass the change tracker. In background services, create a new DbContext for each operation and dispose it promptly.

If you must keep a context alive for multiple operations, periodically call ChangeTracker.Clear() to detach all tracked entities. This releases the references while keeping the context open. However, be aware that clearing the change tracker loses pending changes, so do it only after saving or discarding changes. Monitor memory usage with a profiler to ensure that the context is not holding onto stale entities. In production, log the number of tracked entities to detect anomalies early.

Async Local and AsyncLocal Holding References

AsyncLocal is a thread-agnostic storage mechanism that flows values across asynchronous control flows. While useful for passing context like correlation IDs, it can cause memory leaks if the stored object holds references to large data. The AsyncLocal's value is stored in the execution context, which can be captured and reused by thread pool threads. If a large object is stored in AsyncLocal and the execution context is not cleaned up, that object remains referenced as long as the context is alive. This is a particularly insidious leak because it manifests only under async patterns and can be hard to reproduce.

How Leaks Occur

Consider a middleware that stores the current user's data (including roles, permissions, and profile) in an AsyncLocal for the duration of a request. In ASP.NET Core, this works fine per request. However, if the AsyncLocal value is not cleared after the request ends, and the execution context is reused by another asynchronous operation (e.g., a background task), the user data stays alive. In one incident, a developer stored a large byte array in AsyncLocal for logging purposes. The array was not cleared after the log was written, and because the execution context was captured by a thread pool thread, memory usage grew linearly with concurrent requests.

Detection and Mitigation

To detect AsyncLocal leaks, use memory profiling to look for instances of ExecutionContext or AsyncLocalValueMap that hold large references. The fix is to always clear AsyncLocal values when they are no longer needed, preferably in a finally block. In ASP.NET Core, use the IAsyncLocal<T> interface or ensure that your middleware clears the value at the end of the pipeline. For custom async workflows, explicitly set the AsyncLocal to null after the operation completes.

Another mitigation is to avoid storing large objects in AsyncLocal altogether. Instead, store lightweight identifiers and retrieve the full data from a cache or database when needed. If you must store large objects, consider using WeakReference or a scoped container that can be disposed. Review your code for any use of AsyncLocal and ensure that the stored values are not inadvertently kept alive across asynchronous boundaries. This is a small investment that can prevent a class of leaks that often go unnoticed until production.

Finalization Queue Buildup from Uncollected Objects

Objects that implement a finalizer (destructor) are handled differently by the GC. When such an object becomes unreachable, it is not immediately collected; instead, it is placed on the finalization queue. The finalizer thread runs these finalizers one by one, and only after a finalizer completes is the object eligible for collection. If finalizers are slow or if many objects with finalizers are created quickly, the finalization queue can grow, consuming memory. Furthermore, objects that are never finalized (e.g., because the finalizer throws an exception) may remain on the queue indefinitely, causing a permanent leak.

Common Scenarios

Classes that wrap unmanaged resources (file handles, database connections, GDI+ objects) often implement finalizers as a safety net. However, developers sometimes forget to call Dispose(), relying on the finalizer to clean up. But if the finalizer is slow—for example, it makes a network call—it can delay collection. In a high-throughput application, even a 1 ms finalizer per object can cause the finalization queue to grow faster than it can drain. A team building a video processing pipeline saw memory increase by 100 MB per minute because each frame created a new object with a finalizer that performed a Marshal.Release call. The finalizer thread could not keep up, and the queue grew without bound.

How to Prevent This

The best defense is to avoid finalizers unless absolutely necessary. Implement the IDisposable pattern with a finalizer only as a last resort. Ensure that Dispose() is called promptly, and use using blocks for all disposable resources. If you must have a finalizer, keep it short and avoid any blocking operations. Offload cleanup to a dedicated thread if needed. Consider using SafeHandle for unmanaged resources, which is already optimized for finalization.

If you suspect a finalization queue buildup, use a profiler to monitor the number of objects waiting for finalization. In PerfView, you can enable GC events to see the queue size. Another diagnostic is to log the time spent in finalizers. If the finalizer thread is consuming CPU, it's a sign that finalizers are too slow. In some cases, you can call GC.WaitForPendingFinalizers() during idle periods to force the queue to drain, but this is a workaround, not a solution. The real fix is to reduce the number of finalizable objects and ensure they are disposed deterministically.

LINQ Closures Capturing Disposed Resources

LINQ queries often use closures to capture local variables, including disposable resources like file streams, database connections, or network sockets. If the query is executed lazily (deferred execution), the captured resource may be disposed before the query actually runs. But even if the resource is not yet disposed, the closure keeps a reference to it, preventing collection until the query is garbage collected. This can lead to situations where a stream is left open longer than necessary, tying up file handles or database connections.

A Concrete Example

Imagine a method that reads a file and returns a LINQ query that processes lines. The method opens a StreamReader and captures it in a lambda used by Select. The method then returns the query without closing the stream. The caller may iterate the query later, but the stream remains open until the query is collected. In a service that processes hundreds of files per minute, this pattern can exhaust file handles. In one project, a developer used a MemoryStream inside a LINQ Where clause that was captured by a static predicate. The MemoryStream was never disposed, and memory grew because the stream's buffer was held by the closure.

Detection and Solutions

To detect such leaks, look for LINQ queries that capture IDisposable objects. Review deferred queries that are stored as fields or returned from methods. The fix is to avoid capturing disposable resources in closures. Instead, materialize the query with ToList() or ToArray() before the resource is disposed. For stream processing, read the data into a collection first, then close the stream. Alternatively, use IEnumerable with a using block that ensures disposal even with lazy evaluation—but be cautious: if the query is executed outside the using block, the resource may already be disposed.

Another approach is to use System.Reactive (Rx) for stream-based processing, which handles resource lifetime more cleanly. In general, treat LINQ closures as potential leak sources whenever they capture objects that implement IDisposable. Add code reviews that flag such patterns. With practice, you'll learn to spot these closures and refactor them to safer patterns.

String Interning and Large String Tables

String interning is a CLR optimization that stores one copy of each unique string literal. While this saves memory for repeated literals, it can cause a leak if you dynamically intern strings. The intern pool is a hash table that lives for the lifetime of the application domain. If you call string.Intern() on dynamically generated strings (e.g., from user input, XML parsing, or serialization), those strings remain in the pool forever. Over time, the pool can grow to enormous size, especially if the input strings are unique.

When This Becomes a Problem

In a logging system that interns log messages to reduce memory, the team noticed that after a week of operation, the application's private bytes had grown by 500 MB. Investigation revealed that string.Intern() was called for each unique log message, and since messages were mostly unique, the intern pool grew unbounded. The same issue can occur in deserialization libraries that intern property names, or in caching layers that intern keys. Even if the interned strings are small, millions of them can consume significant memory.

How to Avoid String Intern Leaks

The simplest rule is: never use string.Intern() for strings that are not compile-time constants. If you need to deduplicate strings, consider using a custom dictionary with weak references or a bounded cache. The StringDispenser class from some libraries provides a pool that can be cleared. Alternatively, use string.IsInterned() only for known literals. For dynamic strings, rely on the natural deduplication that may occur due to string interning of literals, but do not force it.

If you must intern strings for performance reasons, monitor the intern pool size using performance counters (e.g., \.NET CLR Memory\# Bytes in all Heaps). Set a limit on the number of interned strings and clear the pool periodically by recycling the AppDomain or using AppDomain.Unload(). In .NET Core, you can use MemoryCache with a string key to achieve deduplication without leaking. Remember that interning is a trade-off: it saves memory for duplicates but costs memory for unique strings. Understand your data distribution before deciding to intern.

Frequently Asked Questions About C# Memory Leaks

In my consulting work, I encounter recurring questions from developers trying to understand and fix memory leaks. Here are answers to the most common ones, based on practical experience.

Can the garbage collector always reclaim memory eventually?

No. The GC can only reclaim memory that is not reachable from any root. If an object is still referenced—even indirectly—by a static field, a running thread, or an event handler, it remains in memory indefinitely. The GC does not detect logical leaks; it only handles physical unreachability.

How can I tell if my application has a memory leak?

Monitor memory usage over time. If it increases steadily and never drops back to a baseline, you likely have a leak. Use performance counters (e.g., \.NET CLR Memory\# Bytes in all Heaps) or a profiler like dotMemory to examine object graphs. Look for objects that should have been collected but are still present.

What are the best tools for diagnosing memory leaks?

dotMemory, PerfView, and Visual Studio Diagnostic Tools are excellent. For production, use memory dumps with WinDbg or dotnet-dump. Always start by examining the largest objects and then trace their reference chains back to a root.

Is it safe to rely on weak references to avoid leaks?

Weak references can help, but they are not a panacea. They add overhead and can cause objects to be collected prematurely if you are not careful. Use them for caches or event handlers, but ensure your code handles the case where the target has been collected.

Should I implement IDisposable even if I don't use unmanaged resources?

Yes, if your class holds references to other disposable objects (e.g., a stream, a database connection, or a timer). By implementing IDisposable, you give callers a deterministic way to release those resources, which can prevent cascading leaks.

What is the biggest mistake developers make?

The most common mistake is assuming that the GC handles everything. Developers often ignore event unsubscription, fail to dispose contexts, or store objects in static collections without eviction policies. A proactive memory management mindset is essential.

Putting It All Together: A Framework for Leak-Free Code

We've covered eight distinct memory leak patterns that can silently degrade your application's performance. The common thread is that each leak stems from a reference that outlives its intended use. By internalizing these patterns, you can adopt a defensive coding style that minimizes the risk of leaks. Start by auditing your codebase for static collections, event subscriptions, and captured variables. Use profiling tools regularly, especially after major refactors. Implement code review checklists that include memory leak patterns.

Beyond the individual fixes, consider adopting a broader memory management strategy. Use dependency injection to control object lifetimes, prefer scoped services over singletons, and avoid caching large objects indefinitely. Educate your team about the pitfalls of closures and AsyncLocal. Set up monitoring for memory usage in production and automate alerts for abnormal growth. With these practices, you can transform memory leak detection from a reactive firefight to a proactive discipline.

Remember, memory leaks in C# are not inevitable. They are the result of specific, avoidable patterns. By staying vigilant and applying the solutions outlined here, you can write code that is both efficient and robust. Start with one pattern today—event handlers are a good place to begin—and gradually expand your coverage. Your users (and your operations team) will thank you.