You should be using this method when the slow HTTP processing can be easily reproducible, when you can easily predict that a request processing would be slow.
An alternative to the approach below is to trigger a memory dump collection with a FREB rule, according to instructions in this article: http://linqto.me/freb-dump.
The only amendment to that article: I would take 2 or 3 dumps one after another, some 10 seconds apart; so, I would use customActionParams="-accepteula -ma -n 3 -s 10 %1% C:\MyDumps".
Both ProcDump and DebugDiag can attach to a process and collect memory dumps from it. DebugDiag is more flexible, ProcDump has almost no footprint.
ProcDump does not require installation. Needs to be run from an administrative console. But ProcDump is not as easily configurable as DebugDiag…
D:\Temp-Dumps> C:\Windows\System32\InetSrv\appcmd.exe list wp
D:\Temp-Dumps> procdump.exe -accepteula -ma -n 5 -s 10 [PID]Replace [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 and install the Debug Diagnostic tool 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 “rule wizard” appears, please click Cancel.
You may want to change the default location where the memory dumps are written.
By default, these are placed under C:\Program Files\DebugDiag\Logs\Misc
Change from Menu > Tools > Options And Settings, then modify Manual Userdump Save Folder:
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.
Go to Processes tab. Sort the processes by Process Name and find the w3wp.exe process.
If there are more than one application pool running at the same time you may see more than one w3wp.exe.
In that case, you may differentiate by Process Identity or by checking the Web Application Pool Name column.
Right click on the process and choose “Create Userdump Series…” and then…
Collect the dump series with the following settings:
Please wait until all the dumps are written on disk at the configured location.
Archive each dump file in its own ZIP and prepare to hand over to the support engineer; upload in a secure file transfer space.
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.
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.