Huge burst of memory in c# service, what could be the cause?

Question

I'm working on a c# service application and i have this problem where out of no where and for no obvious reason, the memory for the process will climb from 150mb to almost 2gb in about 5 seconds and then back to 150mb. But nothing in our system should be using any where near that amount of memory (so its probably a bug somewhere). It might be a tight while true loop somewhere but the cpu usage at the time was very low so i thought i'd look for other ideas.

Now the weirder thing is when i compile the service for 64bit, the same massive burst will occur except it exceeded 10gb of ram (paging most of it) and it just caused lots of problems with the computer and everything running on it. After a while it shuts down but it looks like windows is still willing to give it more memory.

Would you have any ideas or tools that i can use in order to find this? Yes it has lots of logging however nothing in the logs stand out as to why this is happening.

I can run the service in a console app mode, so my next test was going to be running it in visual studio debugger and see if i can find anything.

It only happens occasionally but usually about 10-20 minutes after startup. On 32bit mode it cleans up and continues on like normally. 64bit mode it crashes after a while and uses stupid amounts of memory. But i'm really stumped as to why this is happening!!!

EDIT: Please see the commends to the windbg post

Answer 1

You could try a profiler, like the CLRProfiler, a free download from MS (it's pretty cool). It can profile services. Run it until you see the memory spike, then stop it and look at the heap dump.

Answer 2

You are doing a lot of allocation that then you release. Your memory builds up, until the GC kicks in and start cleaning after you. On amd64 platforms all structures are larger since pointers, v-tables and other structures are inherently double in size compared to x86.

The simplest solution is to run with the application under debugger and wait for the bulge, then freeze it and take a dump. Then analyze the dump:

.loadby sos mscorwks
!dumpheap -stat

Your leaked type will be on the top of the list, with lots of allocations. This is the same technique you'd use to analyze a memory leak, except that the memory is probably technically not leaked, see CLR Memory Leak.