How to capture Debug Info

Standard

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.

Using -hang

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

Using -crash

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 using

 cscript 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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s