Debugging: Discover, Diagnose, and Dispatch

These are all free tools that are available for you from Microsoft, and they can solve a lot of problems.

Discover

• find the problems before your testers do. The compiler and preprocessor is your friend, so leverage your warning level (-W4) to find bits of code that are a problem. Also use -WX to halt on warnings and force yourself to remove the warnings. Also use RTC and GS.

• SAL isn't just your friend's name. It tells the preprocessor what your intentions are so it can block requests that you don't want to do, and it can often find problems before your code is even compiled. Pre-fast (a free tool available in the WDK and /Analyze in enterprise versions) leverages them by default. It's free but doesn't ship by default with the compiler (it's a legal thing), so go get it and use it.

• Use unit tests. Even the act of writing unit tests can ferret out bugs, so don't neglect them.

• Debugging tools for windows (WinDBG/NTSD/CDB/KD) are all available via MSDN. WinDBG looks pretty rudimentary like a holdover from Win 3.1, but that's intentional because it has almost no DLL dependencies and runs minimally. CDB is a console-mode debugger, and KD is the hardcore debugger for kernel and device-driver writers. Also take a look at all the related CHM files that come with the debuggers, as they have some useful tips in 'em.

• A driver verifier has shipped with the OS since Win2K, so take advantage of that.

• Application Verifier – run your app under the debugger during development and not just testing. Application verifier can show off problems that won't show up otherwise.

• Application Compatibility Toolkit – Standard user analyzer (SUA).

Diagnose

• Initiating an application debugging session - check your .srcpath .sympath, !symfix and .reload, as getting the symbols to match up so you can see where the problem actually is is always job one.

• The first steps in root-cause determination !analyze -v – identifies common crashes and can point you in the right direction as to your problem.

• Commands and tips - ? (dumps all commands) ?? (C expression reevaluator so you can predict behavior) k (family of commands to dump the command stack, has loads of options), b (family of commands to set breakpoints)

• Blue Screen of Death – caused by someone in ring zero doing something evil, which is rarely a problem for game developers as games by and large don't run in ring zero.

• Code defensively. Use things like StrSafe and IntSafe to watch for overflows and rollovers.

• Use UNICODE as appropriate.

• Use thread-safe “interlocked” API's and make sure your public API's are thread-safe as well. Make your libraries thread-safe even if you are the only user and you intend for your library to be single-threaded, as you never know how things will happen in the future.

• Trust no arguments, including your own.

Dispatch

• Code reviews aren't just for showing off. Like history, not being aware of a bug will make it your destiny that you will repeat it.

• Share your techniques and tools with your team.

• Include code coverage reports in your reviews.

• Participate in your community. There are a couple of public groups for Microsoft debugging (microsoft.public.windbg) as well Open Systems Resources forums, specifically NTDEV and WINDBG.

Call to Action

• Do not allow your team to check something in without -W4 and -WX

• Leverage contemporary API's

• Leverage verifiers in testing and development.

• Don't overlook the application compatibility toolkit

• share the experience.

Page 6