Despite all the planning, code review, and testing, problems will arise once an application is in production. Some of these bugs are easy to track down, but others can be painful to properly diagnose and remedy; this is especially true of performance issues for Web applications. You can use Microsoft’s free Debug Diagnostic Tool (DebugDiag) when there are issues with applications that use Microsoft technologies.

How to install and use DebugDiag

DebugDiag has an easy to use interface that facilitates troubleshooting issues such as memory leaks, application hangs, performance issues, memory fragmentation, and crashes in any Windows application (Win32 user-mode process) running Windows XP/2003/2008/7.

Download of the current version of DebugDiag (1.2) and run the install, which includes the program’s executable, help files, configuration files, a Windows Service (it provides the monitoring function), and more. The DebugDiag tool is available via DebugDiag.exe in the application install directory. Figure A shows the screen presented when the application runs.
Figure A

DebugDiag’s main screen (Click the image to enlarge.)

The DebugDiag tool has three tabs: Rules, Advanced Analysis, and Processes. The Rules tab is where you define and set up the issue to track and record in a dump file. The Advanced Analysis tab has options for analyzing the results (dump file) from your rules. The Processes tab offers a peek at what services are currently running on the system (Figure B). You will notice the DebugDiag.exe and DbgSvc.exe processes in the list. DbgSvc.exe is a Windows Service installed with the tool, while DebugDiag.exe is the actual tool running. You can troubleshoot any service in the list by right-clicking on the process.
Figure B

See running processes in DebugDiag (Click the image to enlarge.)

How to set up what you want to troubleshoot

The Rules tab allows you to set up what you want to troubleshoot and monitor. You can attempt to track down three types of issues:

  • Memory/Handles: You can track memory leaks via the Leak Monitoring Option, which tracks memory allocation within a process. It can be set up to generate a dump file via a time interval or memory usage, which is specified in the rule.
  • Performance: A hanging process or slow performance uses performance counters or HTTP response times to troubleshoot an application. A dump is generated when a performance counter is exceeded or when a Web application doesn’t respond to a ping within the definition.
  • Crash: DebugDiag can attach to a process and generate a dump when it terminates unexpectedly. It can be generic to monitor for any crash or monitor certain exception types or breakpoints.

Figure C

Select the rule type to set up the DebugDiag tool (Click the image to enlarge.)

The Add Rule button (see Figure A) presents the window shown in Figure C to choose the type of debugging. Figure C is a wizard (which can be disabled) that allows you to quickly choose what you need to monitor: crashes, performance issues, or memory/handle leaks. You select what you want to monitor, and then whether you want to generate a full or mini dump file. Once the rule is created, it appears in the list in the Rules tab shown in Figure A.
As an example, I will set up a ping test for a Web application. I choose Add Rule and select Performance from the window shown in Figure C. Figure D is displayed with HTTP Response Times selected since we want to set up a ping test for a Web application. Next, I choose Add URL and enter the details in Figure E, where we are pinging a URL every minute and generating a timeout event if there is no response within one minute.
Figure D

Selecting the Performance Rule Type during rule setup (Click the image to enlarge.)

Figure E

Configuring a ping URL monitor test (Click the image to enlarge.)

The final part of rule setup is deciding how often to generate a dump and specifying where to store the dump file. The ping test is a simple example, but it is a popular method for measuring site availability.

Crash and burn

I often use DebugDiag to generate a dump file when an application crashes and then use the dump file to locate the reason for the dump, or at least what code or Web page was being used when the dump generates. It begins by choosing Crash from the window presented in Figure C, which results in the Target Type window shown in Figure F. This allows you to monitor a specific process, application, service, IIS application pool, or IIS in general if an application pool is not used. Monitoring an application pool means it will monitor the W3wp.exe process serving the specific application pool.
Figure F

Setting up crash dump analysis by choosing what to monitor (Click the image to enlarge.)

Once you encounter a problem (i.e., a dump is generated), you can use the Advanced Analysis tab of the tool to process the dump file. The tool uses scripts to process dump files – a VBScript type of syntax – with a few scripts included with the tool for working with crashes and hangs, memory problems, performance monitors, and SharePoint. The analysis of the dump will include a summary at the beginning (recommendations are often included as well), followed by details and a summary of the script used to perform the analysis.

Summary

The DebugDiag tool is a good vehicle for working with Microsoft applications, and I especially like the ability to take a closer look at IIS-based Web applications. DebugDiag tool may not solve all your problems, but it will often provide details that move you in the right direction.

What tools do you use?

I am always on the lookout for tools that can assist with everyday work, especially tools that help with tracking down application issues. What tools do you prefer to use when working with code issues? What are your favorite tools for developing code? Share your recommendations with the development community.