The following two procedures guide on how to collect traces of exceptions when the application is not using a logging or telemetry solution - such as Application Insights - to record those exceptions. 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. While ProcDump will report exceptions occurring, DebugDiag will also collect thread call stack information.
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.
C:\Windows\System32\InetSrv\appcmd.exe list wp
D:\Temp-Dumps> procdump.exe -accepteula -e 1 -f "" [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 -e 1 -f "" [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=102635 v2.3.1 (only supports 64-bit)
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.
The Unconfigured First-Chance Exceptions are the unknown ones that we want to determine…
Let's Log Stack Trace for these; say the first 100 occurrences.
Lower the Maximum number of userdumps created by the rule to 1 (would only get a dump if we have a crash; but at this stage we're not after dumps).
Then click Next…
Configure the file location where the (potential) dump file(s) will be generated/written.
A dump would only be collected on crash, if it happens; otherwise, we should only have a text file as output: a monitoring log, where occurred first-chance exceptions are recorded.
Please note that a dump file is a snapshot of the process memory, written in disk; size will be similar to process memory as seen in the Task Manager.
For example, if you see that w3wp.exe uses around 5 GB of memory in Task Manager, then the dump of that process will be around 5 GB on the disk.
Please do not choose a disk in network/UNC; choose a local disk.
Click Next and Finish by selecting to Activate the rule now.
Unknown/Unconfigured first-chance exceptions will be recorded; therefore, revealed.
If the application pool's w3wp.exe process would crash with an unhandled exception, we would also get a memory dump.
If dump is generated, archive in a ZIP and hand over to the support engineer or to the development team that should be aware of these exceptions.
Remember my article about how exceptions are handled and how to collect memory dumps to study them. We can double check if a crash occurred or not: read about w3wp.exe crashes.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.