Will creating a memory snapshot with dotMemory pause the app?

Question

I have a memory leak, that only occours in production (a webapp (Asp.Net MVC)).

I would like to take a memory snapshot with dotMemory (or a tool like it) to see what is going on.

However I am not sure if that will cause the production to pause and mess up any current requests.

Fwiw I have 32 gb of RAM on the machine

So my question is:

Can I get a memory snapshot without adversly blocking / affecting requests?

Answer 1

Yes, dotMemory and any other memory profiler working via Microsoft Profiling API will pause an app for some time, from milliseconds to minutes depending on how much data is in the memory.

I would recommend to take a standard Windows memory dump, in normal situation it also takes some time, but there is a technique which could help to avoid it. Then you can analyze it in dotMemory or any other tool supporting Windows memory dumps.

https://blogs.msdn.microsoft.com/granth/2012/07/02/how-to-take-a-memory-dump-of-an-asp-net-application-pool-quickly/

When I was running the internal Team Foundation Servers (TFS) at Microsoft, we sometimes encountered issues that could only be understood by analysing a memory dump. This was especially true on the Pioneer and Dogfood servers that were running pre-Beta builds. If the problem was serious enough (crashing, memory leaks, etc) that it needed a memory dump, it probably meant that it needed it quickly so that we could recycle the application pool and get the server healthy again.

The problem with dumping an ASP.NET Application Pool, is that all the application pools use the w3wp.exe process name. So, before you can take the dump, you need to work out which process corresponds to the application pool that you are targeting. If you can’t tell by looking at the process owner (e.g. service account/app pool identity). The easy (but slow) way of doing that is to open Task Manager and add the ‘Command Line’ column to the display. You will then see each of the application pool names in the command line of the w3wp.exe processes.

The other problem with app pools that are consuming a large amount of memory, is that the process will be suspended for a long time while the memory is dumped to disk. If this takes longer than the configured ASP.NET process ‘ping time’, then IIS will terminate your process (and start a new one) halfway through the dump and you’ll lose your repro.

To solve that problem, there is the ‘-r’ flag available in the Sysinternals Procdump.exe. It leverages a feature of Windows 7/Windows 2008 R2 that “clones” a process to take the dump and unsuspends the original process faster than normal.

-r      Reflect (clone) the process for the dump to minimize the time 
        the process is suspended (Windows 7 and higher only).

We can then use the IIS management tools to look up the process ID for a particular app pool and now we have a simple batch file that we can put on the desktop of our TFS server for quick access.

DumpTfsAppPool.cmd Create the following batch file and put it in the same directory as Procdump.exe. Don’t forget to create/update the path to the dump location.

%windir%\system32\inetsrv\appcmd list wps /apppool.name:"Microsoft
Team Foundation Server Application Pool" /text:WP.NAME >
"%temp%\tfspid.txt"


:: ProcDump.exe (faster, reflects/clones the process for the dump to
minimize the time the process is suspended (Windows 7 and higher
only))

for /F %%a in (%temp%\tfspid.txt) do "%~dp0\procdump.exe" -accepteula
-64 -ma -r %%a f:\dumps pause