Understanding Visual Studio Analyzer Events

See Also   Tasks

All the tasks you can accomplish using Visual Studio Analyzer — understanding application structure, analyzing performance, and isolating faults — are based on identifying, generating, and collecting application events. In Visual Studio Analyzer, an event is an interaction between two components of an application. For example, in a Visual Basic application that invokes a remote COM object and sends SQL statements to a database server, the interactions between the application, the database server, and the remote COM object are all events.

Using System-Defined Events

Visual Studio Analyzer ships with many system-defined events. These events can provide you with information about:

The system-defined events cover a wide range of application activity. In addition to system-defined events, several Microsoft technologies, such as COM, ADO, and MTS are shipped with the ability to generate Visual Studio Analyzer events. If your application uses any of these technologies, you can run Visual Studio Analyzer against your application after you install Visual Studio. You will see events immediately; it is not necessary to add any code to your application.

If the system-defined events do not provide enough information, you can register your application with Visual Studio Analyzer and generate your own events; see Extending Visual Studio Analyzer for more information.

What Events Tell You

The basic information for an event includes timestamps, identifiers, source and target information (thread, component, and machine), global session identification, local session identification, and security identifications. Additional information includes sequence numbers for correlating related events (for example, requests with responses), descriptions, and user fields.

Visual Studio Analyzer can show you both sides of an interaction, such as the call into a function and the return from that function. The call to and return from the function, although related by the function, are separate events; together, they create a request-response pair.

For example, suppose that function A calls function B. Separate Visual Studio Analyzer events can show you:

This information makes it possible for you to measure time spent on the network, as well as time spent in actual processing.

Viewing Events in Visual Studio Analyzer

Briefly, in order to view events in Visual Studio Analyzer, you need to create three items:

See Visual Studio Analyzer Common Tasks for step-by-step procedures to create each of these items.

After creating these items, start your application. As your application runs, it generates events. The Visual Studio Analyzer event reporting mechanism collects those events into an event log. When your application finishes, you can open the event log in one of the Visual Studio Analyzer views.

Event Security

When you are collecting events, you might be gathering data from applications that process sensitive data. You can take steps to ensure that data is protected while using Visual Studio Analyzer.

Security Assumptions

First of all, you need to guard against certain events and conditions that can make any otherwise secure system insecure. These events and conditions include:

Visual Studio Analyzer's security option is valuable only in the case where none of these conditions exist.

Security on Windows NT

Microsoft recommends you install and run Visual Studio Analyzer on Windows NT if you are concerned about security or will be collecting sensitive data. Windows NT has more comprehensive security support than Windows 95 does.

Any machine where the Visual Studio Analyzer server components run (and each machine you want to monitor with Visual Studio Analyzer requires the server components) must have the following security options set under Windows NT:

Also, if you want Visual Studio Analyzer to be able to collect information from the Windows NT Performance Monitor, make sure the account under which the Visual Studio Analyzer server runs belongs to a group that has the user right to profile system performance selected. You cannot set this user right on an individual Visual Studio Analyzer client basis in this release.

See Configuring Security for Visual Studio Analyzer on Windows NT for step-by-step procedures on setting up security.

Security on Windows 95

If you need to run Visual Studio Analyzer on a Windows 95 machine, you should understand the security implications of doing so. In order to connect to a remote Windows 95 machine running Visual Studio Analyzer, you must run Dcomcnfg.exe on the remote machine to change your DCOM settings to allow remote connections. Before you can run Dcomcnfg.exe on any machine, you must set the machine's access control to user-level (Dcomcnfg.exe requires user-level access control in order to run).

Important   Changing access control to user level on a Windows 95 machine can have far-reaching consequences. For example, it will reset all of your current share permissions and you will need to restore those permissions manually. However, you cannot run Visual Studio Analyzer on a remote Windows 95 machine without changing access control to user level. Make sure you check with your system administrator before you change access control.

See Configuring Security for Visual Studio Analyzer on Windows 95 for step-by-step procedures on setting up security.