The following two procedures guide on how to properly collect a memory dump to study a process crash. This post complements my article about how exceptions are handled and how to collect memory dumps to study them.
Both tools below - ProcDump and DebugDiag - work similarly: they can attach themselves as debuggers to a process, then monitor and log exceptions for that process. Optionally, these tools can collect a memory dump for the monitored process under certain conditions - such as when specific exceptions occur.
Both tools need administrative rights to be run.
DebugDiag is the preferred tool, since it automates some steps, adds more explicit context, and includes automated memory dump analysis capabilities too.
ProcDump does not require installation. But one needs to be specific about the PID to which it is attaching. That PID needs to be determined prior to starting ProcDump. This may be tricky when the respective process is crashing and restarting frequently, with a different PID; such as when Asp.Net apps are causing their w3wp.exe to crash and restart. If the w3wp.exe is crashing very fast, then it is advisable to use the DebugDiag method.
D:\Temp-Dumps> C:\Windows\System32\InetSrv\appcmd.exe list wp
D:\Temp-Dumps> procdump.exe -accepteula -ma -e 1 -f "ExceptionNameOrCodeOrMessageExcerpt" [PID]You may want to redirect the console output of ProcDump to a file, to persist the recording of the encountered exceptions:
D:\Temp-Dumps> procdump.exe -accepteula -ma -e 1 -f "ExceptionNameOrCodeOrMessageExcerpt" [PID] > Monitoring-log.txtReplace [PID] with the actual Process ID integer number identified at the step 2.
DebugDiag requires installation, but it is able to determine itself the whatever process instance - PID - happens to execute for an application pool at some point in time; even when that process may occasionally crash, hence restart with different PID.
Download Debug Diagnostic and install it on IIS machine:
https://www.microsoft.com/en-us/download/details.aspx?id=49924 v2.2 (if 32-bit system)
https://www.microsoft.com/en-us/download/details.aspx?id=103453 v2.3.2 (only supports 64-bit OS)
Open Debug Diagnostic Collection.
If a wizard does not show up, click Add Rule.
Choose Crash and click Next.
Choose “A specific IIS web application pool” and Next.
Select the application pool which runs the problematic application and then click Next.
Lower the Maximum number of userdumps created by the rule to 3 (up to 5; there is no need to collect more).
Then click on Exceptions under Advanced Settings, to add the one(s) we are interested in for analyzing.
A list of common native exceptions is presented; all managed (C#/.NET exceptions) would be under the CLR Exception umbrella.
Select the native exception that affects our app/process or simply type its hex code: C0000005 Access Violation.
Notice that the exception code does not include the hexadecimal prefix "0x".
Select CLR (.NET) Exception and type its fully qualified name (Exception Type Equals…).
Make sure you're not including any prepended or trailing space characters. Case is sensitive!
We need full memory dumps, so select the according value in Action Type.
It is always better if we get more than one memory dump, so you may increase the Action Limit field value.
Confirm that our exception of interest is added, then click Save & Close:
Configure the file location where the dump file(s) will be generated/written.
Please make sure that there is enough disk space on the drive where dumps are collected. Each process dump will take space in the disk approximately the same size the process uses in memory (column Commit Size in Task Manager). For example, if the w3wp.exe process memory usage is ~2 GB, then the size of each dump file will be around 2 GB.
Please do not choose a disk in network/UNC; choose a local disk.
Click Next and Finish by selecting to Activate the rule now.
When the configured exception occurs, a dump file (or files) should be created in the user-dump location selected above.
Archive each dump file in its own ZIP and prepare to hand over to the support engineer; upload in a secure file transfer space.
If we don't get dumps, then we probably don't have the configured first-chance memory occurring. Remember my article about how exceptions are handled and how to collect memory dumps to study them.
Aside: Just in case you are wondering what I use to capture screenshots for illustrating my articles, check out this little ShareX application in Windows Store.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.