Several best practices have already been provided that help prevent problems or at least eliminate bugs early in product development. Regardless, you will still deploy applications with bugs! Welcome to the real world. What is the next step? In Debugging Microsoft .NET 2.0 Applications, John Robbins suggests a nine-step process to follow, called the Debugging Process. The nine steps include tasks such as duplicate the bug, divide and conquer, and verify that the bug is fixed. Each of the nine steps is important and should be considered. The most important step is to consistently replicate the problem.
If the bug cannot be reproduced, you are unlikely to quickly or efficiently resolve the problem. Consider the difficulty of isolating a bug that occurs once a day, a week, or even a month. The longer the gap between occurrences, the more difficult it is to observe patterns and to create a hypothesis of the problem. Re-creating the problem consistently implies a degree of knowledge about the problem. In addition, it is much easier to discern patterns that create the problem. Actually, you may have already uncovered the problem but don’t realize it yet.
Several common factors can make reproducing a bug more challenging:
Simulating real-world stress on the application can be difficult. This is where a professional test apparatus is essential. There are a variety of products available on the market that can apply various stresses to a Web application.
Re-creating user input in a consistent manner is always a challenge. For Web applications, WatiN is an open-source testing tool that provides some ability to re-create user input in a testing environment. For more information, visit the following Web site: http://watin.sourceforge.net.
Problems from deadlocks can sometimes be a challenge to re-create. This is particularly true since deadlocks most often occur in multi-threaded applications. For example, race conditions may disappear with the slightest change of environment. Deadlocks sometimes disappear when switching between production and debug versions of the product. The production application is a release version of the product, and it is optimized. Subtle changes in code from optimization may cause otherwise hidden bugs to appear.
The application with the problem is deployed to a production machine, where debugging on the production machine may not be an option. This is often the case with Web servers. For practical reasons, you may not want to potentially interfere with the execution of a production application. In addition, you may not have physical access to the production machine and remote debugging is required. All of this makes reproducing the problem much more of a challenge.
Many of these problems are more easily resolved with a dedicated test lab. In a dedicated test lab, you can run an application using different configurations and under various pressures. You could have a test machine for every deployment scenario. However, this is not always possible because of the sheer number of machines that might be required and the related costs. Not everyone can afford a dedicated test lab. One way to mitigate the hardware requirements and cost of a test lab is to use Microsoft Virtual Server, Microsoft Virtual PC, or Hyper-V. With these programs, you can install multiple platforms, including different service packs, on a single machine or a handful of machines. Most importantly, you can save an environment as an image, which can be retrieved at any time. This is ideal for resetting the test environment for repetitive tests.
Multi-threaded applications pose a special problem. This type of application can behave differently based on the type of system. For example, a multi-thread application may perform differently on a single- versus dual-core machine. In addition, differences in CPU speed can affect the operation of multi-threaded applications. It is important to test multi-threaded applications (both release and debug versions) on machines with single or multi-core machines. This can preempt future problems and debugging.
ADPlus is an essential tool for debugging random problems that cannot be consistently reproduced. You can download ADPlus with the Debugging Tools for Windows. ADPlus is configurable to capture a dump whenever a crash occurs, an exceptional event occurs, or the application hangs. The dump, which is a snapshot of an application at that moment, is typically made unattended. This will allow you to spend the day sailing. Later, perform post-mortem debugging analysis of the dump or dumps to determine a pattern of problems that can help re-create the problem consistently or resolve the problem immediately.
Several tools, such as ADPlus, have been mentioned. Some of the tools are specialized debugging tools, while others are general purpose. Having the correct tools in your toolbox and knowing how to use them is important. Many of these tools are more complex and less documented than Visual Studio. These tools should be used for more complicated debugging scenarios. However, before reaching for the heavy arsenal, conduct lightweight debugging first in Visual Studio. Check that variables are initialized and within an expected range, confirm that acquired resources are being released, validate the return values of functions and APIs, review the call stack, and more.