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.
Using the command-line ProcDump
ProcDump does not require installation. Needs to be run from an administrative console. But ProcDump is not as easily configurable as DebugDiag…
Replace [PID] with the actual Process ID integer number identified at the step 2. 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 process’ memory usage is ~1 GB, then the size of a dump file will be around 1 GB.
Start reproducing the problem: issue a slow-running request from the client (browser) to the investigated IIS application. Or simply wait or make requests to the IIS/Asp.Net app until the slowness manifests. Then, as fast as possible…
Hit enter on the above ProcDump.exe command (procdump.exe -accepteula -ma -n 5 -s 10 [PID])
Please wait until all the dumps are written and then compress the files before uploading the dumps to the workspace.
Using the UI tool DebugDiag, Debug Diagnostics Collection
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:
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:
Generate a Userdump every 10 seconds.
Start the timer when writing the dump file completes.
Stop after generating 5 userdumps.
Collect Full Userdumps.
As soon as you click Save & Close, you will see the following pop-up box and the dump collection will be started immediately:
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.