Application Verifier is a tool for testing user-mode applications for compatibility with MS Windows XP. It comes in handy when you’re troubleshooting issues like common programming mistakes related to memory allocation, lock usage, and handle usage. The tool exposes instrumentation that already exists in the Windows OS.
The Application Verifier’s graphical front end, appverif.exe v.2.50, adds the application to be tested, selects tests, specifies a debugger, and displays the result log. Once the information is entered, it is stored in the Windows Registry at the following locations:
HKLMSoftwareMicrosoftWindows NT CurrentVersionAppCompatFlagsAppVerifier |- | |-General | |-Custom |- |-Layers |-LAYER_
The General subkey may have the Debugger name, with the full path to the associated debugger, as its value. The Custom
HKLMSoftwareMicrosoftWindows NT CurrentVersionImage File Execution Options |-
The
The stored information is applied to the running application whenever it runs. At runtime, the “base” tests are performed by built-in OS facilities in the system verifier provider, verifier.dll, that operate with the verifier engine in ntdll.dll. The “shim” tests are performed by appvcore.dll, which operates with the shim engine in shimeng.dll. Starting the application under the user mode debugger is optional, but some of the tests, like for handle errors, make sense only if application does run under debugger.
When you finish with testing and remove the application from the application list, the mentioned registry subkeys will be removed as well.
The discovered problems are saved in the%ALLUSERSPROFILE%DocumentsAppVerifierLogs folder. Access them by clicking on the tool’s “View Logs” button.
Remember: The Application Verifier versions available for download were not designed for managed code. This means that if you use them with managed applications, it makes a lot of “noise” in the log. When working with devenv.exe, select the Mixed Debugger Type option on the project property page. Otherwise, the default, Auto Type, sets the debugger type based on the contents of the flags in the IMAGE_COR20_HEADER of the .EXE file. So, if you have a managed .EXE, the automatically selected debugger will not break in the unmanaged code.
In addition, the debugger must be set to catch exceptions on the second chance in order for the Application Verifier to handle them first. You can set it by selecting the right radio buttons in the “Action” group box on the Exceptions dialog box in VS6 or the “When the exception is thrown” and “If the exception handled” group boxes in VS.NET 2003.