Have you ever designed an application that works on your development machine but suddenly seems to stop working (or crashes) on another system? Memory corruptions and invalid handles are sometimes hard to detect, especially if you are just looking at the source code. The Microsoft Application Verifier is a dynamic runtime testing tool specifically designed to tackle such issues. It provides a variety of run-time tests for detecting heap, handle, and lock problems.
Application Verifier works by enabling a verification layer between your target application and the Windows operating system, hooking into the instrumentation, and creating a debug environment. Once your application executable runs, key factors, such as memory allocations, are validated. If the process generates any exceptions, they are intercepted and logged in the Team System IDE. Application Verifier also verifies low-level calls to the kernel, API calls, and any DLLs loaded into your project.
Application Verifier comes in two versions: a standalone version and the version that's part of Visual Studio Team Edition for Developers (and the Visual Studio Team Suite). Application Verifier is compatible with Windows XP, Windows 2003, and later Operating Systems. It is not supported on Windows 2000.
Visual Studio's Application Verifier is an important feature of Visual Studio Team Edition for Developers. This new version of Application Verifier requires Windows XP or later (see the system requirements for Visual Studio 2005 in the ReadMe notes). You may need an operating system update to use AppVerifier. If it is not installed on you machine, you will receive a dialog box with download instructions. It is only enabled in the Debug menu when you load in a C or C++ solution (in fact, Application Verifier is not compatible with .NET applications — you'll learn why in a moment). Microsoft has narrowed down the number of tests (in handles, heaps, and locks) in this version to target the issues that affect developers the most, such as buffer overruns.
Fundamentally, Application Verifier is designed to test unmanaged Win32 applications. The Start With Application Verifier menu option will appear for all C/C++ projects, but clicking on this will show a message box if the underlying debug engine is anything but the native debug engine. Clicking OK on the message box will show the same behavior as Debug Start and the application will not be verified. The debug engine can be changed using the project properties. A pure unmanaged project uses native debug engine by default. Managed and mixed-mode C/C++ projects use "Managed Only" and "Mixed" debug engines respectively by default. You can change the debug engine to "Native Only" for managed and mixed-mode projects. By doing so, you can use Start With Application Verifier to verify the application. In this case, it will only verify the native code in your application. If you were able to try it on a managed .NET application by changing the debug engine to "Native Only," you would notice that the tool reports a long list of problems! This is perfectly normal; the Common Language Runtime (CLR) will inevitably generate a lot of noncritical and critical errors. This is because the CLR accesses "protected" portions of the operating system. It also manages memory (via the automatic Garbage Collection routines) and handles process initialization and de-initialization. Because the run-time environment is deeply entrenched in the Windows operating system, the CLR will perform actions that are construed as application errors by Application Verifier.
Also note that you need administrative privileges to run Application Verifier; otherwise, you will receive an error message.
If you are having difficulties running Application Verifier because that option has been grayed out, be sure your C++ project is properly loaded into Visual Studio and you are not currently performing a build or debug operation on your application.
FxCop is an excellent static analysis tool specifically designed to test your .NET applications. You can find out more about FxCop in Chapter 8, "Managed Code Analysis."