To aid Developers in troubleshooting particularly difficult bugs it may be necessary to run debugging tools on the server environment.
For the purpose of this article, it is assumed you ADplus installed, so please refer to the Microsoft article linked at the bottom of the page.
To take a dump of an process at anytime that is in memory you can use –hang mode.
To dump a specific process use the -pn switch with the process name.
c:\Program Files\Windows Kits\8.0\Debuggers\x64\Adplus -hang -pn w3wp.exe -o c:\temp\DebugDump
(change path from x64 to x86 depending on OS version)
May not work on 2008 R2
To dump all IIS related processes including inetinfo.exe, all w3wp.exe processes, etc. use the -iis switch
c:\Program Files\Windows Kits\8.0\Debuggers\x86\Adplus -hang -iis -o c:\temp\DebugDump
You can also set ADplus to take a dump when a process crashes. This process attaches the debugger at anytime and it waits until a crash occurs.
adplus.vbs -crash -pn RepositoryService.exe -o c:\temp\DebugDump
Additional steps to capture IIS worker processes for debug:
It may be necessary tochange the settings on the customers AppPool to orphan the worker process instead of killing it. This allows you to attach the debugger after the fact. The command is as follows:cscript adsutil.vbs set w3svc/apppools/<nameofapppool>/orphanworkerprocess 1
This should only be done when actively troubleshooting an issue as it will unnecessarily use resources on the server, possibly leading to even more problems or performance issues. So be sure to disable the setting after taking the debug dumps usingcscript adsutil.vbs set w3svc/apppools/<nameofapppool>/orphanworkerprocess 0
Addition information regarding orphaning from the MS article linked at the bottom of this page.
Note: Replace <nameofapppool> in the preceding command with the name of the application pool to which this setting should be applied.
After WAS is configured in this way, the failing instance of W3wp.exe will not be terminated by WAS, and you will be able to hook up a debugger and investigate the cause of the problem.
More information on debugging production environments can be found in Microsoft’s article: Production Debugging for .NET Framework Applications.