How to capture a process memory dump in a .NET process when .NET is not in the middle of a garbage collection (GC)

When I capture a dump file and analyze it (for example, in WinDbg), I often get a warning that the data may be inaccurate or the commands may not be available, because this process was in the middle of the GC when the dump file was collected.

When analyzing memory, we often do this because the memory in the process is high and the high memory pressure is high, which, I believe, often causes .NET for GC.

How to avoid dumping during GC? Is there a way to find out when it is safe to write a dump file?

+7
garbage-collection c # memory-leaks dump
source share
1 answer

I'm not an expert in this area, but I noticed that you can use the .NET runtime performance counters to monitor some interesting things - one of them is the number of bytes that the garbage collector allocated during this latest collection. A description of Allocated Bytes/second in Performance Counters in the .NET Framework states:

Displays the number of bytes per second allocated on the garbage heap. This counter is updated at the end of each garbage collection, and not at every disposal. This counter is not an average over time; it displays the difference between the values โ€‹โ€‹observed in the last two samples divided by the length of the sampling interval.

According to my tests, if you set the performance monitor refresh interval to 1 second and look at the indicator for Allocated Bytes/second , it seems to show a value of 0 after the collection is complete. Therefore, I would suggest that you can get from this value whether the collection is running or not.

I tested it by building a small application in VS 2015 that has the ability to show if there is garbage collection. The indicator value was different from 0, if it was.

Refresh (thanks to Thomas)

You can use ProcDump to monitor the performance counter and automatically dump. The correct way to do this is: procdump ProcessName -s 1 -ma -pl "\.NET CLR Memory(ProcessName)\Allocated Bytes/second" 1000 , which will cause a dump if the value drops below a thousand.

This should work as the value is zero if garbage collection does not occur.

If you are not working with the English version of the operating system, you will need to find out the correct name of a specific performance counter (this can be done by looking at the above MSDN link and switch to another language there). For example. German name be "\.NET CLR-Speicher(ProcessName)\Zugeordnete Bytes/Sek." .

+4
source share

All Articles