Procdump is a light weight Sysinternal's command-line utility whose primary purpose is monitoring an application for CPU spikes and generating crash dumps during such spikes which an administrator or developer can use to determine the cause or to share the dump with PSS for further analysis. It also can serve as a general process dump utility that you can embed in other scripts.
It completely eliminates the need to maintain different utilities like Debug Daig 1.1 for 32 bit processes and adplus for 64 bit processes on the same server.
Looking at task manager we can see w3wp.exe process is spiking CPU between 49%-60% intermittently and then immediately it goes down.
In order to troubleshoot we need to capture 2 sets of dump for w3wp.exe when process reaches 50% CPU and stays there for 3 consecutive seconds or so.This, using Debug Diag 1.1 or Adplus could be a tricky task as it would require great deal of accuracy to manually generate dumps when the actual CPU spike happens or we may end up taking dumps without capturing real activity responsible for the spike.
ProcDump.exe comes in handy in such situation to speed up the course of action and help in getting the right set of data. It would monitor the target process for CPU spike within specified time limit and take snapshot at that point.
procdump -ma -c 50 -s 3 -n 2 5844(Process Name or PID) -ma Write a dump file with all process memory. The default dump format includes thread and handle information. -c CPU threshold at which to create a dump of the process. -s Consecutive seconds CPU threshold must be hit before dump written (default is 10). -n Number of dumps to write before exiting.
The above command would monitor the w3wp.exe till CPU spikes 50% for 3 seconds and it would take full dump at least for two iterations.
C:\Users\jaskis\Downloads\procdump> procdump -ma -c 50 -s 3 -n 2 5844 ProcDump v1.1 - Writes process dump files Copyright (C) 2009 Mark Russinovich Sysinternals - www.sysinternals.com Process: w3wp.exe (5844) CPU threshold: 50% of system Duration threshold: 3s Number of dumps: 2 Hung window check: Disabled Exception monitor: Disabled Dump file: C:\Users\jaskis\Downloads\procdump\w3wp.dmp Time CPU Duration [23:48.35] 59% 1s [23:48.36] CPU usage below threshold. [23:48.37] 54% 1s [23:48.38] 55% 2s [23:48.39] 61% 3s Process has hit spike threshold. Writing dump file C:\Users\jaskis\Downloads\procdump\w3wp_080309_114839PM.dmp... Dump written. [23:48.44] 61% 1s [23:48.45] 59% 2s [23:48.46] 57% 3s Process has hit spike threshold. Writing dump file C:\Users\jaskis\Downloads\procdump\w3wp_080309_114846PM.dmp... Dump written.
Few of other interesting switches
-64 By default Procdump will capture a 32-bit dump of a 32-bit when running on 64-bit Windows. This option overrides to 64-bit dump.
-o Overwrite an existing dump file.
Another area worth investing time would be to write a batch file and run it as window service to take dump on CPU spike even when the user logoff from the server.
Stayed tuned for more on this….
I've written a dump file when my w3wp-proces had a CPU spike.
Can anyone tell me how I can Analyze this .dmp File?
You can use the following blog post by Tess to isolate it further..
Or you can open support ticket with Microsoft PSS IIS/ASP team to look further into dumps by calling
How do i open the .dmp files? The above does not clarify
All the examples are for CPU spikes. I tried the memory threshold switch with no luck.
It seems that it has a hard time when multiple instances of processes are running (like w3wp.exe).
procdump -m 3000 4128 but it never fired even thought the memory went above 3 GB.
I tried a counter in case I didn't understand which "committed memory" counter they were using.
procdump w3wp -p "\Process\Thread Count" 38 4128 -ma -o
In this case I was trying to dump the memory when the thread count went about 38 for a particular instance of w3wp. I tried using the counter string like this "\Process(w3wp#1)\Thread Count", but that gave me an error that the instance couldn't be found (even though perfmon showed the instance to be running. Pretty easy to track the Thread Count so I doubt if I got that wrong.
I also tried other counters. The thresholds never seemed to fire unless I start with a threshold that the process is ALREADY above when I start.
The only one I could get to work was: the -t switch:
procdump -t 4128 -ma -o
When I killed w3wp, it took the dump.
I put a fair amount of time into this, if you can point me to any help or documentation in case I'm doing something wrong, I'd appreciate it.
same issue as above, what do i do with the dump file once its captured an issue , open in notepad doesnt help. thank you for any advice.
Once you've .dmp(dump file) then you have to use windbg (from debugging tools for windows) to analyse it.
You can find examples for it on Tess blog
Does anyone know a way to automate the process of generating a dump file even after the PID changes?
I have multiple instances of w3wp.exe running, so cannot use the Process Name, I need to use the PID. After each App Recycle the PID changes, once the PID changes procdump can no longer generate a dump file.
Any ideas of how to automate this to handle PID changes?
I also was wondering the same thing as Phil. The problem with procdump is when the pid changes with an app pool recycle. Is there a way to monitor all worker processes?