Must-know Visual Studio debugging tricks

I’ve been debugging ASP.NET and SharePoint code in Visual Studio for a good many years now and still periodically get stumped when a breakpoint won’t turn red or the breakpoint is correctly set but the debugger still won’t break.

My simple, random checklist for successful debugging includes the following:

• web.config debug=”true”
• Application compiled in debug mode
• .pdb files deployed to the bin directory or the GAC (map a drive to \\{machine_name}\c$\windows\assembly\gac_msil\{version_publickey} in the latter case and drop .pdb files into folder or go command line)
• Check the event log (do this first for most things SharePoint)
• Reset IIS
• Ensure output caching is not enabled in the SharePoint site collection (if you’re restoring a site collection from a production environment where output caching is configured, note those settings will come down to dev every time you restore your content database)
• When in doubt Debug –> Windows –> Modules will tell you all about which assemblies have been loaded and where they’re sourcing debug symbols, if at all. If necessary, right-click on the Modules window and select the Show Modules for all Processes option.
• If you've deployed a change to the local bin directory and it just doesn't seem to have any effect, make sure a previous version of the assembly isn't in the GAC
• VS can be told to use code that differs from the code in the running assembly: right-click break point –> Location… and check Allow the source code to be different from the original version
• System.Diagnostics.Debugger.Launch(); in code will prompt you to attach a debugger and manually point it to a source file
• Remote debugging generally requires the user running VS to be the same user running the remote debugger. If that’s not the case, domain\username@remotemachine may help. If you're running it on a real server, it may help to login as the debug user or least as a user on the same domain before starting the remote debug monitor (altering the account within the debug monitor may not always work and don't forget the conversation is two-way between your workstation and the server). Also ensure firewalls aren't in the way.
• Is the remote debugger actually running?
• Are you running the right version of the remote debugger for VS2005/2008?
• Are you sure you want to be attaching to w3wp.exe and not aspnet, IE, a Windows application or service (ie. stsadm doesn’t run under w3wp.exe).
• Got more than one w3wp.exe process running? You can attach to all the processes if you want to. Alternatively, type resetiis into a command window, browse a page on the site you want to debug (each SharePoint site will most often be running in its own application pool, which equates to a unique w3wp.exe worker process), and attach to the single process. If you don’t want to kill all the processes, determine the id of the process you’re after and attach to it.
• Can’t see any w3wp.exe processes? Ensure the Show processes from all users and Show processes in all sessions check boxes are checked
• For client-side web debugging use Fiddler, WireShark if you’re really desperate, and the YSlow plugin for Firefox. Also use Fiddler to inspect your HTTP headers and see if the page is being cached somewhere (keep an eye out for Cache-Control and/or Expires headers); if caching is an issue, append a rubbish query string (eg. ?1=1 as that may bust the cache entry for a single request)
• If you’re doing SharePoint development from a remote machine and dragging/dropping assemblies into the bin directory, do you need to update the authenticated or anonymous sites?

Dirty Words (Michael Hanes) - blog.mediawhole.com mailto:info@mediawole.com