Memory leaks are usually caused by inappropriate event handlers and static references, checking and canceling unnecessary subscriptions to avoid storing large objects in static classes. Use weak references to allow garbage collection. Monitor Windows performance counters such as private bytes, .NET CLR memory, and available memory, capture memory snapshots to analyze object retention. Configure periodic recycling of IIS application pools, set memory-limited recycling policies, and enable overlapping recycling to reduce downtime. Review long-running requests or background threads, make sure the task is cleaned correctly after completion, terminate the operation with a cancel token, and check for known leaks in the third-party library.

Memory leaks in IIS application pools can quietly eat away at server resources, eventually leading to performance degradation or even crashes. They're often tricky to spot because the symptoms—like graduate memory usage increases or occasional timeouts—can look like normal load issues. But if your app pool keeps growing in memory usage over time and never releases it, you might be dealing with a leak.

Check for Common Causes Like Event Handlers and Static References

One of the most common sources of memory leaks is improper handling of events and static objects. If your application subscribes to events but doesn't unsubscribe, or holds onto large objects in static variables, those references can prevent the garbage collector from cleaning up memory.

• Make sure event handlers are unsubscribed when no longer needed.
• Avoid storing large objects or collections in static classes unless absolutely necessary.
• Use weak references where appropriate to allow garbage collection.

A classic example is caching data in a static dictionary without any evidence policy—over time, this can consume more and more memory without ever releasing it.

Monitor Performance Counters and Use Debugging Tools

To confirm a memory leak, start by watching performance counters in Windows. Key metrics include:

• Private Bytes – shows how much memory the process is using.
• .NET CLR Memory – # Bytes in all Heaps – give insight into .NET memory usage.
• Available MBytes – tracks how much physical memory is free on the server.

If you see private bytes climbing steady while the app is under load, that's a red flag. From there, use tools like PerfMon , DebugDiag , or Visual Studio Diagnostic Tools to take memory dumps and analyze object retention.

• Capture multiple memory snapshots over time.
• Look for types that are increasing unexpectedly in count.
• Pay attention to object roots holding onto memory (especially static fields).

Review Application Pool Recycling Settings

Sometimes, what looks like a memory leak is actually just expected behavior that's not being reset. IIS application pools can be configured to recycle periodically, which resets memory usage. If recycling isn't enabled or is set too far apart, memory usage may grow unchecked until the app pool restarts.

• Set regular recycling intervals (eg, every 12 or 24 hours).
• Consider configuring recycling based on memory limits if you know a healthy max threshold.
• Be aware that recycling will cause some downtime for in-process requests unless overlapped recycling is enabled.

This won't fix the leak itself, but it helps manage impact and give you a clearer pattern to monitor between recycles.

Watch Out for Long-Lived Requests or Background Threads

Some applications use background threads or long-running async operations—like polling loops or SignalR connections—that can inadvertently hold onto memory. These threads may cache data or maintain state indefinitely, especially if they're not properly distributed of or stopped when no longer needed.

• Track down threads that run continuously and review their memory usage.
• Ensure background tasks clean up after themselves.
• Consider using cancellation tokens to gracefully terminate long-lived operations.

It's also worth checking if third-party libraries or frameworks used in your app have known memory leak issues—sometimes the problem isn't in your code at all.

Memory leaks in IIS app pools aren't always obvious, but once you start looking at event handlers, static references, performance counters, and background operations, patterns usually emerge. The key is to gather enough data over time to distinguish real leaks from normal usage spikes.

The above is the detailed content of Diagnosing Memory Leaks Within IIS Application Pools. For more information, please follow other related articles on the PHP Chinese website!