Isolating Faults

You can use Visual Studio Analyzer to isolate faults by taking advantage of the many Visual Studio Analyzer events that components can generate and that Visual Studio Analyzer can record. Visual Studio Analyzer provides many predefined events, including:

• Component start and shutdown.
  
  
• Function call and return.
  
  
• Query start and completion.

You only have to write code for your own custom events. The events you collect are stored in an event log, which you can view in many different ways and at different levels to help you understand which component is at fault.

You use the events that Visual Studio Analyzer generates as the keys to understand where the failure might be. For example, if your application sends queries to a database and receives results back, you can add code to generate Visual Studio Analyzer events when these activities occur. You can then examine the Event List view to ensure that the queries do, in fact, occur as expected.

Comparing Visual Studio Analyzer and Debugging Tools

Traditional debugging tools work at a low level to determine the exact fault in a software component. Visual Studio Analyzer is not designed as a low-level debugger. Instead, Visual Studio Analyzer is a high-level tool that helps you understand which component or set of components is failing, so that you can use your low-level debugger strategically, thus reducing the overall cost of debugging.

Locating Faults

Suppose you are trying to locate a fault in a multi-tier application. Let's suppose further that you've already run Visual Studio Analyzer against a session of your application. (It can be useful to run Visual Studio Analyzer against each application as part of your final quality assurance passes, and then save the Visual Studio Analyzer project as a baseline.) The following steps illustrate how you can use Visual Studio Analyzer to assist you.

1. Open the saved Visual Studio Analyzer project and create a new event log. Select a saved filter, set the filter as the recording filter, and start recording events into the new event log. Then open the Component Diagram view, switch to your application, set a breakpoint in your code, and begin execution.

   For more information on Visual Studio Analyzer projects, event logs, filters, and views, see Understanding Visual Studio Analyzer Projects, Understanding Visual Studio Analyzer Event Logs, Understanding Visual Studio Analyzer Filters, and Understanding Visual Studio Analyzer Views.

2. As your application executes, the Component Diagram view displays a diagram of the application as well as the various Visual Studio Analyzer events generated by the components in your application. When the breakpoint in your code is reached, your application suspends.
   
   
3. At this point you can reset the event log to the beginning and open an Event view, where you can view all the information about a single event. You can then step through the event log using the playback controls on the Analyzer toolbar, reviewing the details of each event in the Event view as you go along.
   
   
4. Suppose that on this first pass you saw no problems, but you suspect your application of being corrupted in another place. You switch to your application and set a breakpoint in that place, and then resume execution. Additional events are generated and the Component Diagram view and Event view are updated. When the second breakpoint is reached, your application suspends again.
   
   
5. You use the Event view to review the events between the two breakpoints and see an event with incorrect data, such as an incorrect call, an expected call that didn't appear, or a reported error return. This event tells you which component of your application to debug further.

Extending Visual Studio Analyzer for Custom Fault Isolation

You can use Visual Studio Analyzer to identify more complex faults, such as miscommunication between components. You accomplish this by adding Visual Studio Analyzer event generation code to your application.

For example, suppose your development team has created a large two-tier application that consists of multiple objects within a single executable. Many of these objects update a database using ODBC. A problem exists in the application that you cannot detect using normal Visual Studio Analyzer events, because it involves a bug between objects within the executable, as opposed to between separate components within the application. Your team wants to add code to your application so you can use Visual Studio Analyzer to trace the activity across the different logical components. You might use the following steps to accomplish this.

1. Begin by implementing a setup program that registers your application with Visual Studio Analyzer, and then add event generation code to your application in any location where you want to generate an event. (See Extending Visual Studio Analyzer for more information on customizing your application for Visual Studio Analyzer.)
   
   
2. After you have added Visual Studio Analyzer code to your application, create a Visual Studio Analyzer project, connect to the current machine (probably the development machine), create a filter, and create an event log. Edit the filter to select the current machine, your application and ODBC as event sources, and all events associated with both your application and ODBC. Activate the filter and begin collecting events, run your application, and then stop collecting events.
   
   
3. Open the Component Diagram view and review the application and ODBC events. Trace the flow between components and view all the data associated with each event using the Event view. With this approach, you can locate the miscommunication between components.