Testing with an Application Verifier

Testing with an Application Verifier

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 Custom1 subkey may have the <{GUID}.sdb> shim data base name that is located at %SystemRoot%AppPatchCustom folder. The selected “shim” tests are represented by corresponded values.

HKLMSoftwareMicrosoftWindows NT       CurrentVersionImage File Execution Options            |-

The subkey may have the Debugger name, as above. If the full path has spaces, double quotes should be used. The subkey also has the VerifierPath name with a value of the full path to the application to be tested. The selected “base” tests are represented by the GlobalFlag and VerifierFlags names’ corresponded values.

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.

See also  5 Tips For Working With An Onsite Interpreter

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist