Application Verifier Tool (Windows Embedded CE 6.0)


The Application Verifier tool assesses the stability of an application and detects common programming mistakes. The tool can detect and pinpoint memory leaks, handle leaks (such as critical sections and DLLs), and leaks in graphics device interface (GDI) objects. The tool can also detect some forms of heap corruption.

Application Verifier attaches to an application or DLL and performs tests at runtime. With the tool, you may be able to diagnose subtle problems with an application that would otherwise be difficult to diagnose on Windows Embedded CE. It can check standalone applications, code that runs while the device is booting (when debugging is not possible), and on system files and drivers.

Application Verifier is also extensible. Each test that Application Verifier runs is referred to as a shim. The tool inserts the shim into the code path between the calling function and the intended target function. A shim loads into the process space, and the kernel redirects calls from other libraries to the shim. A developer with a specific problem can write a shim to focus on that problem.

You might find it helpful to run a shim with a debugger attached to the target device. If a debugger is attached to the target device, the debugger points to the location where the exception occurred, which might be close to the source of the problem identified by the shim.

As has been mentioned, Application Verifier can track either applications or DLLs. Application Verifier shims the application or DLL when it is loaded. This occurs whether you launch with the Run button on the UI or start the EXE using the device or emulator UI.

Application Verifier can log a single DLL, providing higher granularity than logging a whole application and all of its associated DLLs. In order to collect log files for that DLL, the user must launch an application that loads and runs the desired DLL. Note that the log file containing data for a single DLL is named for the application that loads the DLL, not for the DLL itself. Logging files are associated with the application, not with the DLL.

Application Verifier is most commonly run in standalone UI mode. In this mode, it has been used successfully on devices over ActiveSync and KITL and on a Platform Builder Device Emulator over KITL.

Application Verifier can also be run as an extension to Platform Builder with a CEShell command line interface. This interface allows checkpoints to be set and to collect log data with a "delta" command instead of having to wait for the application to close; this can be especially useful for checking device drivers that do not get closed, and thus do not generate log files with useful data.

Application Verifier can be added to the OS image and registry, and can start up automatically, shimming and logging device and shell processes. It can be configured in the registry to provide a range of additional capabilities for heap checking, such as breaking into the debugger on the nth allocation, allocate m bytes, or some combination thereof. It can be made to inject heap failures on some percentage of allocation. If GWES.EXE is being logged, you can log buffer overflow/underflow conditions as well.

Running the Application Verifier Tool

Tells how to run App Verifier.

Testing an Application with the Application Verifier Tool

Explains how to test an app with App Verifier.

Setting Up the Application Verifier Tool to Test a Driver

Describes how to set up App Verifier to test a driver.

Viewing Test Results from the Application Verifier Tool

Tells how to view test results from App Verifier.

Using Shims with the Application Verifier Tool

Describes the shims available for App Verifier.

Setting Up Application Verifier for Always-Running Processes

Describes how to set up App Verifier for running processes.

Community Additions