Debugging Browser Forms

Debugging InfoPath forms in the client environment is relatively simple: set a breakpoint, press F5 and execute the process that will cause the breakpoint to be hit. However, debugging InfoPath forms that are opened in the browser requires some additional steps:

1) Ensure the InfoPath Form Template is compiled in the Debug Configuration so the XSN includes the symbol (PDB) file
2) Open the local copy of the code file in Visual Studio and set a breakpoint
3) Attach to the appropriate w3wp process
4) Execute the process that will cause the breakpoint to be hit

So let’s take a look at each step individually.

Step 1: Ensure the InfoPath Form Template is compiled in the Debug Configuration so the XSN includes the symbol (PDB) file

1) Open the InfoPath Form Template in Design View
2) Open the Code Editor
3) From the Project menu choose "<ProjectName> Properties"
4) Insure the Configuration option is set to Active (Debug)

NOTE: If you do not see the Configuration option make sure the "Show Advanced Build Configurations" option is enabled: Tools | Options | Projects and Solutions | General

5) Build and save the project
6) Publish the Form Template to your Microsoft Office SharePoint Server

NOTE: If you want to make sure the XSN you are publishing includes the symbol (pdb) file, save the XSN as Source Files and review the resulting files to make sure there is the .pdb file.

Step 2: Open the local copy of the code file in Visual Studio

1) Launch Visual Studio 2005
2) Open the code file (i.e. FormCode.cs) from the project files folder for your Form Template
3) Set a breakpoint

Step 3: Attach to the appropriate w3wp process

1) Open Internet Explorer and navigate to your site
2) From the Debug menu in Visual Studio choose "Attach to Process…"
3) For the "Attach To" option make sure this has at least "Managed code" – if not, click the Select button to enable Managed Code
4) Select the correct w3wp process and click Attach

NOTE: Determining the correct w3wp process can be a bit tricky. To isolate the correct process:
- From the server machine, open a command prompt
- Navigate to the System32 directory and run the following script: iisapp.vbs. This script will list all the currently running w3wp.exe processes, listing their PID and associated application pool id. The application pool id is the only relation between the pid and your application.
- Use the PID to identify the correct w3wp.exe on the "Attach to Process" screen.

Step 4: Execute the process that will cause the breakpoint to be hit

1) Open your form in the browser and execute the process that will cause the code to run – execution should stop when it hits your breakpoint!

Debugging Browser Forms: Determine the right w3wp.exe

Non-production Server

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.

The easiest approach is to attach to all worker processes at the same time. Both Visual Studio and WinDbg support this.
To do so, go to "Attach to process" (available in "Tools" menu for VS, "File" menu for WinDbg) and attach to all W3WP processes. Breaking into debugger (on breakpoint or exception) will affect all sites. Users likely to get timeouts or other forms of "service unavailable" responses; make sure noone loses their data while you are debugging.

Run IISreset and then execute single request to site you want to debug. It is very likely that there will be only one W3WP started at this point.

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.

thanks Scott Heim & Alexei Levenkov