Category Archives: Debugging

Things I Always Do to web.config When Developing and Debugging in SharePoint

First off, if you are debugging a feature receiver or any other type of assembly installed in the GAC, read this post.

Beyond that, I always make the following changes to web.config:

Whenever you see "An unexpected error has occurred," you are looking at a custom error screen. If you want to see the real error, find <customErrors
mode="On" />
and change it to <customErrors
mode="Off" />
to see the standard ASP.Net error page.

I also like to see the call stack and trace information. Find <SafeMode
and change it to <SafeMode

Finally, I like to enable generation of debug symbols for just in time compilation in the rare case I need it. Find <compilation
and change it to <compilation

None of these configuration choices are appropriate for a production environment, but they all make development much easier. Seeing the actual error and call stack has saved many of the few hairs I have left on my head. "An unexpected error has occurred" is no help to a developer!

Author: Doug Ware

Getting the w3wp.exe Process ID for Attach to Process

This is pretty well known and lots of others have posted about it over the years, but for the sake of completeness for those who read the last post and don’t know this already…

Often when you try to attach to the w3wp.exe process and debug an assembly there are multiple instances from which to choose. How do you know which one to pick?

Open a command prompt and run the iisapp.vbs script with no parameters as follows:

It will output a list of the currently running application pools and the associated PIDs.

Author: Doug Ware

You Don’t Need to Copy PDB Files to Debug in the GAC!

Following up on my last post, many developers choose to put assemblies into bin because they find them easier to debug. Usually, they do not create detailed CAS policies. Instead they simply set the trust level to full so they can ‘just make it work’. While this is a sentiment I can fully understand having wrestled with it myself, it’s not the best idea. Generally, I think most will agree that the closer the development environment’s configuration matches the production environment the better. So developing with assemblies in BIN with the web config set to full trust and then deploying them at the last minute to the GAC just makes me feel unclean.

Fortunately, it’s just as easy to debug in the GAC as it is in BIN if you configure the development environment correctly. Unfortunately, few know how to do this because the internet is polluted with pages full of bad information that is a held over from previous versions of .Net. You can spot these easily because they will say you need to copy the debug symbols (.pdb file) to the GAC. In and of itself, that will not work. These days it is also completely unnecessary.

To configure VS 2005 to debug the assemblies properly, do the following:

Open Tools | Options.

Check Show all settings if needed and locate Enable Just My Code (Managed only)

Uncheck it and click OK

Attach to the w3wp.exe process for the instance you want to debug.

There may be more than one. You can attach to all of them, but only the first one will be debugged. To verify that you are attached to the correct instance of w3wp.exe, open the Modules window by pressing CTRL-ALT-U.

If your assembly is listed, you picked the right one. If not, choose stop and attach to the next one until you find it.

In this example, the assembly is loaded. Note that the symbol file is loaded and that it was not copied to the GAC.

My breakpoints are hit! Yay!


P.S. Don’t forget the set debug="true" in the web.config or it won’t matter where you put the assembly! This can really trip you up if you forget to do it because the breakpoints will turn all nice and red, but it won’t stop.

Note: I renamed this post because I want people to read it and I decided that some might miss the message based on the earlier title.

Author: Doug Ware