Scott Hanselman

Being a good .NET citizen means certain things...start with your debugging skills

December 03, 2004 Comment on this post [5] Posted in ASP.NET | Web Services | Bugs
Sponsored By

I've not been one to work the newsgroups, answering questions. I probably should. I'm more of a one on one person, and I tend to go the extra mile when folks (largely strangers) ask me technical questions. I've had email threads 10-deep with total strangers on technical questions, and only at the end do I say, "Um, do I know you?"

I haven't done what Scott Mitchell wisely did and setup a "Getting Help" policy, but I'm quickly getting there. I'll happily answer your question for $75 too, satisfaction guaranteed, and I'll blog the answer. I've done this hundreds of times for free. :)

Anyway, the point of this post was this: People, for crying out loud, debug a few things before you ask for help. If you don't know how to debug, learn or ask someone to teach you.

So, I present:

The Hanselman List of .NET Debugging Dos and Don'ts

Don't - Say "Hey, I got a NullReferenceException," what's the problem?
Do - Provide a Stack Trace/Dump with the line number it likely happened on.

Don't - Get deep into your complicated program, find a bug and insist it's BillGs fault.
Do - Reproduce the bug in some simple test program and tell the world. Remember, 9/10 times it's you.

Don't - Decide there's a problem if you don't know the preferred behavior.
Do - Always Assert your assumptions. If null can happen, check for it. BUT, if null must never happen it's time for a Debug.Assert

Don't - Move code around blindly, somehow fix your bug, ignore it and keep coding. Programming by Coincidence!
Do - Understand your program fully. Remember what Andy and Dave say about lucky folks who step into minefields and don't die. Just because you didn't die, doesn't mean there aren't mines!

Don't - Reformat or "pave" something because you don't know what's wrong. If you get a spot on your carpet, fix the spot. Don't lay new carpet.
Do - Know enough about your environment to know what your program's dependencies are. If your registry settings can get boogered, Debug.Assert that you are getting good values from the registry.

Don't - Get overly frustrated with Assembly loading/versioning/policy. At least the Assembly Loader follows clear, set, rules.
Do - Make a folder called C:\FusionLogs, then go to the registry in HKLM:\Software\Microsoft\Fusion and make a DWORD value LogFailures=1 and string value LogPath=C:\FusionLogs. Every AppDomain that has a binding failure or weird redirect will get logged. Know: What assembly you want, what they looked for, what you got. Know where Assemblies are searched for.

Don't - Avoid debugging. Debugging in .NET is easier than ever before. Remote debugging and AttachToProcess are gifts. Don't stop at a point in the call stack if you can keep going by finding PDBs.
Do - Keep your Source and PDBs in the same location. We keep ZIPs of every build's PDBs. Just today we dug up 9-month old PDBs and source (from CVS) to debug into some confusion. Not saving those PDBs would have screwed us. Create a Symbol Server.

Don't - Limit yourself to the QuickWatch. Learn what VS.NET has to offer.
Do - Use the Immediate Window to test theories. Remember that you can perform Casts in the Watch Window. Remember that you can drag and drop variables into the Watch Window. Remember you have 4 Watch Windows, Autos, Locals, not to mention. Learn how to use Conditional Breakpoints!

Don't - not debug something just because you can't figure out how to launch the process from the VS.NET Project Properties.
Do - Debug|Processes|Attach to attach to processes that have your DLL loaded. Use ProcExp from SysInternals as a better Task Manager to see .NET processes, as well as a system-wide DLL search. Who's got you loaded?

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
December 03, 2004 22:32
Hmm... I thought it was interesting you saying that we should keep .pdb files. Can you go into debug mode if you have only .pdb file? Wouldn't you be able to re-create .pdb file from source code? If so, what's the point of saving .pdb file?
December 03, 2004 22:42
Your fifth one; "Don't - Reformat or 'pave' something", is a popular one around here. I have to send this one around the office. Thanks for stating out loud what should have been common sense to most by now, but for some reason isn't.

December 05, 2004 0:00
As you first commenter mentioned could expand on saving old PDB's? Symbol Server? Is there somewhere that talk about these techniqes?
December 06, 2004 8:48
It's WAY easier to just keep the PDBs around, and you'd hate to have to reproduce an entire source/build system to "Rebuild" the PBFs as vbNullString says. You run the risk of your new PDB not matching up with the source.

The PDBs let you match up lines of source and methods with compiled code. If you have the source, that's not enough to debug an application. You'll also need the PDBs.

You can create a "symbol server" that holds all your PDBs and lets developers in your company download them as they need them. Microsoft also has a public symbol server with PDBs for much of the OS.

December 07, 2004 8:24
excellent advice. good work.

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.