Last week, we posted an article on techniques around debugging browser forms. We received a few questions around the recommended way to find the right w3wp.exe process to attach to - this article aims to help. Non-production Server (where you can do anything without users complaining about service availability)
It is good idea to use Visual Studio to debug W3WP.exe. It is easier than using WinDbg but way more heavy weight to install. In any case make sure you have proper symbols servers configured properly or have PDB files for your code handy.
Options for production servers apply to non-production servers, too, but not vice versa :-).Production Server
You are likely will be limited to grabbing stack trace/full memory dump at the moment of exception using WinDbg. You still need process ID; here are 2 way to get it without hurting the server.
1) Use %windir%\system32\iisapp.vbs to get process IDs of W3WP processes. Note that it might be not trivial to figure out what W3WP to attach to if AppPool is configured as Web Garden or non-default option (new App Pool with port as part of app pool name) was chosen when Web Application was created.
2) Look into WSS logs (...\web server extensions\12\logs\) for recent entry related to W3WP. Even better, just look for failure trace in the log file and second column is process ID to debug. Note that it could be good idea to bump logging level to Verbose to some or all categories related for Forms Server on "Central Administration" -> "Operations" -> "Diagnostic Logging" page.
Alexei LevenkovSoftware Design Engineer
Note for all those who _really_ don't want to use VS and are not too keen on WinDbg:
Sometimes it might be acceptable to install the Remote Debugging components where a full Visual Studio deployment might not be allowed. Simply copy the contents of "%VS80COMNTOOLS%\..\IDE\Remote Debugger" (x86 or x64 depending on what you need) to the machine you want to debug and start msvsmon.exe.
The remote debugger does not require installation and will allow Visual Studio to connect to it using NTLM authentication. Once connected (via Tools | Attach To Process and then putting the remote machine name in the Qualifier field) it's business as usual.