.NET application experiences sudden an extreme growth of unmanaged memory

I'm running an application that exhibits some very peculiar issues. It runs just fine for around 2.5 hours, then suddenly unmanaged memory begins to grow, and grow quickly. Within around another half an hour or so the app crashes.

The application is not using any unmanaged DLLs. It is communicating with an external application. It's writing with a socket (used via a Stream) and reading through a WCF stream.

I profiled it with ANTS. The sudden change in unmanaged memory utilization is very striking; it stays perfectly flat forever, then suddenly starts to ramp up and continues to do so at a steady rate until the application fails. Nothing in managed memory appears to be out of place.

Given that I'm not intentionally using unmanaged code, it's difficult to pin down where the leak is coming from. ANTS is no help. It's hard to scrub the code for issues when it's not a steady increase from the start (the app sits idle all this time, although it doe开发者_JAVA技巧s ping it's server once per second over the socket with a very small bit of data).

To re-iterate, the application and the server are both idle during this time; this is running on an isolated test system (both server and client). The client is the one that is leaking.

---

You'll probably want to use DebugDiag to monitor for memory leaks and provide information as to what was allocated, how much, and from what call stacks. In short:

Soon after the process has started (or been restarted) do the following:

1. Open DebugDiag.
2. Cancel out of the wizard.
3. Go to the Processes tab.
4. Right-click on the desired process.
5. Choose Monitor For Leaks.
6. Click OK.

After the process has been running for a while, and the memory issue is evident:

1. Go to DebugDiag
2. If it was not still open, Cancel out of the wizard.
3. Go to the Processes tab.
4. Right-click on the same process as part #1.
5. Choose Create Full Userdump.
6. Make note of the location of the dump.

Also, if the process is restarted before the memory dump is captured, the leak monitoring will have to be re-enabled.

Once you have the dump:

1. Go to DebugDiag.
2. Go to the "Advanced Analysis" tab.
3. Select the "MemoryAnalysis.asp" script up top.
4. Click "Add Data Files" at the bottom and choose the dump created previously.
5. Click "Start Analysis" and look over the results.

Once you have that information, you should be able to determine where the memory allocations are coming from, and hopefully the cause of your issues.

You can find more information from the following resources:

• http://blogs.msdn.com/b/tess/archive/2010/01/14/debugging-native-memory-leaks-with-debug-diag-1-1.aspx
• http://www-01.ibm.com/support/docview.wss?uid=swg21307645

---

We eventually found the problem. It turned out that we had a socket connection between the two, and during the idle phase we'd send a KeepAlive packet to keep the listener from auto-disconnecting. However, after sitting idle for a certain amount of time, through some peculiar timeouts with WCF, the socket was being closed server side.

So basically every time the DispatchTimer fired, the keep-alive packet would get written to the socket, but apparently it would block. This would not stop the next DispatchTimer from doing exactly the same thing. Although it seemed like it was something larger, those small packets were rapidly building up and eating all of the unmanaged memory, I presume the buffer for the socket (I believe we were using NetworkStream for the connection). With a few shifts in logic the issue went away.

Thanks for all the input though, it was greatly appreciated!