Application Verifier

Microsoft Application Verifier is a runtime verification tool for unmanaged code. It assists developers in quickly finding subtle programming errors that can be extremely difficult to identify with normal application testing. Application Verifier makes it easier to create reliable applications by monitoring an application's interaction with the Microsoft Windows operating system, profiling its use of kernel objects, the registry, the file system, and Microsoft Win32 APIs (heap, handles, locks, and more).

To find information about a specific verifier stop , use the index or search to quickly find a topic. To research what errors may be encountered, review each of the available Verifier Tests.

Where Applicable

Application Verifier can be used with any unmanaged application/program.

Runtime Requirements

In order to test with Application Verifier, you must run your project with the tool turned on and go through your testing scenarios. Refer to the Testing Applications section for more details.

User Requirements

You must be an administrator on the system that you are using in order to run Application Verifier.

System Requirements

Application Verifier runs on Windows XP, Windows Server 2003 and Windows Vista. Windows 2000 and WinPE are not supported.

If full page heap is enabled, you will need to ensure you have a large page file (e.g. 1Gb).

Uninstalling

If you wish to uninstall Application Verifier, make sure that applications that you were testing have been closed. This will ensure that the uninstall behavior acts accordingly. OR you can simply reboot your machine after the uninstall is complete. Both of these solutions will ensure that the system tests are no longer being performed.


Features

Application Verifier has the following features:

Applications

The Applications window contains applications that have been added to Application Verifier to test. Any application you add to this list will continue to be tested each time it is run until it is removed.

To add an application

  1. On the File menu, select Add Application .

  2. Browse to the application and click Open .

or

  1. Right click within the Applications pane and select Add Application .

  2. Browse to the application and click Open .

To remove an application

  1. Highlight the application to be deleted.

  2. On the File menu, select Delete Application .

or

  • Right click on the application and select Delete Application .

Tests

The information within the Tests window shows the verification layers that can be turned on or off for the selected application. By expanding the verification layer, specific tests (also known as checks) are displayed.

To turn on a test

  • Select the checkbox next to the test (check).

To turn on an entire verification layer

  • Select the checkbox at the top level.

To turn a test

Clear the box next the test.

To return to the default settings

  • On the File menu, select Restore Defaults .

See Testing Applications for more details.

Properties

The Properties window displays properties for the selected test.

To view the Properties window

  • On the View menu, click Property Window .

To display the properties for a test

  • Select the name of the test in the Tests window.

Refer to Property Window and Setting Properties for Verification Layers to learn more about this topic.

Logs

Logs are generated when an application is run and errors were encountered based on the tests selected.

To view the available logs

  • On the View menu, select Logs .

Refer to Logs to find out what other options are available for this feature.


Accessibility Features

Microsoft is committed to making its products and services easier for everyone to use. The features within Application Verifier that make it more accessible for people with disabilities are keyboard shortcuts, text reader, and ability to alter the fonts and themes.

Note: The information in this section applies only to users who license Microsoft products in the United States. If you obtained this product outside of the United States, you can use the subsidiary information card that came with your software package or visit the Microsoft Accessibility website for a list of telephone numbers and addresses for Microsoft support services. You can contact your subsidiary to find out whether the type of products and services described in this section are available in your area. Information about accessibility is available in other languages, including Japanese and French.

Using keyboard shortcuts

By using keyboard shortcuts in Application Verifier, you can quickly accomplish the following common tasks.

To do this | Use this keyboard shortcut
Add an application to test | Ctrl + A
Remove an application | Ctrl + D
Enable all tests | Ctrl + E
Disable all tests | Ctrl + I
Restore the test defaults | Ctrl + R
Save changes | Ctrl + S
Exit Application Verifier | Atl + E
Open the property window | Ctrl + P
Open the log screen | Ctrl + L

Accessibility Features of Application Verifier Help

Application Verifier Help includes features that make it accessible to a wider range of users, including those who have limited dexterity, low vision, or other disabilities.

Keyboard shortcuts for using the Help window

By using the following keyboard shortcuts in Help, you can quickly accomplish many common tasks.

To do this | Use this keyboard shortcut
Display the Help window. | F1
Select the previous hidden text or hyperlink. | SHIFT+TAB
Perform the action for the selected Show All, Hide All, hidden text, or hyperlink. | ENTER
Display the Options menu to access any Help toolbar command. | ALT+O
Hide or show the pane containing the Contents, Search, and Index tabs. | ALT+O, and then press T
Display the previously viewed topic. | ALT+O, and then press B
Display the next topic in a previously displayed sequence of topics. | ALT+O, and then press F
Return to the specified home page. | ALT+O, and then press H
Stop the Help window from opening a Help topic (useful if you want to stop a Web page from downloading). | ALT+O, and then press S
Open the Internet Options dialog box for Microsoft Internet Explorer, where you can change accessibility settings. | ALT+O, and then press I
Refresh the topic (useful if you have linked to a Web page). | ALT+O, and then press R
Print all topics in a book or a selected topic only. | ALT+O, and then press P
Close the Help window. | ALT+F4

To change the appearance of a Help topic

You can customize the colors, font styles, and font sizes used in Help.

  1. Open the Help window.

  2. Click Options , and then select Internet Options .

  3. On the General tab, click Accessibility .

  4. Select any of the checkboxes: Ignore colors specified on webpages , Ignore font styles specified on webpages , or Ignore font sizes specified on webpages .

You also can choose to use the settings specified in your own style sheet.

To change the color of the background or text in Help

  1. Open the Help window.

  2. Click Options , and then click Internet Options .

  3. On the General tab, click Accessibility .

  4. Select the Ignore colors specified on webpages checkbox.

  5. On the General tab, click Colors .

  6. Clear the Use Windows Colors checkbox, and then select the font and background colors that you want to use.

Note: If you change the background color of the Help topics in the Help window, the change also affects the background color when you view a web page in Microsoft Internet Explorer.

To change the font in Help

  1. Open the Help window.

  2. Click Options , and then click Internet Options .

  3. On the General tab, click Accessibility .

  4. To use the same settings as those used in your instance of Microsoft Internet Explorer, select the Ignore font styles specified on webpages and Ignore font sizes specified on webpages checkboxes.

  5. To customize the font style used in Help, on the General tab, click Fonts , and then click the font style you want.

Note: If you change the font of the Help topics in the Help window, the change also affects the font when you view a Web page in Internet Explorer.


Logs

A log is generated when a verifier stop occurs during verification of an application.

Accessing Logs

Application Verifier displays a Logs window that contains the applications that have been run previously and the logs associated with them.

To access the log window

  • On the View menu, select Logs .

To view the details of a log

  • Select name of the application.

Saving/Exporting Logs to XML

If you export a log to XML, you can open the log file in Microsoft Internet Explorer or Microsoft Excel.

To export a log to XML

  1. Select the application and then the log you wish to export.

  2. Click Save As .

  3. Enter the name you want to give the file and its location, and then click Save .

Filtering Logs

You may want to filter log information on items such as Severity, to see warnings only, or to trace where you can define a custom filter to display only items that contain your application. To do so the following procedure is recommended:

To filter a log

  1. Save the log to XML and open it in Excel.

  2. In Excel, highlight the first row (containing the column headers).

  3. On the Data menu, clicking Filter , and then clicking AutoFilter .

Deleting Logs

Application Verifier enables either to delete a log individually or to remove an application and delete all logs associated with it.

To delete a log individually

  • Select the log and click Delete .

or

  • Right-clicking the log and select Delete .

To remove an application and delete all logs associated it

  • Right-click the application name and then select Delete .

To delete all logs

  1. Open the main Application Verifier window.

  2. On the File menu, select Clear All Logs .

Adding Stamps

When a process is running, you can add a stamp into its associated log file. The stamp information can be an arbitrary string, such as current time. Later you can use this information as a filter to retrieve the log of interest.

To add a stamp into a log file

  1. Select the log file, and then click Add Stamp .

  2. Enter a string as the stamp information.

Output Options

By default, the logs for services/apps running under user accounts are stored under: %USERPROFILE%\serviceprofiles\AppVerifierLogs.

For services/apps running under local service accounts, the log files are written under: %windir%\serviceprofiles\LocalService\AppVerifierLogs

For services/apps running under a system account, the log files are stored under: %windir%\system32\config\systemprofile\AppVerifierLogs for native services, and %windir%\syswow64\config\systemprofile\AppVerifierLogs for wow64 services/apps.

For services/apps running under a network service account, log files are stored under: %windir%\serviceprofiles\NetworkService\AppVerifierLogs.

If the application doesn’t have permissions to write/create the log file in the default log file path, it will fail with the error 0xC0000022.

Setting the VERIFIER_LOG_PATH environmental variable overrides the default log file creation. This can be useful if you want all your log files stored in a single location.

Protected processes don’t have access to environmental variables and hence cannot create log files. To work around this, the protected process log path can be set using the AppVerif.EXE command-line: “appverif.exe –sppath <drive:>\<path>” to set the protected log path.

The command line; “appverif.exe –cppath” clears the protected log path.

Symbol path – the symbol path will be used to resolve the stack trace in the log file. If you don’t specify a symbol path, Application Verifier will automatically look at _NT_SYMBOL_PATH to see if any symbol path is specified there.

From, to – You can specify the starting stamp and ending stamp. You will only see the log content, which is recorded after the From stamp is inserted and before the end stamp is inserted. If you do not provide a From or To stamp, Application Verifier will display the log from the very beginning of the file to the end of file respectively.

Protected Process Logging

Application Verifier log file creation depends on environment variables such as VERIFIER_LOG_PATH and %USERPROFILE%. If a process such as protected (secure) process cannot access these environment variables, it fails to create the log files. The following command line options can be used to set/clear the protected process log path. This log path is used only if the process cannot create log files under VERIFIER_LOG_PATH or %USERPROFILE%.

To set the protected process log path:

appverif –sppath [PROTECTED_PROCESS_LOG_PATH].

For ex: The following command line sets the protected process log path to “c:\My Logs\Verifier Logs”.

appverif –sppath “c:\My Logs\Verifier Logs”.

Note: Make sure that “c:\My Logs” exists and the protected process has permission to create files in this path.

The following command line shows the existing protected process log path.

appverif –sppath

To show the existing protected process log path and clear it, use the following command line:

appverif -cppath

Note that the “Application Verifier –Logs” window shows the log files in %USERPROFILE% of the logged on user. If you want the protected process logs to show up in this UI, you need to manually copy them to %USERPROFILE%\AppVerifierLogs.


Property Window

The Property window provides access to the various settings for each of the verification layers and checks.

Accessing the Property Window

The property window displays its information in the lower half of the screen.

To view the Property window

  • On the View menu, select Property Window . A check mark while appear next to the Property Window selection.

Closing the Property Window

If desired, you can remove the property window from your view.

To close the property window

  • On the View menu, select Property Window . The check mark next to the Property Window selection will be cleared.

Setting Properties

Each verification layer has its own set of properties to set and change. For more details see Setting Properties - 1.

To set a property for a verification layer

  • Select the layer within the test area (for example, Basics). This step will display the properties of the selected test.


Setting Properties

There are two sets of properties within Application Verifier. One is based on the checks within a given verification layer, whereas the other is based on the image (solution or project). These properties are accessed from the Property Window.

Available Properties

Application Verifier displays the following information for each of the properties that are allowed to be edited:

  • Name - Unique name for each of the properties

  • Type - Boolean, DWORD, String, MultipleString

  • Value - The element that can be changed and varies based on type

  • Description - The description explains what the property is.

Editing Properties for images

For each image being tested within Application Verifier, you are able to edit the following:

  • Propagate - Propagate verifier settings from parent process to child process. Note that not all tests can be propagated. If this property is enabled (box checked), settings are propagated. Otherwise, settings are not propagated.

  • AutoClr - After specified image starts to run, the verified image will clear the settings for itself. If this property is enabled (box checked), the verified image will clear the settings. Otherwise it will not clear the settings.

  • AutoDisableStop - Verifier will only complain once for the same issue found. If Verifier finds the same issue again, it will not generate an error. If this property is enabled (box checked), Verifier will generate only one error for a given issue. Otherwise Verifier will generate an error each time the issue occurs.

  • LoggingOnLocksHeld - The dll load/unload event will be logged. Verifier is doing I/O when the loader lock is held. This can cause the application to hang. If this property is enabled (box checked), the event is logged. Otherwise, the event is not logged.

  • ExceptionOnStop – For each verifier stop, exception will be raised instead of debug break. If this property enabled (box checked), each stop reported by Verifier raises an exception. Otherwise, each stop reported by Verifier breaks into the debugger.

  • MinimumMemoryOverhead – Reduce memory overhead by disabling some of the features used just for debugging. If this property is enabled (box checked), some features are disabled to reduce memory overhead. Otherwise, features are not disabled.

    Note:
    Do not enable this property unless it is absolutely necessary to reduce memory overhead. When this property is enabled, debugging information is missing, and it is more difficult to diagnose errors.

Setting/Editing Properties for checks

The properties are associated to the checks, so please refer to those topics for detailed field information. To edit the properties you can take one of two approaches:

  1. Individually - Within the property window, double click the property you wish to edit. This will display a dialog that will allow you to edit the item as well as set it back to the default. Change the entry and click OK.

  2. Group - From the Test area, click the test or verification layer you need to edit. Use your right click options to display a screen of all the properties. Change the properties or reset back to the default and click OK.


Testing Applications

To verify an application, you need to add the application to the tool, select the test(s) you would like to run, and execute the application. Following are the details.

Tests within AppVerifier

The tests included in the Application Verifier are to help software developers avoid common mistakes by using verification layers to validate the usage of API families:

  • Basics Verification Layer - These are the core set of tests that check for issues within heap, handles, locks, and more.

  • Low Resource Simulation Verification Layer - This test simulates an environment under low resources for example, out of memory.

  • Limited User Account Predictor Verification Layer - This test simulates an environment running as a user with a limited user account and has two primary goals: predictive and diagnostic. The predictive element determines whether an application that is running in an administrative environment would also run well in an environment with less privilege, as a limited user, for example. The diagnostic element evaluates an application when it is running as a limited user and identifies potential problems.

  • Miscellaneous Verification Layer- This consists of two checks Dirty Stacks and Dangerous APIs.

Test differences between the last version and v3.0

There are a few tests that you will not find within this release of Application Verifier that were in previous releases:

  • Compatibility tests

  • Design for Windows tests

  • RPC tests

  • COM tests

  • Security tests

  • Encryption tests

    • Misc programming errors [MiscProgrammingErrors]

    • Obsolete API calls [ObsoleteAPICalls]

    • Registry usage [RegistryChecks]

    • Early timer rollover [TimerRollover]

    • DirectX file version [DXFileVersionInfo]

    • Design For Windows

    These may return in the future.

    Application and System Requirements

    Remember, Application Verifier tests unmanaged code for 32 and 64 bit applications and will run on Microsoft Windows XP or greater. For more detailed information, please see Application Verifier Overview.

    Note: Although Application Verifier is for unmanaged code it does validate managed code to a degree due to many applications are mixed code (managed and unmanaged). However, the CLR does get verified.

    Start Testing an Application

    To test an application you must first add the Application to the verifier tool. You can then select the tests you want enabled, save your test setup, and run your application.

    To add an application to Application Verifier

    1. On the File menu, select Add Application .

    2. Browse to the application and click Open .

    or

    1. Right click within the Applications pane and select Add Application .

    2. Browse to the application and click Open .

    Note: After enabling the verifier for an executable file, all instances of that application on the system will be verified.

    To select the tests to run

    • Select the checkbox next to the test you want to enable.

    Selecting the checkbox next to a verification layer expands the list and selects all tests within the layer. You can then clear the tests you do not want to enable.

    To enable all tests

    • On the File menu, select Enable All Tests . All test except Low Resource Simulation will be enabled.

    or

    • Right-click the application and select Enable All Tests . All test except Low Resource Simulation will be enabled.

    Note: If you wish to apply tests to multiple applications, you must do so via the command line since multi-application-select is not available currently in the user interface.

    To save your test setup

    • When the tests you want enabled have all been selected, click Save .

    or

    • On the File menu, select Save .

    You may decide to close Application Verifier while running through your tests. Whether the Application Verifier user interface is open or closed, your application will be validated each time you run.

    The tests that were selected will check the code of the application running and the actions being taken in the application. These tests will generate logs for each application and will continue until the application is removed from the list of applications within Application Verifier.

    Note: to ensure good coverage of your application, run Application Verifier while performing all of your test cases.

    Stop Testing an Application

    Your application will continue to be checked, even when Application Verifier is closed, until you remove the application name from the tool.

    To remove an application from Application Verifier

    1. Select the name of the application

    2. On the File menu, select Delete Application .

    3. Click Save .

    Once you've made this change and saved the settings, the application will no longer run under Application Verifier.

    Note: by removing your application, it will not delete the logs that were previously generated.

    Default tests

    When an application is added to Application Verifier to test, a set of tests are already selected to run. The Basics are the default tests.

    To revert back to the default tests

    1. Select the application you want to change.

    2. On the File menu, select Restore Defaults .

    or

    • Right-click the application and select Restore Defaults.

    Setting up a Debugger

    The Basics verification layer within Application Verifier requires the application to be run under a debugger.

    Before Application Verifier will allow you to save your settings when selecting one of these, it will provide a dialog reminding you that these tests require you to run under a debugger.
    To obtain more information on how to run your application under a debugger, please refer the Debugger install and setup topic.


Using the Command Line

Application Verifier can be used via the UI or by using command line options. Following are examples of how to use the command line (below are the details):

To quickly enable Application Verifier for Handles, Heap, Lock, Exceptions, TLS, and Memory:

Copy Code
appverif /verify TARGET [/faults [PROBABILITY [TIMEOUT [DLL …]]]]
appverif /verify notepad
appverif -enable LAYER … -for TARGET ... [-with [LAYER].PROPERTY=[VALUE] …]
appverif -disable LAYER ... -for TARGET ...
appverif -query LAYER ... -for TARGET ...
appverif –configure STOP ... -for TARGET ... [-with STOPPROPERTY=[VALUE] …]
appverif –logtofile {enable|disable}

To enable Application Verifier for a specific verification layer for two applications:

Copy Code
appverif –enable Heaps Locks –for notepad.exe iexplore.exe

To enable two layers named X and Y for target test.exe with properties X.DebugLevel and Y.DebugLevel:

Copy Code
appverif –enable X Y –for test.exe –with X.DebugLevel=1 Y.DebugLevel=2

To disable all checks run on an application:

Copy Code
appverif -disable * -for notepad.exe

OR

Copy Code
appverif -delete settings -for notepad.exe

To globally enable or disable Application Verifier logging for all processes:

Copy Code
appverif –logtofile enable
appverif –logtofile disable

Logging is enabled by default for all processes.

Following are the details on running Application Verifier using the command line.

Command Line Syntax

The command line syntax accepts one or more layers and applies them to one or more targets with optional property specifiers for layers.

Copy Code
appverif -enable LAYER ... -for TARGET ... [-with [LAYER].PROPERTY=[VALUE] …]
appverif -disable LAYER ... -for TARGET ...
appverif -query LAYER ... -for TARGET ...
appverif –configure STOP ... -for TARGET ... [-with STOPPROPERTY=[VALUE] …]

where:

  • LAYER is a standard name for a verification layer. If a new verifier provider is installed then this will expose a new verification layer name to be used in the command line. Current layers are:

    • Heap

    • Locks

    • Handles

    • Etc.

    You can set LAYER to * to specify that the command applies to all layers.

  • TARGET is a binary name (e.g. notepad.exe). This is a static setting that is persisted in the registry and will be taken into consideration whenever the application is started. For the appverif –disable command, you can set TARGET to * to specify that all targets should be disabled.

  • PROPERTY is property name specific to the LAYER mentioned in the command line. For example, the Handles layer has traces as property.

  • VALUE is a value for the property. The type of the value depends on the type associated with the property and it will be enforced. The supported types for now are: boolean (true/false), integer (decimal/octal/hex in C notation), string and multi-string (containing `\0’ between strings and being terminated by `\0\0’). If VALUE is not specified it means the user wants to delete that property and revert behavior to the default value for the property.

  • STOP is the number (decimal or hex in C notation) of the verifier stop issue to be configured. The stop codes must be unique (no two layers can use the same stop code therefore the tool itself will determine to what layer the stop belongs to)

  • STOPPROPERTY is a property name that is acceptable for verifier stops. If the value is not specified it is assumed the property must be deleted. Right now the allowed properties for stops are (See Configuring Verifier Stops below for more details):

    • ErrorReport

    • Severity

    • Flavor

The properties can be optionally qualified by the layer they belong to. However, this is not needed if command line enables just one layer. For example, to enable two layers named X and Y for target test.exe with properties X.DebugLevel and Y.DebugLevel the command is:

Copy Code
appverif –enable X Y –for test.exe –with X.DebugLevel=1 Y.DebugLevel=2

However if layer X is enabled, then an unqualified property name can be used:

Copy Code
appverif –enable X –for test.exe –with DebugLevel=1

The separator character between property name and value can be `=’ (equal sign) or `:’ (colon).

Miscellaneous commands

Copy Code
appverif –query providers
appverif –delete logs –for TARGET ...
appverif –delete settings –for TARGET ...

Wipe out completely TARGET from registry.

Copy Code
appverif –stamp log –for Target –with Stamp=”LOG_STAMP”[Log= RELATIVE_TO_LAST_INDEX]

This command will stamp the log with LOG_STAMP. This stamp is useful to identify only a section of a log as relevant when viewing the log in XML form.

Copy Code
appverif –export log –for TARGET –with To=XML_FILE[Symbols=SYMBOL_PATH][Stamp=LOG_STAMP][StampTo=LOG_STAMP][Log=RELATIVE_TO_LAST_INDEX]

The command above will export a binary log to an xml file. The optional Stamp property is used to identify which part of the log should be exported to XML. If not specified then the entire log will be converted. The Log property has a negative integer as possible value and signifies what log file should be converted starting from last one (assumed if property is not present). For example, launch notepad.exe three times in a row. To access the first log created, specify Log=-2 in the command line.

Shortcuts for Command Line

Following are shortcuts:

Copy Code
appverif /verify TARGET [/faults [PROBABILITY [TIMEOUT [DLL …]]]]

where:

  • TARGET has the same meaning as described above.

  • PROBABILITY is the probability to inject faults. Must be a value in the range 0..1000000. If not specified the default value is 5%.

  • TIMEOUT is the time interval in milliseconds during process startup when fault injection does not happen. This is done to allow the process to properly startup before faults happen. If not specified the value is 500 msecs.

  • DLL is the name of module that gets loaded in the process. Typically this is the name of a dynamic library (extension .dll) but can be an ActiveX (extension .ocx) or some other loadable module.

Examples:

Copy Code
appverif /verify notepad.exe /faults 100000 1000 msvcrt.dll

Enable fault injection for notepad.exe (whenever it will be launched). Faults should happen with probability 10%, only 1000 msecs after process got launched and only for operations initiated from msvcrt.dll.

Enabling Fault Injection details

Using the /faults command line will enable fault injection just for OLE_ALLOC and HEAP_ALLOC. However, you can use the command line to configure which type of fault injection you want to turn on. For example, if you want to inject fault into a registry or file API as 2%, use the command line:

Copy Code
appverif -enable lowres -for hello.exe -with registry=20000 file=20000

Another example:

Copy Code
appverif -query lowres -for hello.exe

Settings for hello.exe:

Test [lowres] enabled.

Copy Code
Include = *
Exclude =
TimeOut = 2000 (0x7D0)
WAIT = 0 (0x0)
HEAP_ALLOC = 20000 (0x4E20)
VIRTUAL_ALLOC = 0 (0x0)
REGISTRY = 20000 (0x4E20)
FILE = 20000 (0x4E20)
EVENT = 0 (0x0)
MAP_VIEW = 0 (0x0)
OLE_ALLOC = 20000 (0x4E20)
STACKS = false

Configuring Verifier Stops

Using the command line (or user interface) you can configure verifier stops. Following are examples to leverage:

Copy Code
Appverif -configure STOP ... -for TARGET ... -with PROPERTY=VALUE ...

STOP is stop code such as 0x200 0x201

TARGET is application name such as foo.exe

PROPERTY can be one of the “ErrorReport”, “Severity”, and “Flavor”

For the ErrorReport , VALUE can be the combination of the following values.

0x00000001 means the stop is active. (If this bit is zero, it means the stop is disabled)

0x00000020 means the stop will break into debugger using a breakpoint.

0x00000040 means the stop break into debugger by generating a Verifier Exception.

0x00000080 means the stop will be logged in the log file.

0x00000100 means the stack trace for this stop will be logged in the log file.

For the Severity , VALUE can be one of followings.

0x00000003 Informative stop.

0x0000000F Warning.

0x0000003F Error.

For the Flavor , Value can be the combination of the following values.

0x00000002 Non-continuable stop.

0x00000010 This stop will only appear one time. It will be ignored the following time within the test run.

For example, disable stops 0x2700, 0x2701 for foo.exe

Copy Code
Appverif –configure 0x2700 0x2701 –for foo.exe –with ErrorReport=0

Configure stop code 0x2700 as breaking into debugger (it’s off by default), saving a log without stack trace, and make it non-continuable

Copy Code
Appverif –configure 0x2700 –for foo.exe –with ErrorReport=0xA1 Flavor=0x2


Verifier Stop Options - Advanced Settings

Application Verifier has advanced settings, such as Inactivate, that you may alter per verifier stop.

Access Verifier Stop Options

Verifier stop options are changed on a dialog that lists the available options.

To access the verifier stop options

  1. Select the name of a test in the Tests pane.

  2. On the Edit menu, select Verifier Stop Options .

or

  • Right-click the test and select Verifier Stop Options .

Verifier Stop Options

You may alter the following elements per verifier stop listed by clicking the stop code (note that a description of the stop will appear when clicked):

  • Inactive is a checkbox that when selected will deactivate the verifier stop code from being run.

  • Severity determines how the verifier stop should be flagged:

    • Ignore

    • Information

    • Warning

    • Error

  • Error Reporting determines how you would like the specific verifier stop to be reported/logged:

    • Log to File - a checkbox that when selected will log to the designated file.

    • Log Stack Trace - a checkbox that when selected will log the stack traces when they are available.

    • No Break - an option not to break in the debugger.

    • Exception - an option along with no break and breakpoint

    • Breakpoint - an option along with no break or exception.

  • Miscellaneous provides two options

    • Stop Once - a checkbox that when selected will only stop on that error once when testing an application.

    • Not Continuable - a checkbox that when selected will not allow you to continue without investigating.


Tests within Application Verifier

This section provides information on each of the tests available in Application Verifier. Simply expand this section and click on the topic that interests you.


Basics Verification Layer

The Basics verification layer consists of tests for:

  • Exceptions Stop Details - ensures that applications do not hide access violations using structured exception handling.

  • Handles Stop Details - tests to ensure the application is not attempting to use invalid handles.

  • Heaps Stop Details - checks for memory corruptions issues in the heap.

  • Leak Stop Details - detects leaks by tracking the resources made by a dll that are not freed by the time the dll was unloaded.

  • Locks Stop Details - verifies the correct usage for critical sections.

  • SRWLock Stop Details - verifies the correct usage for slim reader/writer (SRW) locks.

  • Memory Stop Details - ensures APIs for virtual space manipulations are used correctly (e.g. VirtualAlloc, MapViewOfFile).

  • TLS Stop Details - ensures that Thread Local Storage APIs are used correctly.

  • Threadpool Stop Details- the threadpool verification ensures correct usage of threadpool API’s and enforces consistency checks on worker-thread-states after a callback.


Limited User Account Predictor Verification Layer

The Limited User Account Privilege Predictor (LuaPriv) has two primary goals:

  1. Predictive: While running an application with administrative privilege, predict whether that application would work as well if run with less privilege (generally, as a normal user). For example, if the application writes to files that only allow Administrators access, then that application won’t be able to write to the same file if run as a non-administrator.

  2. Diagnostic: When running as a non-administrator, identify potential problems that may already exist with the current run. Continuing the previous example, if the application tries to write to a file that only grants members of the Administrators group access, the application will get an ACCESS_DENIED error. If the application doesn’t operate correctly, this operation may be the culprit.

The types of problems that LuaPriv identifies are as follows:

Potential Issue

Description

Restricted Namespaces

Creating a named synchronization object (Event, Semaphore, Mutex, etc) without a namespace may complicate running without privilege on some operating systems because the operating system may choose to place the object in a restricted namespace.

Creating such an object in a restricted namespace (such as the Global namespace) requires SeCreateGlobalPrivilege, which is only granted to administrators.

LuaPriv flags both these issues if it detects them.

Hard Administrator Checks

Some applications interrogate the user’s security token to find out how much privilege he/she has. In those cases, the application may change its behavior depending on how much power it thinks the user is granted.

LuaPriv flags API calls that return this information.

Requesting Privileges

An application may attempt to enable a security-relevant privilege (such as SeTcbPrivilege or SeSecurityPrivilege) prior to performing an operation that requires it.

LuaPriv flags attempts to enable privileges that are security-relevant.

Missing Privileges

If an application attempts to enable a privilege that the user doesn’t have, it probably signals that the application expects the privilege, which can cause behavior differences. So, LuaPriv flags failed privilege requests.

INI-file operations

Attempts to write to mapped INI files (WritePrivateProfileSection and similar APIs) can fail as a non-administrator user. LuaPriv flags such operations.

Access Denied

If the application attempts to access an object (File, registry key, etc) but the attempt fails due to insufficient access, then the application probably expects to be running with more privilege than it has. LuaPriv flags object-open attempts that fail with ACCESS_DENIED and similar errors.

Deny ACEs

If an object has Deny ACEs in its DACL, then it explicitly denies access to specific entities. This is uncommon, and makes prediction difficult, so LuaPriv flags Deny ACEs when it finds them.

Access Restricted

If an application attempts to open an object for rights that are not granted to normal users (for example, trying to write to a file that’s only writeable by administrators), then the application probably won’t work the same when run as a normal user.

LuaPriv flags such operations.

MAXIMUM_ALLOWED

If an application opens an object for MAXIMUM_ALLOWED, then the actual access check on the object will occur elsewhere. Most code that does this doesn’t work correctly, and will almost certainly work differently when run without privilege.

LuaPriv thus flags all incidents of MAXIMUM_ALLOWED.


Miscellaneous Verification Layer

The Miscellaneous verification layer consists of the following checks. For more information, please see the topics:

  • Dangerous APIs Stop Details

  • Dirty Stacks Stop Details

  • Time Rollover


Low Resource Simulation Verification Layer

Low resource simulation tries to simulate an environment under low resources, such as out of memory. This simulation will identify bugs that occur in low memory conditions. This is also referred to as Fault Injection.

This verification layer also includes Stacks.


Compatibility Verification Layer

Compatibility Verification Layer tests help to identify an application that may have problems with Microsoft Windows operating system. Many of these checks can also be used to test for the Designed for Windows Logo requirements.

For more information on the Compatibility Verification Layers see the individual Verifier Stop Codes for Compatibility and Designed for Windows. For more information on Logo requirements visit the Windows Logo webpage.


Cuzz Verification Layer

The Concurrency Fuzzing (Cuzz) verification layer detects concurrency bugs and data race conditions. Cuzz adjusts thread scheduling by injecting random delays at key points in an application's code. The following scenario illustrates the type of concurrency bug that could be detected by the Cuzz verification layer.

An application has a parent thread and a child thread. The parent thread starts the child thread and then allocates memory for a structure.

Copy Code
// Parent Thread
StartChildThread(...);
g_pointer = ... malloc(...);

The child thread dereferences the pointer.

Copy Code
//Child Thread
LONG value = g_pointer->someMember;

The preceding code has a concurrency bug. If the child thread attempts to dereference the pointer before the parent thread allocates the memory, the pointer will be invalid. The bug is very unlikely to manifest itself, because in most cases, the parent thread will allocate the memory before the child thread gets started. But in rare cases, the child thread could get started and attempt to dereference the pointer before the parent thread has allocated the memory.

The Cuzz verification layer increases the likelihood of finding concurrency bugs like the one illustrated in the preceding example. Cuzz does not perform any additional checks apart from inserting delays. As such, there are no verification stops directly associated with Cuzz. However, if enabling Cuzz results in a concurrency bug manifesting itself, other verification layers will benefit. For instance, if a race condition results in a heap overflow, the Heaps verification layer will not find the error unless the race condition manifests itself at run time. By increasing the probability of the race condition occurring, Cuzz improves the effectiveness of the Heaps layer in identifying the error.

To get the maximum benefit of Cuzz, enable Cuzz on as many tests as possible, and repeat the same test many times. Cuzz can be enabled on all tests, including manual tests, functional tests, and stress tests. Also, enable as many Application Verifier verification layers as possible.

You can increase the probability of reproducing a bug by providing Cuzz with the same random seed (see Properties).

The current version of Cuzz inserts delays only on Win32 synchronization API calls.

Properties

The following properties are available for the Cuzz verification layer. To set the properties, select the Cuzz layer in the Application Verifier user interface, and open the Property Window.

Property | Description
FuzzingLevel | Controls the fuzzing level for Cuzz. Set this to 1 for time-critical applications and 4 for regular applications.
RandomSeed | The random seed used by Cuzz at start. If you set this to 0, Cuzz generates a time-based random seed.


Print Verification Layer

Print Verifier is a tool that is designed to help find and troubleshoot issues that may result when the print subsystem is called by an application. Print Verifier targets the two layers of the print subsystem, the PrintAPI layer and the PrintDriver layer..

Print API Layer

Print Verifier tests the interface between a program and Winspool.drv and prntvpt.dll as also test the interfaces of those DLLs. The rules for calling functions in this interface are defined in the MSDN in the help on the APIs exported by winspool.drv and prntvpt.dll.

Print Driver layer

Print Verifier also tests the interface between a core print driver such as UNIDRV.DLL, UNIDRUI.DLL, PSCRIPT5.DLL, PS5UI.DLL, or MXDWDRV.DLL, and the print driver plugins. This interface is described in the MSDN and the WDK.


NTLM Verification Layer

This Application Verifier plug-in monitors an individual process’ calls to the authentication APIs AcquireCredentialsHandle and InitializeSecurityContext in order to detect uses of the NTLM protocol.

Why the NTLM Plug-in is Needed

NTLM is an outdated authentication protocol with flaws that potentially compromise the security of applications and the operating system. The most important shortcoming is the lack of server authentication, which could allow an attacker to trick users into connecting to a spoofed server. As a corollary of missing server authentication, applications using NTLM can also be vulnerable to a type of attack known as a “reflection” attack. This latter allows an attacker to hijack a user’s authentication conversation to a legitimate server and use it to authenticate the attacker to the user’s computer. NTLM’s vulnerabilities and ways of exploiting them are the target of increasing research activity in the security community.

Although Kerberos has been available for many years, many applications are still written to use NTLM only. This needlessly reduces the security of applications. Kerberos cannot however replace NTLM in all scenarios – principally those where a client needs to authenticate to systems that are not joined to a domain (a home network perhaps being the most common of these). The Negotiate security package allows a backwards-compatible compromise that uses Kerberos whenever possible and only reverts to NTLM when there is no other option. Switching code to use Negotiate instead of NTLM will significantly increase the security for our customers while introducing few or no application compatibilities. Negotiate by itself is not a silver bullet – there are cases where an attacker can force downgrade to NTLM but these are significantly more difficult to exploit. However, one immediate improvement is that applications written to use Negotiate correctly are automatically immune to NTLM reflection attacks.

By way of a final word of caution against use of NTLM: In Windows 7 and Windows Server 2008 R2 and later versions of Windows it is possible to disable the use of NTLM at the operating system level. If applications have a hard dependency on NTLM they will simply fail to authenticate when NTLM is disabled.

What factors cause NTLM to be “hard-coded” in an application?

There are two factors that will cause a hard dependency on NTLM. The first is explicitly selecting NTLM as the authentication package to be used by the application. For some protocols and APIs the choice of NTLM is obvious, such as in the call to the API AcquireCredentialsHandle (). For other protocols, it may not be so obvious. For example, RPC’s default authentication package (RPC_C_AUTHN_DEFAULT) is actually an alias to NTLM when RPC is used over the network and even the explicit flag to select NTLM doesn’t have the NTLM abbreviation anywhere in it (RPC_C_AUTH_WINNT). This kind of construct makes it easier to select NTLM without necessarily knowing you have done so.

In place of NTLM, developers should use the Negotiate package (this is also sometimes referred to as the SPNEGO or SNEGO package). Package selection needs to match on both client and server components in order for Negotiate to be able to attempt to use Kerberos - so both client and server parts of the application need to use Negotiate. If either side uses NTLM (as might be the case with legacy versions) Negotiate will still work but will always revert to NTLM. How to tell your application to use Negotiate varies by protocol. Some of the most common protocols (RPC, LDAP, DCOM, HTTP) are covered in detail later in topic 5000 – Application Has Explicitly Selected NTLM Package.

The second factor that results in NTLM being used is when the client does not supply a valid server target name to the authentication process. In protocols that support or require mutual authentication (such as Kerberos) the target name is what is used to achieve mutual authentication. Authentication APIs (such as InitializeSecurityContext ) take an optional parameter, usually called something like “TargetName”, “PrincipalName” or “ServerPrincipalName”. This is the identifier used by domain controllers to select the correct domain account for obtaining credentials for the target service. Since NTLM has no concept of server authentication this parameter is not required for NTLM to successfully authenticate. Kerberos, on the other hand, requires that a client obtains a service ticket that is valid for the service that the client is authenticating to. Kerberos authentication will always fail if no target name or an invalid target name is specified. When Negotiate is selected as the package, supplying no target name (or an invalid target name) will cause Kerberos to be skipped altogether and NTLM to be used. Most authentication APIs have the target name as an optional parameter will accept if NULL without error. Unless the developer overrides this and provides an explicit target name, NTLM, (and moreover, reflectable NTLM) is the result.

How the Plug-in Works

The Verifier plug detects the following errors:

•The NTLM package is directly specified in the call to AcquireCredentialsHandle (or higher level wrapper API).

•The target name in the call to InitializeSecurityContext is NULL. In this case, Negotiate falls back to NTLM directly.

•The target name in the call to InitializeSecurityContext is not a properly-formed SPN, UPN or NetBIOS-style domain name. In this case, the domain controller returns a “principal not found” error, which causes Negotiate to fall back to NTLM.

The plug-in also logs warnings when it detects downgrades to NTLM; for example, when an SPN is not found by the Domain Controller. These are only logged as warnings since they are often legitimate cases – for example, when authenticating to a system that is not domain-joined.

Configuring Plug-in Stop Options

By default all events categorized as Error are set to cause a debug break. All warning events are set to log the event details only.

Error Events cause a Stop/Break:

•5000 – Application Has Explicitly Selected NTLM Package

•5001 – Negotiate Package List Includes only NTLM

•5002 – Negotiate Package List Wrong NTLM Exclusion

•5003 – No target name or malformed target name for Server

Warning Events logged:

5010 – Downgrade to NTLM Detected

NTLM Stops

5000 – Application Has Explicitly Selected NTLM Package

Severity – Error

The application or subsystem explicitly selects NTLM instead of Negotiate in the call to AcquireCredentialsHandle. Even though it may be possible for the client and server to authenticate using Kerberos this is prevented by the explicit selection of NTLM.

How to Fix this Error

The fix for this error is to select the Negotiate package in place of NTLM. How this is done will depend on the particular Network subsystem being used by the client or server. Some examples are given below. You should consult the documentation on the particular library or API set that you are using.

APIs(parameter) Used by Application | Incorrect Value | Correct Value | Notes
AcquireCredentialsHandle (pszPackage) | “NTLM” | NEGOSSP_NAME or “Negotiate” |
RPC Client: RPCBindingSetAuthInfoEx RPCBindingSetAuthInfoEx (AuthnSv) RPC Server: RPCServerRegisterAuthInfo(AuthnSvc) | RPC_C_AUTHN_WINNT or RPC_C_AUTH_DEFAULT | RPC_C_AUTH_GSS_NEGOTIATE | It is not an error for an RPC server to register the NTLM/WINNT package. This is often required to support older clients that only support NTLM. It is an error if only the NTLM package is registered since this forces all clients to use NTLM even if they are capable of using Kerberos.
DCOM: SetBlanket CoSetProxyBlanket (dwAuthnSvc) CoCreateInstanceEx (passed as dwAuthnSvc member of COAUTHINFO structure, which itself is a member of the COSERVERINFO struct passed to the API) | RPC_C_AUTHN_WINNT | RPC_C_AUTHN_DEFAULT or RPC_C_AUTHN_GSS_NEGOTIATE | Negotiate should only be used if the communication always occurs across a network. If the DCOM call ever occurs between client and server on the same machine you must use DEFAULT and allow DCOM to choose the correct package to use.
LDAP: ldap_bind_s (method) | LDAP_AUTH_NTLM | LDAP_AUTH_NEGOTIATE |
HTTP WinHTTPSetCredentials (AuthScheme) | WINHTTP_AUTH_SCHEME_NTLM | WINHTTP_AUTH_SCHEME_NEGOTIATE |

5001 – Negotiate Package List Includes only NTLM

Severity – Error

When using AcquireCredentialsHandle it is possible to supply a list of packages to be used or ignored by Negotiate. Depending on the list specified, this may override the logic built into Negotiate for choosing the most appropriate and secure authentication package. If the package list includes only NTLM or excludes Kerberos the result is identical to bypassing Negotiate altogether and explicitly selecting the NTLM SSP package directly.

Specifying a sub-package list is only possible when calling AcquireCredentialsHandle directly since most higher-layer APIs (such as RPC) do not allow the caller to control the Negotiate package list.

Microsoft does not recommend that applications try to manipulate the Negotiate package list in this way.

How to Fix this Error

Use the Negotiate package without specifying a list of subpackages or ensure that Kerberos is included.

APIs(parameter) Used by Application | Incorrect Value | Correct Value
AcquireCredentialsHandle (PackageList member of SEC_WINNT_AUTH_IDENTITY_EX struct passed as pAuthData parameter) | “!Kerberos” or “NTLM” | NULL or “Kerberos, NTLM” or “Kerberos, !NTLM” or “!NTLM”

5002 – Negotiate Package List Wrong NTLM Exclusion

Severity - Warning

When calling AcquireCredentialsHandle the application has attempted to exclude NTLM from the list of packages supported by Negotiate. However, the wrong syntax has been used to exclude NTLM, so it remains in the list.

How to Fix this Error

Use the following syntax to exclude the NTLM package from Negotiate:

APIs(parameter) Used by Application | Incorrect Value | Correct Value
AcquireCredentialsHandle (PackageList member of SEC_WINNT_AUTH_IDENTITY_EX struct passed as pAuthData parameter) | “-NTLM” | “!NTLM”

5003 – No target name or malformed target name for Server

Severity – Error

When using the Negotiate package, supplying a null or invalid target name (sometimes referred to as principal name) will cause Kerberos to fail and NTLM to be used in its place. You should always specify a valid target name when making an authentication call. The target name is a unique identifier that allows a domain controller to obtain the account details of the server that your application is trying to authenticate to. Once the domain controller has this information it can build appropriate Kerberos tickets that will be understood (decryptable) by both the client and the server.

How to Fix this Error

Target names can be specified in three different formats, each of which is can be used by domain controllers to locate the correct server account object. These formats are Service Principal Name (SPN), User Principal Name (UPN) and NetBIOS two-part domain\account name. The SPN is the most common form and the most interoperable with other Kerberos implementations. A full discussion of SPNs is beyond the scope of this document but the simplest and most common SPN form has two parts – a service class and a host name. The service class identifies the type of server application (e.g. specific application type like http or ldap or as generic as host).The second part is either the fully qualified domain name or flat (NetBIOS) name of the server. Windows clients and servers automatically register SPNs for “host” for the FQDN and flat names. Domain controllers will also map around 40 application-specific service classes on to the “host” SPN for things like “http”, “ldap”, “rpc”, “tapi”, etc. <<Technet Ref>>. o specify a target name for an application running in the context of the server operating system (e.g. localsystem, network service or localservice) client applications can use the automatically-registered “host” SPN or one of its aliases. To authenticate to an application running in the context of a domain user account you must register an SPN for that account.

For user accounts you can also use the implicit UPN form that built from the user account name tha and the domain that the account resides in: useraccountname@domain.dom. Although you can create additional UPNs for user account (using the UPN suffixes that can be created for each domain) these will not work as Kerberos targetnames – only the UPN corresponding to the actual logon account name and actual domain where the account lives can be used.

Finally you can still use the NT4-style domain\username (or domain\computername in the case of services running as localsystem, networkservice or localservice). This works for targets that are running in the context of domain user account or computer accounts.

APIs(parameter) Used by Application | Parameter to set target name | Notes
InitializeSecurityContext | pszTargetName |
RPC Client: RPCBindingSetAuthInfoEx RPCBindingSetAuthInfoEx (AuthnSv) | ServerPrincipalName | This should be the target name for the account under which the server/service is running. It does not have to be the same as the value set in RPCServerRegisterAuthInfo
DCOM: SetBlanket CoSetProxyBlanket (dwAuthnSvc) CoCreateInstanceEx (passed as dwAuthnSvc member of COAUTHINFO structure, which itself is a member of the COSERVERINFO struct passed to the API) | pServerPrincName | Can use COLE_DEFAULT_PRINCIPAL to let COM automatically select name from binding information
LDAP: none |  | Automatically generated by LDAP client.
HTTP none |  | WinHTTP and WinInet supply the targetname from the URL server name

5010 – Downgrade to NTLM Detected

Severity - Warning

Even though the application specific Negotiate and used a correctly-formatted target name something occurred to cause Negotiate to downgrade to NTLM. Depending on what the circumstances were this may indicate an error or expected behavior. For example, when a computer is not part of a domain or is being used in a location where a domain controller is not accessible it is expected that Negotiate will silently downgrade to allow the application to authenticate using NTLM. However, if this stop occurs when a domain controller is available and you would normally expect Kerberos to be used it almost certainly indicates that something is wrong.

How to Fix This Error

Assuming that you have determined that Kerberos should have been used and not NTLM in this circumstance, there are a number of possibilities why the downgrade took place:

•The target name, even though it may have been in the correct format, did not exist in the domain (or forest).

oYou should check that you are building the correct target name in the client application. Is the service class correct? Is the host name correct?

oIs the server process running in the context of the computer or another domain account. In the former case SPNs are automatically registered, in the latter case you may have to register the SPN or use an alternative form such as an implicit UPN or a flat name.

oMight there be network connectivity problems preventing communication with a domain controller or DNS server?

oIs the target SPN registered on more than one account? This will cause the domain controller to reject authentication attempts to it.


Net Verification Layer

Properties

The following properties are available for the Net verification layer. To set the properties, select the Networking provider in the Application Verifier user interface, and open the Property Window.

Property | Description
FragmentsEnabled | Enables the fragmenting of data streams received by TCP IPv4 and IPv6 sockets.
FragmentSize | Specifies the maximum number of bytes returned into a buffer to any Winsock receive API call.

The FragmentsEnabled property enables functionality in the Networking verifier provider to facilitate testing and verification of an application parsing TCP streams off of a network. Once enabled, all calls to Winsock to receive data will only receive up to FragmentSize bytes unless the application specifically requires the entire buffer filled before returning (controlled by the MSG_WAITALL flag). Since neither the TCP protocol nor Winsock provide any guarantees about the number of bytes possibly returned into a buffer, enabling this check will facilitate verifying that the code parsing the stream of data off of the network does so correctly, independently of the number of bytes received per call to Winsock. Issues in stream parsers have been a source of high-profile bugs, and these properties are provided to ease verification of correctness, as this is particularly difficult to test. Note: This does not change the data returned – it only slows it down at a specific rate: the application should behave exactly same fashion with this enabled or disabled.

The following command line enables the fragmentation of all incoming TCP streams to all TCP IPv4 and IPv6 sockets created in myApp.exe and all binaries loaded by myApp.exe.

Copy Code
appverif -enable Networking -for myApp.exe -with Networking.FragmentsEnabled=True Networking.FragmentSize=10

!avrf Debugger Extension

!avrf -net -socket count displays open and closed socket handle count

!avrf -net -socket dump [-v] [HANDLE] displays socket handle(s), verbosely or not.

!avrf -net -wsastacks displays the current WSA init count and chronological list of stack traces for WSAStartup/WSACleanup.

!avrf -net -wsastacks count displays the current WSA init count.

!avrf -net -socket count

This command will give the overall number of socket handles that are being tracked, both opened and closed. Note that these are tracked in a circular queue, so there is a ceiling to the total being tracked. Sockets are added to the opened list when one of the Winsock APIs which allocates a socket handle is called. For example, socket(), WSASocket(), accept(). Sockets are moved from the opened list to the closed list when the closesocket() function is called on that socket handle.

!avrf -net -socket dump [-v] [HANDLE]

This command will enumerate the socket handles. "-socket dump" will list all tracked opened and closed socket handles by their SOCKET values. The optional -v flag will additionally print the open or close call stack immediately after printing each SOCKET value. The optional HANDLE field will list only the specified SOCKET handle and its open or close call stack.

Here are example of the various -socket usage options:

Copy Code
0:008> !avrf -net -socket count
Number of open socket handles   = 16
Number of closed socket handles = 12

0:008> !avrf -net -socket dump
CLOSED SOCKET HANDLE - 0x47c
CLOSED SOCKET HANDLE - 0x2cc
CLOSED SOCKET HANDLE - 0x8c4
CLOSED SOCKET HANDLE - 0x6bc
CLOSED SOCKET HANDLE - 0x44c
CLOSED SOCKET HANDLE - 0x578
CLOSED SOCKET HANDLE - 0x6f4
CLOSED SOCKET HANDLE - 0x5b4
CLOSED SOCKET HANDLE - 0x4d8
CLOSED SOCKET HANDLE - 0x3cc
CLOSED SOCKET HANDLE - 0x4fc
CLOSED SOCKET HANDLE - 0x4e0
OPEN SOCKET HANDLE - 0xfd4
OPEN SOCKET HANDLE - 0x7d8
OPEN SOCKET HANDLE - 0xf8c
OPEN SOCKET HANDLE - 0xf88
OPEN SOCKET HANDLE - 0xae0
OPEN SOCKET HANDLE - 0xe58
OPEN SOCKET HANDLE - 0xdfc
OPEN SOCKET HANDLE - 0xcf8
OPEN SOCKET HANDLE - 0xa18
OPEN SOCKET HANDLE - 0x7a0
OPEN SOCKET HANDLE - 0x7b0
OPEN SOCKET HANDLE - 0x534
OPEN SOCKET HANDLE - 0xcdc
OPEN SOCKET HANDLE - 0x1f0
OPEN SOCKET HANDLE - 0x444
OPEN SOCKET HANDLE - 0x8bc

0:008> !avrf -net -socket dump -v 0x47c

The socket handle is closed

vfNet!VfHookclosesocket
WININET!ICSocket::_UnSafeCloseSocket
WININET!ICSocket::Dereference
WININET!CFsm_GetConnection::RunSM
WININET!CFsm::Run
WININET!DoFsm
WININET!HTTP_REQUEST_HANDLE_OBJECT::OpenConnection_Fsm
WININET!CFsm_OpenConnection::RunSM
WININET!CFsm::Run
WININET!DoFsm
WININET!HTTP_REQUEST_HANDLE_OBJECT::OpenConnection
WININET!HTTP_REQUEST_HANDLE_OBJECT::MakeConnection_Fsm
WININET!CFsm_MakeConnection::RunSM
WININET!CFsm::Run
WININET!DoFsm
WININET!HTTP_REQUEST_HANDLE_OBJECT::SendRequest_Fsm
WININET!CFsm_SendRequest::RunSM
WININET!CFsm::Run
WININET!DoFsm
WININET!HTTP_REQUEST_HANDLE_OBJECT::HttpSendRequest_Start
WININET!CFsm_HttpSendRequest::RunSM
WININET!CFsm::Run
WININET!CFsm::RunWorkItem
SHLWAPI!ExecuteWorkItemThreadProc
vfbasics!AVrfpRtlWorkerCallback
ntdll!RtlpTpWorkCallback
ntdll!TppWorkerThread
kernel32!BaseThreadInitThunk
ntdll!__RtlUserThreadStart
ntdll!_RtlUserThreadStart

!avrf -net -wsastacks [count]

[background] Winsock requires application developers to call the WSAStartup() at least once before making any Winsock calls. This is tracked by Winsock process-wide. The initial reference count instructs a Winsock library (ws2_32.dll) to initialize and load the Winsock catalog and providers. Further calls to WSAStartup increments that reference count. Winsock also requires application developers to call WSACleanup() when they have 'finished'calling into Winsock. The calls to WSACleanup must be paired correctly with a prior call to WSAStartup(). The call to WSACleanup() decrements the process-wide reference count. When the reference count falls to zero, Winsock releases its resources and unloads the Winsock catalog and providers.

This command will give the overall reference count value of the current "WSAStartup" initialization routine and lists the call stacks to calls to WSAStartup and WSACleanup made within the process. Note that this is maintained within a fixed circular queue, so it is not guaranteed to be complete - only the N most recent calls.

Here are example of the various -wsastacks usage options:

Copy Code
0:008> !avrf -net -wsastacks count

Current WSARefCount: 1 (WSAStartup call count minus WSACleanup call count for the target process)

0:008> !avrf -net -wsastacks

Current WSARefCount: 1 (WSAStartup call count minus WSACleanup call count for the target process)

THREAD ID: 0xe4c called WSAStartup
vfNet!WSAInitStacks<NetAllocatorViaPrivateHeap>::AddWSAStackTrace
vfNet!VfHookWSAStartup
WININET!LoadWinsock
WININET!GlobalDataInitialize
WININET!InternetSetOptionA
WININET!InternetSetOptionW
IEFRAME!LCIEUpdateSessionStartTime
IEFRAME!LCIETab_ThreadProc
iertutil!_IsoThreadProc
vfbasics!AVrfpStandardThreadFunction
kernel32!BaseThreadInitThunk
ntdll!__RtlUserThreadStart
ntdll!_RtlUserThreadStart


Webservices API Layer

Windows Webservices API (WWSAPI) Verification Layer

The WWSAPI plug-in allows developers to catch instances of:

1) A WWSAPI being called which references an invalid intrinsic WWSAPI object.

2) A WWSAPI being called which references a single threaded object already in use.

3) An intrinsic object freed with an asynchronous call pending.

4) Calling blocking APIs from short threads.

Additionally, this plug-in:

5) Tracks the use of objects from instantiation to deletion.

6) Force calls that can be completed asynchronously to be completed synchronously. This is to prevent applications depending on a particular behavior from a call taking a WS_ASYNC_CONTEXT.

7) Provides a human readable description when an API is passed a bad object, or an object is in use using the !avrf –ws –obj debugger extension (shown below)

8) For channel, service proxy and service host, each call tracked will show the current state of the object.

By default, the following checkers are enabled:

Property NameDescriptionValidateObjectValidates that the intrinsic object is validTrackObjectTracks the use of an object through its lifetime

Other checkers that can be enabled in this provider through the properties UI are:

Property NameDescriptionCheckTimeoutValidates that async functions are completed within the timeout (specified as TimeoutValForceSyncForce the sync path to be taken when a WS_ASYNC_CONTEXT context is supplied to an API.

A debugger extension is provided (!avrf –ws –obj) which displays opened and closed intrinsic WWSAPI objects. If this extension is suffixed by an object, it will display verbose information about the usage of this object.

!avrf -ws –obj

This command displays the intrinsic WWSAPI objects which are being tracked, both created and closed. Note that the closed objects are stored in a circular queue, so there is a ceiling to the total number of objects tracked.

Objects are added when the following APIs successfully complete: WsCreateChannel(), WsCreateChannelForListener(), WsCreateServiceHost(), WsCreateServiceProxy(), WsCreateServiceProxyFromTemplate(), WsCreateError(), WsCreateHeap(), WsCreateListener(), WsCreateMetadata(), WsCreateMessage(), WsCreateMessageForChannel(), WsCreateReader(), WsCreateWriter(), WsCreateXmlBuffer(), WsReadXmlBuffer(), WsReadXmlBufferFromBytes()

Objects are moved from the created to the freed list when the corresponding WsFree*() function is called and completes.

!avrf –ws –obj [OBJECT]

This command displays the usage of an intrinsic WWSAPI object. The usage information includes the stack when the object was created, used and freed. If the object is a channel, service host or service proxy, it will display the state of the object prior to the API using the object is called.

Here is an example of the !avrf –ws –obj usage options:

Copy Code
0:001> !avrf -ws -obj
Objects dependent on internal objects allocated:

Objects currently allocated:

 0x00000000048566C0 (Type=Heap, Thread=0x000001bc, Pending Operations=0)
 0x0000000001BE6780 (Type=Error, Thread=0x000001bc, Pending Operations=0)
 0x0000000001C13580 (Type=Service Proxy, Thread=0x000001bc, Pending Operations=0)

Freed objects:

 0x0000000001C17170 (Type=Service Proxy, Thread=0x000001bc)
 0x0000000004856730 (Type=Heap, Thread=0x000001bc)
 0x0000000001BE6820 (Type=Error, Thread=0x000001bc)

0:001> !avrf -ws -obj 0x0000000001C13580

Object @ 0x0000000001C13580
        Type = Service Proxy
        Thread = 0x000001bc
        Internal Reference = 0x00000000026C5E80

Created stack:
  vfnws!VfHookWsCreateServiceProxy+0x00aa
  BLUESTONE!WST_WebServices::WsCreateServiceProxy+0x00d8
  BLUESTONE!ServiceProxy::Connect+0x0116
  BLUESTONE!ServiceModel_SimpleTest::SimpleClient+0x0607
  BLUESTONE!ServiceModelTestGroup_Simple_Test02_Run+0x0041
  BLUESTONE!Fnshell2::FnshellConfiguration::RunTest+0x002e
  BLUESTONE!Fnshell2::TESTCASE::Run+0x00d6
  BLUESTONE!fnsMsgProc+0x02d6
  BLUESTONE!fnsRunTestsWorkerThread+0x085f
  KERNEL32!BaseThreadInitThunk+0x000d
  ntdll!RtlUserThreadStart+0x001d

Last 4 operations

Operation #1 created in thread 0x00000000000001BC

Service proxy state before operation = Created

Callstack:
  vfnws!VfHookWsGetServiceProxyProperty+0x0053
  BLUESTONE!WST_WebServices::WsGetServiceProxyProperty+0x009b
  BLUESTONE!ServiceProxy::GetState+0x004b
  BLUESTONE!ServiceProxy::VerifyState+0x001c
  BLUESTONE!ServiceProxy::Connect+0x01c7
  BLUESTONE!ServiceModel_SimpleTest::SimpleClient+0x0607
  BLUESTONE!ServiceModelTestGroup_Simple_Test02_Run+0x0041
  BLUESTONE!Fnshell2::FnshellConfiguration::RunTest+0x002e
  BLUESTONE!Fnshell2::TESTCASE::Run+0x00d6
  BLUESTONE!fnsMsgProc+0x02d6
  BLUESTONE!fnsRunTestsWorkerThread+0x085f
  KERNEL32!BaseThreadInitThunk+0x000d
  ntdll!RtlUserThreadStart+0x001d

Operation #2 created in thread 0x00000000000001BC

Service proxy state before operation = Created

Callstack:
  vfnws!VfHookWsOpenServiceProxy+0x0079
  BLUESTONE!WST_WebServices::WsOpenServiceProxy+0x0092
  BLUESTONE!ServiceProxy::Connect+0x03d3
  BLUESTONE!ServiceModel_SimpleTest::SimpleClient+0x0607
  BLUESTONE!ServiceModelTestGroup_Simple_Test02_Run+0x0041
  BLUESTONE!Fnshell2::FnshellConfiguration::RunTest+0x002e
  BLUESTONE!Fnshell2::TESTCASE::Run+0x00d6
  BLUESTONE!fnsMsgProc+0x02d6
  BLUESTONE!fnsRunTestsWorkerThread+0x085f
  KERNEL32!BaseThreadInitThunk+0x000d
  ntdll!RtlUserThreadStart+0x001d

Operation #3 created in thread 0x00000000000001BC

Service proxy state before operation = Open

Callstack:
  vfnws!VfHookWsGetServiceProxyProperty+0x0053
  BLUESTONE!WST_WebServices::WsGetServiceProxyProperty+0x009b
  BLUESTONE!ServiceProxy::GetState+0x004b
  BLUESTONE!ServiceProxy::VerifyState+0x001c
  BLUESTONE!ServiceProxy::Connect+0x0484
  BLUESTONE!ServiceModel_SimpleTest::SimpleClient+0x0607
  BLUESTONE!ServiceModelTestGroup_Simple_Test02_Run+0x0041
  BLUESTONE!Fnshell2::FnshellConfiguration::RunTest+0x002e
  BLUESTONE!Fnshell2::TESTCASE::Run+0x00d6
  BLUESTONE!fnsMsgProc+0x02d6
  BLUESTONE!fnsRunTestsWorkerThread+0x085f
  KERNEL32!BaseThreadInitThunk+0x000d
  ntdll!RtlUserThreadStart+0x001d

Operation #4 created in thread 0x00000000000001BC

Service proxy state before operation = Open

Callstack:
  vfnws!VfHookWsCall+0x00a6
  BLUESTONE!DefaultBinding_ICalculator_Add+0x008b
  BLUESTONE!ServiceModelTestGroup_Simple_Function+0x010a
  BLUESTONE!ServiceModel_SimpleTest::SimpleClient+0x069a
  BLUESTONE!ServiceModelTestGroup_Simple_Test02_Run+0x0041
  BLUESTONE!Fnshell2::FnshellConfiguration::RunTest+0x002e
  BLUESTONE!Fnshell2::TESTCASE::Run+0x00d6
  BLUESTONE!fnsMsgProc+0x02d6
  BLUESTONE!fnsRunTestsWorkerThread+0x085f
  KERNEL32!BaseThreadInitThunk+0x000d
  ntdll!RtlUserThreadStart+0x001d

Asynchronous Callback = BLUESTONE!ServiceModelTestGroup_Simple_Callback
Asynchronous CallbackState = 0x0000000005EBDC30

Completed asynchronously with HRESULT=0x00000000 in thread 0x00000000000001BC

Asynchronous callback stack:
  vfnws!VfHookWsCall+0x00e3
  BLUESTONE!DefaultBinding_ICalculator_Add+0x008b
  BLUESTONE!ServiceModelTestGroup_Simple_Function+0x010a
  BLUESTONE!ServiceModel_SimpleTest::SimpleClient+0x069a
  BLUESTONE!ServiceModelTestGroup_Simple_Test02_Run+0x0041
  BLUESTONE!Fnshell2::FnshellConfiguration::RunTest+0x002e
  BLUESTONE!Fnshell2::TESTCASE::Run+0x00d6
  BLUESTONE!fnsMsgProc+0x02d6
  BLUESTONE!fnsRunTestsWorkerThread+0x085f
  KERNEL32!BaseThreadInitThunk+0x000d
  ntdll!RtlUserThreadStart+0x001d

Closed stack:

0:001>


API Reference for Application Verifier
See Also

The API Reference contains information about COM interfaces and enumerations that you can use to configure Application Verifier programmatically.

In This Section

Enumerations for Application Verifier

Interfaces for Application Verifier

See Also

Concepts

Testing Applications


Enumerations for Application Verifier
See Also

Each enumeration listed below defines a set of related constants required by the COM interfaces to control the configuration of Application Verifier.

In This Section

VerifierErrorFlag enumeration

VerifierErrorReporting enumeration

VerifierPropertyType enumeration

VerifierStopFlag enumeration

VerifierStopSeverity enumeration

See Also

Other Resources

API Reference for Application Verifier


VerifierErrorFlag enumeration
See Also

Defines values that determine how errors are logged, such as whether stack traces are to be included.

Copy Code
typedef enum
    VerifierErrorFlag

{
    VerifierErrorFlagLogToFile,
    VerifierErrorFlagLogStackTrace
}

Elements

VerifierErrorFlagLogToFile

Application Verifier creates a log entry when it encounters the verifier stop.

VerifierErrorFlagLogStackTrace

Application Verifier includes a stack trace in the log entry.

Requirements

Header: Enum.h

Library: Appverifier.dll

See Also

Other Resources

Enumerations for Application Verifier


VerifierErrorReporting enumeration
See Also

Controls how Application Verifier interacts with a debugger.

Copy Code
typedef enum
    VerifierErrorReporting

{
    VerifierErrorReportingNoBreak,
    VerifierErrorReportingException,
    VerifierErrorReportingBreakpoint
}

Elements

VerifierErrorReportingNoBreak

When a stop is encountered, Application Verifier will not break into the debugger.

VerifierErrorReportingException

When a stop is encountered, Application Verifier will generate an exception.

VerifierErrorReportingBreakpoint

When a stop is encountered, Application Verifier will break into the debugger.

Requirements

Header: Enum.h

Library: Appverifier.dll

See Also

Reference

IAppVerifierStop::get_ErrorReporting method
IAppVerifierImageStop::get_ErrorReporting method
IAppVerifierImageStop::put_ErrorReporting method

Other Resources

Enumerations for Application Verifier


VerifierPropertyType enumeration
See Also

Defines the data type of an Application Verifier property.

Copy Code
typedef enum
    VerifierPropertyType

{
    VerifierPropertyTypeNone,
    VerifierPropertyTypeDWORD,
    VerifierPropertyTypeQWORD,
    VerifierPropertyTypeString,
    VerifierPropertyTypeStringArray,
    VerifierPropertyTypeByteArray,
    VerifierPropertyTypeBoolean
}

Elements

VerifierPropertyTypeNone

The property will be a variant of type VT_EMPTY.

VerifierPropertyTypeDWORD

The property will be a variant of type VT_UI4.

VerifierPropertyTypeQWORD

The property will be a variant of type VT_UI8.

VerifierPropertyTypeString

The property will be a variant of type VT_BSTR.

VerifierPropertyTypeStringArray

The property will be a variant of either type VT_ARRAY | VT_BSTR.

VerifierPropertyTypeByteArray

The property will be a variant of either type VT_ARRAY | VT_UI1.

VerifierPropertyTypeBoolean

The property will be a variant of type VT_BOOL.

Requirements

Header: Enum.h

Library: Appverifier.dll

See Also

Reference

IAppVerifierProperty::get_Type method
IAppVerifierImageProperty::get_Type method
IAppVerifierImageProperty::put_Value method

Other Resources

Enumerations for Application Verifier


VerifierStopFlag enumeration
See Also

Determines how a verifier stop interacts with a debugger.

Copy Code
typedef enum
    VerifierStopFlag

{
    VerifierStopFlagStopOnce,
    VerifierStopFlagNotContinuable
}

Elements

VerifierStopFlagStopOnce

During the lifetime of the process, Application Verifier will issue this stop one time only. If the conditions that produce the stop are subsequently detected by Application Verifier, they will be ignored.

VerifierStopFlagNotContinuable

Program execution cannot continue after Application Verifier issues this stop. Application Verifier will terminate the process after any configured exceptions or break points are thrown.

Requirements

Header: Enum.h

Library: Appverifier.dll

See Also

Other Resources

Enumerations for Application Verifier


VerifierStopSeverity enumeration
See Also

Indicates the level of severity of a verifier stop.

Copy Code
typedef enum
    VerifierStopSeverity

{
    VerifierStopSeverityIgnore,
    VerifierStopSeverityInformation,
    VerifierStopSeverityWarning,
    VerifierStopSeverityError
}

Elements

VerifierStopSeverityIgnore

Ignore the stop.

VerifierStopSeverityInformation

The stop is for informational purposes only.

VerifierStopSeverityWarning

The stop is a warning. It may or may not indicate an issue that you must resolve. You should investigate further.

VerifierStopSeverityError

The stop represents a serious issue that you must resolve.

Requirements

Header: Enum.h

Library: Appverifier.dll

See Also

Reference

IAppVerifierStop::get_Severity method
IAppVerifierImageStop::get_Severity method
IAppVerifierImageStop::put_Severity method

Other Resources

Enumerations for Application Verifier


Interfaces for Application Verifier
See Also

In This Section

IAppVerifierCheck interface

IAppVerifierChecks interface

IAppVerifierImage interface

IAppVerifierImageCheck interface

IAppVerifierImageChecks interface

IAppVerifierImageLog interface

IAppVerifierImageLogs interface

IAppVerifierImageProperties interface

IAppVerifierImageProperty interface

IAppVerifierImages interface

IAppVerifierImageStop interface

IAppVerifierImageStops interface

IAppVerifierManager interface

IAppVerifierProperties interface

IAppVerifierProperty interface

IAppVerifierStop interface

IAppVerifierStops interface

See Also

Other Resources

API Reference for Application Verifier


IAppVerifierCheck interface
See Also

Represents a verifier check and provides metadata information about a check that is available in Application Verifier.

Methods

IAppVerifierCheck::get_Description method

Retrieves a textual description of the check.

IAppVerifierCheck::get_GroupName method

Retrieves the name of the group that contains the check.

IAppVerifierCheck::get_GuidString method

Retrieves a string that represents the globally unique identifier (GUID) for the check.

IAppVerifierCheck::get_LongName method

Retrieves the long name of the check.

IAppVerifierCheck::get_MajorVersion method

Retrieves the major version of the check.

IAppVerifierCheck::get_MinorVersion method

Retrieves the minor version of the check.

IAppVerifierCheck::get_Name method

Retrieves the friendly name of the check.

IAppVerifierCheck::get_Properties method

Retrieves a collection of default properties of the check.

IAppVerifierCheck::get_Propigate method

Retrieves a flag that indicates if the check is propagated to child processes.

IAppVerifierCheck::get_Stops method

Retrieves a collection of Application Verifier stops that are associated with the check.

Remarks

To find the specific setting for a check on an image that Application Verifier enabled, use the IAppVerifierImageCheck interface.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierChecks interface

Other Resources

Interfaces for Application Verifier


IAppVerifierCheck::get_Description method
See Also

Retrieves a textual description of the Application Verifier check.

Copy Code
HRESULT
    get_Description
   (
    BSTR*
    pbstr

);

Parameters

pbstr

[out] Points to the description of the check. If the check does not provide a description, this parameter will point to an empty string.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierCheck interface


IAppVerifierCheck::get_GroupName method
See Also

Retrieves the name of the group that contains the check.

Copy Code
HRESULT
    get_GroupName
  (
    BSTR*
    pbstr

);

Subhead

pbstr

[Out] Points to the name of the group that contains the check.

Return Value

The following list includes the most likely return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

For simplicity, checks are divided into groups. These groups are often displayed as the first level in a hierarchy in a user interface. For example, the Handle checks are part of the Basics group.

See Also

Reference

IAppVerifierCheck interface


IAppVerifierCheck::get_GuidString method
See Also

Retrieves a string that represents the globally unique identifier (GUID) for the check.

Copy Code
HRESULT
    get_GuidString
  (
    BSTR*
    pbstr

);

Parameters

pbstr

[out] Points to the GUID for the check.

Return Value

The following list includes the most likely return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The returned GUID is guaranteed to be a unique identifier. However, the name of the check (or event the combination of the name and group) is not guaranteed to be unique.

See Also

Reference

IAppVerifierCheck interface


IAppVerifierCheck::get_LongName method
See Also

Retrieves the long name of the Application Verifier check.

Copy Code
HRESULT
    get_LongName
  (
    BSTR*
    pbstr

);

Parameters

pbstr

[out] Points to the long name for the check.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierCheck interface


IAppVerifierCheck::get_MajorVersion method
See Also

Retrieves the major version of the check.

Copy Code
HRESULT
    get_MajorVersion
  (
    LONG*
    plMajorVersion

);

Parameters

plMajorVersion

[out] Points to the major version number of the check.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierCheck interface
IAppVerifierCheck::get_MinorVersion method


IAppVerifierCheck::get_MinorVersion method
See Also

Retrieves the minor version of the check.

Copy Code
HRESULT
    get_MinorVersion
  (
    LONG*
    plMinorVersion

);

Parameters

plMinorVersion

[out] Points to the minor version number of the check.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierCheck interface
IAppVerifierCheck::get_MinorVersion method


IAppVerifierCheck::get_Name method
See Also

Retrieves the friendly name of the check.

Copy Code
HRESULT
    get_Name
   (
    BSTR*
    pbstr

);

Parameters

pbstr

[out] Points to the name of the check.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierCheck interface


IAppVerifierCheck::get_Properties method
See Also

Retrieves a collection of default properties of the check.

Copy Code
HRESULT
    get_Properties
   (
    IAppVerifierProperites**
    ppProperties

);

Parameters

ppProperties

[out] Points to the interface that represents the properties for the check.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierCheck interface
IAppVerifierProperties interface


IAppVerifierCheck::get_Propigate method
See Also

Retrieves a flag that indicates if the check is propagated to child processes.

Copy Code
HRESULT
    get_Propigate
   (
    VARIANT_BOOL*
    pbResult

);

Parameters

pbResult

[out] Points to a byte that contains the result of whether the check is propagated to child processes. The result is TRUE if the check is propagated; otherwise it is FALSE.

Return Value

The following list includes the most likely return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierCheck interface


IAppVerifierCheck::get_Stops method
See Also

Retrieves a collection of Application Verifier stops that are associated with the check.

Copy Code
HRESULT
    get_Stops
   (
    IAppVerifierStops**
    ppStops

);

Parameters

ppStops

[out] Points to a collection of Application Verifier stops.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierCheck interface
IAppVerifierStops interface


IAppVerifierChecks interface
See Also

Represents a collection of verifier checks and provides metadata information about the checks that are available.

Methods

IAppVerifierChecks::get__NewEnum method

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of checks. Use the interface to retrieve objects from the collection.

IAppVerifierChecks::get_Count method

Retrieves the number of checks in the collection.

IAppVerifierChecks::get_Item method

Retrieves the specified AppVerifierCheck object from the collection.

Remarks

To find the settings for checks on an image with Application Verifier enabled, use the IAppVerifierImageChecks interface.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierCheck interface

Other Resources

Interfaces for Application Verifier


IAppVerifierChecks::get__NewEnum method
See Also

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of checks. Use the interface to retrieve objects from the collection.

Copy Code
HRESULT
    get__NewEnum
   (
    LPUNKNOWN*
    ppunk

);

Parameters

ppunk

[out] Points to the enumerator interface.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

E_OUTOFMEMORY

Ran out of memory during procedure.

Remarks

The enumerator interface supports both IEnumVARIANT and IEnumUnknown . You can find information about these interfaces in the Platform SDK.

See Also

Reference

IAppVerifierChecks interface


IAppVerifierChecks::get_Count method
See Also

Retrieves the number of checks in the collection.

Copy Code
HRESULT
    get_Count
   (
    long*
    plCount

);

Parameters

plCount

[out] Points to the number of checks in the collection.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierChecks interface


IAppVerifierChecks::get_Item method
See Also

Retrieves the specified AppVerifierCheck object from the collection.

Copy Code
HRESULT
    get_Item
   (
    BSTR
    bstrGUID
  ,
    IAppVerifierCheck**
    ppCheck

);

Parameters

bstrGUID

[in] GUID that identifies the check object to be returned.

ppCheck

[out] Points to the check object.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

Procedure failed.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierChecks interface
IAppVerifierCheck interface


IAppVerifierImage interface
See Also

Represents an executable image (or application) that has enabled Application Verifier.

Methods

IAppVerifierImage::get_Checks method

Retrieves a collection of checks for the image.

IAppVerifierImage::get_Name method

Retrieves the name of the image.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierImages interface

Other Resources

Interfaces for Application Verifier


IAppVerifierImage::get_Checks method
See Also

Retrieves a collection of checks for the image.

Copy Code
HRESULT
    get_Checks
   (
    IAppVerifierImageChecks**
    ppChecks

);

Parameters

ppChecks

[out] Points to a collection of checks for the image.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImage interface
IAppVerifierImageChecks interface


IAppVerifierImage::get_Name method
See Also

Retrieves the name of the image.

Copy Code
HRESULT
    get_Name
   (
    BSTR*
    pbstr

);

Parameters

pbstr

[out] Points to the name of the image.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImage interface


IAppVerifierImageCheck interface
See Also

Represents an instance of a specific check for an image (application) that has enabled Application Verifier.

Methods

IAppVerifierImageCheck::get_Description method

Retrieves a textual description of the image check.

IAppVerifierImageCheck::get_Enabled method

Retrieves a value that indicates if the check is enabled.

IAppVerifierImageCheck::get_GroupName method

Retrieves the name of the group that contains the check.

IAppVerifierImageCheck::get_GuidString method

Retrieves a string that represents the globally unique identifier (GUID) for the check.

IAppVerifierImageCheck::get_LongName method

Retrieves the long name of the image check.

IAppVerifierImageCheck::get_MajorVersion method

Retrieves the major version of the check.

IAppVerifierImageCheck::get_MinorVersion method

Retrieves the minor version of the check.

IAppVerifierImageCheck::get_Name method

Retrieves the friendly name of the check.

IAppVerifierImageCheck::get_Properties method

Retrieves a collection of default properties of the check.

IAppVerifierImageCheck::get_Propigate method

Retrieves a flag that indicates if the check is propagated to child processes.

IAppVerifierImageCheck::get_Stops method

Retrieves a collection of Application Verifier stops that are associated with the check.

IAppVerifierImageCheck::put_Enabled method

Enables or disables the check for the associated image.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierImageChecks interface

Other Resources

Interfaces for Application Verifier


IAppVerifierImageCheck::get_Description method
See Also

Retrieves a textual description of the image check.

Copy Code
HRESULT
    get_Description
   (
    BSTR*
    pbstr

);

Parameters

pbstr

[out] Pointer to the description of the check.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageCheck interface


IAppVerifierImageCheck::get_Enabled method
See Also

Retrieves a value that indicates if the check is enabled.

Copy Code
HRESULT
    get_Enabled
  (
    VARIANT_BOOL*
    pbResult

);

Subhead

pbResult

[Out] Boolean value that is TRUE when the check is enabled; otherwise, the value is FALSE. The value is TRUE by default.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

E_UNEXPECTED

Unexpected error occurred.

See Also

Reference

IAppVerifierImageCheck interface


IAppVerifierImageCheck::get_GroupName method
See Also

Retrieves the name of the group that contains the check.

Copy Code
HRESULT
    get_GroupName
  (
    BSTR*
    pbstr

);

Subhead

pbstr

[Out] Points to the name of the group that contains the check.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

For simplicity, checks are divided into groups. These groups are often displayed as the first level in a hierarchy in a user interface. For example, the Handle checks are part of the Basics group.

See Also

Reference

IAppVerifierImageCheck interface


IAppVerifierImageCheck::get_GuidString method
See Also

Retrieves a string that represents the globally unique identifier (GUID) for the check.

Copy Code
HRESULT
    get_GuidString
  (
    BSTR*
    pbstr

);

Parameters

pbstr

[out] Points to the GUID for the check.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The returned GUID is guaranteed to be a unique identifier. However, the name of the check (or event the combination of the name and group) is not guaranteed to be unique.

See Also

Reference

IAppVerifierImageCheck interface


IAppVerifierImageCheck::get_LongName method
See Also

Retrieves the long name of the image check.

Copy Code
HRESULT
    get_LongName
  (
    BSTR*
    pbstr

);

Parameters

pbstr

[out] Points to the long name for the check.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageCheck interface


IAppVerifierImageCheck::get_MajorVersion method
See Also

Retrieves the major version of the check.

Copy Code
HRESULT
    get_MajorVersion
  (
    LONG*
    plMajorVersion

);

Parameters

plMajorVersion

[out] Points to the major version number of the check.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageCheck interface
IAppVerifierImageCheck::get_MinorVersion method


IAppVerifierImageCheck::get_MinorVersion method
See Also

Retrieves the minor version of the check.

Copy Code
HRESULT
    get_MinorVersion
  (
    LONG*
    plMinorVersion

);

Parameters

plMinorVersion

[out] Points to the minor version number of the check.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageCheck interface
IAppVerifierImageCheck::get_MajorVersion method


IAppVerifierImageCheck::get_Name method
See Also

Retrieves the friendly name of the check.

Copy Code
HRESULT
    get_Name
   (
    BSTR*
    pbstr

);

Parameters

pbstr

[out] Points to the name of the check.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageCheck interface


IAppVerifierImageCheck::get_Properties method
See Also

Retrieves a collection of default properties of the check.

Copy Code
HRESULT
    get_Properties
   (
    IAppVerifierImageProperites**
    ppProperties

);

Parameters

ppProperties

[out] Points to the interface that represents the properties for the check.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

Procedure failed.

E_POINTER

Pointer is invalid.

E_OUTOFMEMORY

Ran out of memory during procedure.

Remarks

If the image check is not enabled, IAppVerifierImageCheck::get_Properties and IAppVerifierImageCheck::get_Stops will fail and return E_FAIL. Therefore, you should determine that the check is enabled before using these methods. This is especially true when you are using a language that supports the FOR EACH construct to enumerate the checks collection.

See Also

Reference

IAppVerifierImageCheck interface
IAppVerifierImageProperties interface


IAppVerifierImageCheck::get_Propigate method
See Also

Retrieves a flag that indicates if the check is propagated to child processes.

Copy Code
HRESULT
    get_Propigate
   (
    VARIANT_BOOL*
    pbResult

);

Parameters

pbResult

[out] Points to a byte that contains the result of whether the check is propagated to child processes. The result is TRUE if the check is propagated; otherwise it is FALSE.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageCheck interface


IAppVerifierImageCheck::get_Stops method
See Also

Retrieves a collection of Application Verifier stops that are associated with the check.

Copy Code
HRESULT
    get_Stops
   (
    IAppVerifierImageStops**
    ppStops

);

Parameters

ppStops

[out] Points to a collection of Application Verifier stops.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

Procedure failed.

E_POINTER

Pointer is invalid.

E_OUTOFMEMORY

Ran out of memory during procedure.

Remarks

If the image check is not enabled, IAppVerifierImageCheck::get_Properties and IAppVerifierImageCheck::get_Stops will fail and return E_FAIL. Therefore, you should determine that the check is enabled before using these methods. This is especially true when you are using a language that supports the FOR EACH construct to enumerate the checks collection.

See Also

Reference

IAppVerifierImageCheck interface
IAppVerifierImageStops interface


IAppVerifierImageCheck::put_Enabled method
See Also

Enables or disables the check for the associated image.

Copy Code
HRESULT
    put_Enabled
   (
    VARIANT_BOOL*
    Value

);

Parameters

Value

[in] Set to TRUE to enable the check. Set to FALSE to disable the check.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_ACCESSDENIED

The current user has inadequate permission to set the state of the check. Changing the value of the enabled state requires Administrator privileges.

E_UNEXPECTED

Unexpected error occurred.

See Also

Reference

IAppVerifierImageCheck interface


IAppVerifierImageChecks interface
See Also

Represents a collection of verifier checks for an image (application).

Methods

IAppVerifierImageChecks::get__NewEnum method

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of checks. Use the interface to retrieve objects from the collection.

IAppVerifierImageChecks::get_Count method

Retrieves the number of checks in the collection.

IAppVerifierImageChecks::get_Item method

Retrieves the specified IAppVerifierImageCheck object from the collection.

Remarks

If you disable all of the checks in the IAppVerifierImageChecks collection, then the image will no longer be under verification, which means it will be automatically removed from the images collection. If that happens, you must re-add the image to the images collection in IAppVerifierManager . So be careful when removing checks from the collection that you do not delete the last one inadvertently.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierImageCheck interface

Other Resources

Interfaces for Application Verifier


IAppVerifierImageChecks::get__NewEnum method
See Also

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of checks. Use the interface to retrieve objects from the collection.

Copy Code
HRESULT
    get_NewEnum
   (
    LPUNKNOWN*
    ppunk

);

Parameters

ppunk

[out] Points to the enumerator interface.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

E_OUTOFMEMORY

Ran out of memory during procedure.

Remarks

The enumerator interface supports both IEnumVARIANT and IEnumUnknown . You can find information about these interfaces in the Platform SDK.

See Also

Reference

IAppVerifierImageChecks interface


IAppVerifierImageChecks::get_Count method
See Also

Retrieves the number of checks in the collection.

Copy Code
HRESULT
    get_Count
   (
    long*
    plCount

);

Parameters

plCount

[out] Points to the number of checks in the collection.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageChecks interface


IAppVerifierImageChecks::get_Item method
See Also

Retrieves the specified IAppVerifierImageCheck object from the collection.

Copy Code
HRESULT
    get_Item
   (
    BSTR
    bstrGUID
  ,
    IAppVerifierImageCheck**
    ppCheck

);

Parameters

bstrGUID

[in] GUID that identifies the check object to be returned.

ppCheck

[out] Points to the check object.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

Procedure failed.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageChecks interface
IAppVerifierImageCheck interface


IAppVerifierImageLog interface
See Also

Represents the ability to manipulate a log for a run of the image.

Methods

IAppVerifierImageLog::get_Name method

Retrieves the name of the log.

IAppVerifierImageLog::SaveAsXML method

Converts a native Application Verifier log from a binary format to an XML-based format and saves it to the specified path.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierImageLogs interface

Other Resources

Interfaces for Application Verifier


IAppVerifierImageLog::get_Name method
See Also

Retrieves the name of the log.

Copy Code
HRESULT
    get_Name
   (
    BSTR*
    pbstr

);

Parameters

pbstr

[out] Points to the name of the log.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageLog interface


IAppVerifierImageLog::SaveAsXML method
See Also

Converts a native Application Verifier log from a binary format to an XML-based format and saves it to the specified path.

Copy Code
HRESULT
    SaveAsXML
   (
    BSTR
    bstrLogPath

    BSTR
    bstrSymPath

);

Parameters

bstrLogPath

[in] Full path to the log file.

bstrSymPath

[in] Full path to the symbol files of the image (application). The symbol files will be used to resolve the function names in the stack trace that could be included as part of the log.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

The method failed.

E_UNEXPECTED

An unexpected error occurred.

E_INVALIDARG

You passed an invalid argument.

See Also

Reference

IAppVerifierImageLog interface


IAppVerifierImageLogs interface
See Also

Represents a collection of log files that were created during previous runs of Application Verifier for a given image (application).

Methods

IAppVerifierImageLogs::get__NewEnum method

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of checks. Use the interface to retrieve objects from the collection.

IAppVerifierImageLogs::get_Count method

Retrieves the number of logs in the collection.

IAppVerifierImageLogs::get_Item method

Retrieves the specified IAppVerifierImageLog object from the collection.

IAppVerifierImageLogs::Remove method

Deletes a log from the collection.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierImageLog interface

Other Resources

Interfaces for Application Verifier


IAppVerifierImageLogs::get__NewEnum method
See Also

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of checks. Use the interface to retrieve objects from the collection.

Copy Code
HResult
    get_NewEnum
   (
    LPUNKNOWN*
    ppunk

);

Parameters

ppunk

[out] Points to the enumerator interface.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

E_OUTOFMEMORY

Ran out of memory during procedure.

Remarks

The enumerator interface supports both IEnumVARIANT and IEnumUnknown . You can find information about these interfaces in the Platform SDK.

See Also

Reference

IAppVerifierImageLogs interface


IAppVerifierImageLogs::get_Count method
See Also

Retrieves the number of logs in the collection.

Copy Code
HResult
    get_Count
   (
    long*
    plCount

);

Parameters

plCount

[out] Points to the number of logs in the collection.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageLogs interface


IAppVerifierImageLogs::get_Item method
See Also

Retrieves the specified IAppVerifierImageLog object from the collection.

Copy Code
HResult
    get_Item
   (
    long
    lLogIndex
  ,
    IAppVerifierImageLog**
    ppLog

);

Parameters

lLogIndex

[in] Zero-based index of the log to retrieve from the collection.

ppLog

[out] Points to the log object.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_INVALIDARG

You passed an invalid argument.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageLogs interface
IAppVerifierImageLog interface


IAppVerifierImageLogs::Remove method
See Also

Deletes a log from the collection.

Copy Code
HResult
    Remove
   (
    long
    lLogIndex

);

Parameters

lLogIndex

[in] Zero-based index of the log to delete from the collection.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

Procedure failed.

E_INVALIDARG

You passed an invalid argument.

See Also

Reference

IAppVerifierImageLogs interface


IAppVerifierImageProperties interface
See Also

Represents a collection of properties that are related to an image check.

Methods

IAppVerifierImageChecks::get__NewEnum method

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of properties. Use the interface to retrieve objects from the collection.

IAppVerifierImageChecks::get_Count method

Retrieves the number of properties in the collection.

IAppVerifierImageChecks::get_Item method

Retrieves the specified IAppVerifierImageProperty object from the collection.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierImageProperty interface

Other Resources

Interfaces for Application Verifier


IAppVerifierImageProperties::get__NewEnum method
See Also

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of properties. Use the interface to retrieve objects from the collection.

Copy Code
HRESULT
    get_NewEnum
   (
    LPUNKNOWN*
    ppunk

);

Parameters

ppunk

[out] Points to the enumerator interface.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

E_OUTOFMEMORY

Ran out of memory during procedure.

Remarks

The enumerator interface supports both IEnumVARIANT and IEnumUnknown . You can find information about these interfaces in the Platform SDK.

See Also

Reference

IAppVerifierImageProperties interface


IAppVerifierImageProperties::get_Count method
See Also

Retrieves the number of properties in the collection.

Copy Code
HRESULT
    get_Count
   (
    long*
    plCount

);

Parameters

plCount

[out] Points to the number of properties in the collection.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageProperties interface


IAppVerifierImageProperties::get_Item method
See Also

Retrieves the specified IAppVerifierImageProperty object from the collection.

Copy Code
HRESULT
    get_Item
   (
    BSTR
    bstrPropertyId
  ,
    IAppVerifierImageProperty**
    ppProperty

);

Parameters

bstrPropertyId

[in] Identifier for the property to retrieve.

ppProperty

[out] Points to the property object.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

The method failed.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageProperties interface


IAppVerifierImageProperty interface
See Also

Represents a property associated with an image check.

Methods

IAppVerifierImageProperty::get_Name method

Retrieves the name of the property.

IAppVerifierImageProperty::get_Type method

Retrieves the data type of the property.

IAppVerifierImageProperty::get_Value method

Retrieves the value of the property.

IAppVerifierImageProperty::put_Value method

Sets the value of the property.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierImageProperties interface

Other Resources

Interfaces for Application Verifier


IAppVerifierImageProperty::get_Name method
See Also

Retrieves the name of the property.

Copy Code
HRESULT
    get_Name
   (
    BSTR*
    pbstr

);

Parameters

pbstr

[out] Points to the name of the property.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_INVALIDARG

You passed an invalid argument.

See Also

Reference

IAppVerifierImageProperty interface
IAppVerifierImageProperty::get_Type method


IAppVerifierImageProperty::get_Type method
See Also

Retrieves the data type of the property.

Copy Code
HRESULT
    get_Type
   (
    VerifierPropertyType*
    pVerifierPropertyType

);

Parameters

pVerifierPropertyType

[out] Points to the type associated with the property value. This parameter cannot be NULL.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageProperty interface
VerifierPropertyType enumeration
IAppVerifierImageProperty::get_Name method
IAppVerifierImageProperty::get_Value method


IAppVerifierImageProperty::get_Value method
See Also

Retrieves the value of the property.

Copy Code
HRESULT
    get_Value
   (
    VARIANT*
    pvValue

);

Parameters

pvValue

[out] Points to the value the property. The variant type depends on the type that is set for the property.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

The method failed.

E_POINTER

Pointer is invalid.

E_OUTOFMEMORY

Process ran out of memory.

E_UNEXPECTED

An unexpected error occurred.

E_NOTIMPL

Support for binary properties is not implemented.

See Also

Reference

IAppVerifierImageProperty interface
IAppVerifierImageProperty::get_Type method
IAppVerifierImageProperty::put_Value method


IAppVerifierImageProperty::put_Value method
See Also

Sets the value of the property.

Copy Code
HRESULT
    put_Value
   (
    VARIANT
    vValue

);

Parameters

vValue

[in] Value to set for the property. The value will be converted to the appropriate VARIANT type from the VerifierPropertyType enumeration.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

The method failed.

E_ACCESSDENIED

The current user has inadequate permission to set the property. Changing the value of the property requires Administrator privileges.

E_INVALIDARG

You passed an invalid argument.

E_OUTOFMEMORY

Process ran out of memory.

E_NOTIMPL

Support for binary properties is not implemented.

HRESULT_FROM_WIN32(ERROR_CANTWRITE)

The property is read-only.

See Also

Reference

IAppVerifierImageProperty interface
IAppVerifierImageProperty::get_Value method
IAppVerifierImageProperty::get_Type method


IAppVerifierImages interface
See Also

Represents the collection of images (applications) for which Application Verifier is enabled.

Methods

IAppVerifierImages::Add method

Enables Application Verifier for the image.

IAppVerifierImages::get__NewEnum method

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of images. Use the interface to retrieve objects from the collection.

IAppVerifierImages::get_Count method

Retrieves the number of images in the collection.

IAppVerifierImages::get_Item method

Retrieves the specified IAppVerifierImage object from the collection.

IAppVerifierImages::Remove method

Disables Application Verifier for the image.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierImage interface

Other Resources

Interfaces for Application Verifier


IAppVerifierImages::Add method
See Also

Enables Application Verifier for the image.

Copy Code
HRESULT
    Add
   (
    BSTR
    bstrImageName
  ,
    IAppVerifierImage**
    ppImage

);

Parameters

bstrImageName

[in] Name of the image.

ppImage

[out] Points to the image object.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_INVALIDARG

You passed an invalid argument.

E_POINTER

Pointer is invalid.

E_OUTOFMEMORY

Process ran out of memory.

See Also

Reference

IAppVerifierImages interface
IAppVerifierImage interface
IAppVerifierImages::Remove method


IAppVerifierImages::get__NewEnum method
See Also

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of images. Use the interface to retrieve objects from the collection.

Copy Code
HRESULT
    get_NewEnum
   (
    LPUNKNOWN*
    ppunk

);

Parameters

ppunk

[out] Points to the enumerator interface.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

E_OUTOFMEMORY

Ran out of memory during procedure.

Remarks

The enumerator interface supports both IEnumVARIANT and IEnumUnknown . You can find information about these interfaces in the Platform SDK.

See Also

Reference

IAppVerifierImages interface


IAppVerifierImages::get_Count method
See Also

Retrieves the number of images in the collection.

Copy Code
HRESULT
    get_Count
   (
    long*
    plCount

);

Parameters

plCount

[out] Points to the number of images in the collection.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImages interface


IAppVerifierImages::get_Item method
See Also

Retrieves the specified IAppVerifierImage object from the collection.

Copy Code
HRESULT
    get_Item
   (
    BSTR
    bstrImageName
  ,
    IAppVerifierImage**
    ppImage

);

Parameters

bstrImageName

[in] Name of the image to retrieve from the collection.

ppImage

[out] Points to the image object.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

The method failed.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImages interface


IAppVerifierImages::Remove method
See Also

Disables Application Verifier for the image.

Copy Code
HRESULT
    Remove
   (
    BSTR
    bstrImageName

);

Parameters

bstrImageName

[in] Name of the image.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

The method failed.

E_INVALIDARG

You passed an invalid argument.

See Also

Reference

IAppVerifierImages interface
IAppVerifierImages::Add method


IAppVerifierImageStop interface
See Also

Represents a stop that is associated with an image check.

Methods

IAppVerifierImageStop::get_Active method

Retrieves a flag that indicates if the Application Verifier stop is active.

IAppVerifierImageStop::get_ErrorFlags method

Retrieves a set of flags that configure the behavior of Application Verifier when an error is detected.

IAppVerifierImageStop::get_ErrorReporting method

Retrieves the settings that determine the method of reporting when Application Verifier encounters an error.

IAppVerifierImageStop::get_Severity method

Retrieves the severity of the stop.

IAppVerifierImageStop::get_StopCode method

Retrieves the stop code that is associated with the stop.

IAppVerifierImageStop::get_StopFlags method

Retrieves a set of flags that configure the behavior of Application Verifier when the stop is encountered.

IAppVerifierImageStop::put_Active method

Sets or resets a flag that indicates if the Application Verifier stop is active.

IAppVerifierImageStop::put_ErrorFlags method

Sets the flags that configure the behavior of Application Verifier when an error is detected.

IAppVerifierImageStop::put_ErrorReporting method

Sets the settings that determine the method of reporting when Application Verifier encounters an error.

IAppVerifierImageStop::put_Severity method

Sets the severity of the stop.

IAppVerifierImageStop::put_StopFlags method

Sets the flags that configure the behavior of Application Verifier when the stop is encountered.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierImageStops interface

Other Resources

Interfaces for Application Verifier


IAppVerifierImageStop::get_Active method
See Also

Retrieves a flag that indicates if the Application Verifier stop is active.

Copy Code
HRESULT
    get_Active
   (
    VARIANT_BOOL*
    pbResult

);

Parameters

pbResult

[out] Points to the flag that indicates if the stop is active. If the flag is TRUE, the stop is active. If the flag is FALSE, the stop is inactive.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageStop interface
IAppVerifierImageStop::put_Active method


IAppVerifierImageStop::get_ErrorFlags method
See Also

Retrieves a set of flags that configure the behavior of Application Verifier when an error is detected.

Copy Code
HRESULT
    get_ErrorFlags
   (
    LONG*
    plFlags

);

Parameters

plFlags

[out] Points to an integer that contains the flags.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageStop interface
IAppVerifierImageStop::put_ErrorFlags method


IAppVerifierImageStop::get_ErrorReporting method
See Also

Retrieves the settings that determine the method of reporting when Application Verifier encounters an error.

Copy Code
HRESULT
    get_ErrorReporting
   (
    VerifierErrorReporting*
    pVerifierErrorReporting

);

Parameters

pVerifierErrorReporting

[out] Points to an enumeration value that represents the method of reporting errors.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

The method failed.

See Also

Reference

IAppVerifierImageStop interface
IAppVerifierImageStop::put_ErrorReporting method


IAppVerifierImageStop::get_Severity method
See Also

Retrieves the severity of the stop.

Copy Code
HRESULT
    get_Severity
   (
    VerifierStopSeverity*
    pVerifierStopSeverity

);

Parameters

pVerifierStopSeverity

[out] Points to an enumeration value that represents the severity of the stop.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

E_NOTIMPL

Security level not implemented.

See Also

Reference

IAppVerifierImageStop interface
IAppVerifierImageStop::put_Severity method


IAppVerifierImageStop::get_StopCode method
See Also

Retrieves the stop code that is associated with the stop.

Copy Code
HRESULT
    get_StopCode
   (
    LONG*
    plStopCode

);

Parameters

plStopCode

[out] Points to the stop code for the verifier stop.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The stop code uniquely identifies the stop for a check. Stop codes should be unique across all checks, but their uniqueness is not guaranteed.

See Also

Reference

IAppVerifierImageStop interface


IAppVerifierImageStop::get_StopFlags method
See Also

Retrieves a set of flags that configure the behavior of Application Verifier when the stop is encountered.

Copy Code
HRESULT
    get_StopFlags
   (
    LONG*
    plFlags

);

Parameters

plFlags

[out] Points to the stop flags for the verifier stop.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageStop interface
IAppVerifierImageStop::put_StopFlags method


IAppVerifierImageStop::put_Active method
See Also

Sets or resets a flag that indicates if the Application Verifier stop is active.

Copy Code
HRESULT
    put_Active
   (
    VARIANT_BOOL
    vValue

);

Parameters

vValue

[in] Value to set the flag that indicates if the stop is active. If the flag is set to TRUE, the stop is active. If the flag is set to FALSE, the stop is inactive.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

See Also

Reference

IAppVerifierImageStop interface
IAppVerifierImageStop::get_Active method


IAppVerifierImageStop::put_ErrorFlags method
See Also

Sets the flags that configure the behavior of Application Verifier when an error is detected.

Copy Code
HRESULT
    put_ErrorFlags
   (
    LONG
    lFlags

);

Parameters

lFlags

[in] Bitwise-OR value to which to set the error flags.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

See Also

Reference

IAppVerifierImageStop interface


IAppVerifierImageStop::put_ErrorReporting method
See Also

Sets the settings that determine the method of reporting when Application Verifier encounters an error.

Copy Code
HRESULT
    put_ErrorReporting
   (
    VerifierErrorReporting
    errorReporting

);

Parameters

errorReporting

[in] Enumeration value that represents the method of reporting errors.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

The method failed.

See Also

Reference

IAppVerifierImageStop interface
IAppVerifierImageStop::get_ErrorReporting method


IAppVerifierImageStop::put_Severity method
See Also

Sets the severity of the stop.

Copy Code
HRESULT
    put_Severity
   (
    VerifierStopSeverity
    VerifierStopSeverity

);

Parameters

VerifierStopSeverity

[in] Enumeration value that represents the severity of the stop.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

The method failed.

See Also

Reference

IAppVerifierImageStop interface
IAppVerifierImageStop::get_Severity method


IAppVerifierImageStop::put_StopFlags method
See Also

Sets the flags that configure the behavior of Application Verifier when the stop is encountered.

Copy Code
HRESULT
    put_StopFlags
   (
    LONG
    lFlags

);

Parameters

lFlags

[out] Bitwise-OR value to which to set the stop flags.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

See Also

Reference

IAppVerifierImageStop interface
IAppVerifierImageStop::put_StopFlags method


IAppVerifierImageStops interface
See Also

Represents a collection of Application Verifier stops that are associated with an image check.

Methods

IAppVerifierImageStops::get__NewEnum method

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of stops. Use the interface to retrieve objects from the collection.

IAppVerifierImageStops::get_Count method

Retrieves the number of stops in the collection.

IAppVerifierImageStops::get_Item method

Retrieves the specified IAppVerifierImageStop object from the collection.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierImageStop interface

Other Resources

Interfaces for Application Verifier


IAppVerifierImageStops::get__NewEnum method
See Also

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of stops. Use the interface to retrieve objects from the collection.

Copy Code
HRESULT
    get_NewEnum
   (
    LPUNKNOWN*
    ppunk

);

Parameters

ppunk

[out] Points to the enumerator interface.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

E_OUTOFMEMORY

Ran out of memory during procedure.

Remarks

The enumerator interface supports both IEnumVARIANT and IEnumUnknown . You can find information about these interfaces in the Platform SDK.

See Also

Reference

IAppVerifierImageStops interface


IAppVerifierImageStops::get_Count method
See Also

Retrieves the number of stops in the collection.

Copy Code
HRESULT
    get_Count
   (
    long*
    plCount

);

Parameters

plCount

[out] Points to the number of images in the collection.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageStops interface


IAppVerifierImageStops::get_Item method
See Also

Retrieves the specified IAppVerifierImageStop object from the collection.

Copy Code
HRESULT
    get_Item
   (
    LONG
    lStopCode
  ,
    IAppVerifierImageStop**
    ppStop

);

Parameters

lStopCode

[in] Stop code of the stop to retrieve from the collection.

ppStop

[out] Points to the stop object.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

The method failed.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierImageStops interface


IAppVerifierManager interface
See Also

Represents the ability to configure Application Verifier. This is the top most interface for Application Verifier and all other interfaces are acquired directly or indirectly from this one.

Methods

IAppVerifierManager::get_BuildVersion method

Retrieves the build version portion of Application Verifier version number.

IAppVerifierManager::get_Checks method

Retrieves the check collection.

IAppVerifierManager::get_Images method

Retrieves the collection of images (applications) that have enabled Application Verifier.

IAppVerifierManager::get_MajorVersion method

Retrieves the major version portion of Application Verifier version number.

IAppVerifierManager::get_MinorVersion method

Retrieves the minor version portion of Application Verifier version number.

IAppVerifierManager::get_PrivateVersion method

Retrieves the private version portion of Application Verifier version number.

IAppVerifierManager::get_Logs method

Retrieves the collection of logs for the specified image.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Other Resources

Interfaces for Application Verifier


IAppVerifierManager::get_BuildVersion method
See Also

Retrieves the build version portion of Application Verifier version number.

Copy Code
HRESULT
    get_BuildVersion
  (
    LONG*
    plBuildVersion

);

Parameters

plBuildVersion

[out] Points to the build version number of Application Verifier.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The build version is the third group in a version number of the following format: xxxx.xxxx.xxxx.xxxx. For example, if the version is 1.9.5048.2, the build version is 5048.

See Also

Reference

IAppVerifierManager interface


IAppVerifierManager::get_Checks method
See Also

Retrieves the check collection.

Copy Code
HRESULT
    get_Checks
  (
    IAppVerifierChecks**
    ppChecks

);

Parameters

ppChecks

[out] Points to the checks collection.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The checks collection is a metadata interface that contains information about all checks that are available within Application Verifier. You can retrieve settings for a check that is enabled for an image (application) from the IAppVerifierImageChecks collection, which is accessed from the image object.

See Also

Reference

IAppVerifierManager interface
IAppVerifierImageChecks interface
IAppVerifierImage interface


IAppVerifierManager::get_Images method
See Also

Retrieves the collection of images (applications) that have enabled Application Verifier.

Copy Code
HRESULT
    get_Images
  (
    IAppVerifierImages**
    ppImages

);

Parameters

ppImages

[out] Points to the images collection.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The images collection contains information about all images (applications) that have enabled Application Verifier. To disable verification for an image, remove the image from the collection.

See Also

Reference

IAppVerifierManager interface
IAppVerifierImages interface


IAppVerifierManager::get_MajorVersion method
See Also

Retrieves the major version portion of Application Verifier version number.

Copy Code
HRESULT
    get_MajorVersion
  (
    LONG*
    plMajorVersion

);

Parameters

plMajorVersion

[out] Points to the major version number of Application Verifier.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The major version is the first group in a version number of the following format: xxxx.xxxx.xxxx.xxxx. For example, if the version is 1.9.5048.2, the major version is 1.

See Also

Reference

IAppVerifierManager interface


IAppVerifierManager::get_MinorVersion method
See Also

Retrieves the minor version portion of Application Verifier version number.

Copy Code
HRESULT
    get_minorVersion
  (
    LONG*
    plMinorVersion

);

Parameters

plMinorVersion

[out] Points to the minor version number of Application Verifier.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The minor version is the second group in a version number of the following format: xxxx.xxxx.xxxx.xxxx. For example, if the version is 1.9.5048.2, the minor version is 9.

See Also

Reference

IAppVerifierManager interface


IAppVerifierManager::get_PrivateVersion method
See Also

Retrieves the private version portion of Application Verifier version number.

Copy Code
HRESULT
    get_PrivateVersion
  (
    LONG*
    plPrivateVersion

);

Parameters

plPrivateVersion

[out] Points to the private version number of Application Verifier.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The private version is the fourth group in a version number of the following format: xxxx.xxxx.xxxx.xxxx. For example, if the version is 1.9.5048.2, the private version is 2.

See Also

Reference

IAppVerifierManager interface


IAppVerifierManager::get_Logs method
See Also

Retrieves the collection of logs for the specified image.

Copy Code
HRESULT
    get_Logs
  (
    BSTR
    bstrImage
  ,
    IAppVerifierImageLogs**
    ppLogs

);

Parameters

bstrImage

[out] Name of the image.

ppLogs

[out] Points to a collection of logs for the image.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The logs collection contains the available logs that relate to the specified image. If you pass NULL for the image name, all available logs are retrieved.

See Also

Reference

IAppVerifierManager interface


IAppVerifierProperties interface
See Also

Represents a collection of properties that are available for a check.

Methods

IAppVerifierProperties::get__NewEnum method

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of properties. Use the interface to retrieve objects from the collection.

IAppVerifierImageProperties::get_Count method

Retrieves the number of properties in the collection.

IAppVerifierProperties::get_Item method

Retrieves the specified IAppVerifierProperty object from the collection.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierProperty interface

Other Resources

Interfaces for Application Verifier


IAppVerifierProperties::get__NewEnum method
See Also

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of properties. Use the interface to retrieve objects from the collection.

Copy Code
HRESULT
    get_NewEnum
   (
    LPUNKNOWN*
    ppunk

);

Parameters

ppunk

[out] Points to the enumerator interface.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

E_OUTOFMEMORY

Ran out of memory during procedure.

Remarks

The enumerator interface supports both IEnumVARIANT and IEnumUnknown . You can find information about these interfaces in the Platform SDK.

See Also

Reference

IAppVerifierProperties interface


IAppVerifierProperties::get_Count method
See Also

Retrieves the number of properties in the collection.

Copy Code
HRESULT
    get_Count
   (
    long*
    plCount

);

Parameters

plCount

[out] Points to the number of images in the collection.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierProperties interface


IAppVerifierProperties::get_Item method
See Also

Retrieves the specified IAppVerifierProperty object from the collection.

Copy Code
HRESULT
    get_Item
   (
    BSTR
    bstrPropertyId
  ,
    IAppVerifierProperty**
    ppProperty

);

Parameters

bstrPropertyId

[in] Identifier for the property to retrieve.

ppProperty

[out] Points to the property object.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

The method failed.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierProperties interface


IAppVerifierProperty interface
See Also

Insert introduction here.

Represents a property that is available for a check.

Methods

IAppVerifierProperty::get_Name method

Retrieves the name of the property.

IAppVerifierProperty::get_Type method

Retrieves the data type of the property.

IAppVerifierProperty::get_Value method

Retrieves the default value of the property.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierProperties interface

Other Resources

Interfaces for Application Verifier


IAppVerifierProperty::get_Name method
See Also

Retrieves the name of the property.

Copy Code
HRESULT
    get_Name
   (
    BSTR*
    pbstr

);

Parameters

pbstr

[out] Points to the name of the property.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierProperty interface


IAppVerifierProperty::get_Type method
See Also

Retrieves the data type of the property.

Copy Code
HRESULT
    get_Type
   (
    VerifierPropertyType*
    pVerifierPropertyType

);

Parameters

pVerifierPropertyType

[out] Points to the type associated with the property value. This parameter cannot be NULL.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierProperty interface
VerifierPropertyType enumeration


IAppVerifierProperty::get_Value method
See Also

Retrieves the default value of the property.

Copy Code
HRESULT
    get_Value
   (
    VARIANT*
    pvValue

);

Parameters

pvValue

[out] Points to the default value the property. The variant type depends on the type that is set for the property.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierProperty interface


IAppVerifierStop interface
See Also

Represents a stop that is associated with a check.

Methods

IAppVerifierStop::get_Active method

Retrieves a flag that indicates if the Application Verifier stop is active.

IAppVerifierStop::get_ErrorFlags method

Retrieves a set of flags that configure the behavior of Application Verifier when an error is detected.

IAppVerifierStop::get_ErrorReporting method

Retrieves the settings that determine the method of reporting when Application Verifier encounters an error.

IAppVerifierStop::get_Severity method

Retrieves the severity of the stop.

IAppVerifierStop::get_StopCode method

Retrieves the stop code that is associated with the stop.

IAppVerifierImageStop::get_StopFlags method

Retrieves a set of default flags that configure the behavior of Application Verifier when the stop is encountered.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierStops interface

Other Resources

Interfaces for Application Verifier


IAppVerifierStop::get_Active method
See Also

Retrieves a flag that indicates if the Application Verifier stop is active.

Copy Code
HRESULT
    get_Active
   (
    VARIANT_BOOL*
    pbResult

);

Parameters

pbResult

[out] Points to the flag that indicates if the stop is active. If the flag is TRUE, the stop is active. If the flag is FALSE, the stop is inactive.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The IAppVerifierStop interface is for metadata only and does not indicate the status of the check for any particular image. To check the flag for a particular image, use the IAppVerifierImageStop interface that is associated with the image.

See Also

Reference

IAppVerifierStop interface
IAppVerifierImageStop interface


IAppVerifierStop::get_ErrorFlags method
See Also

Retrieves a set of flags that configure the behavior of Application Verifier when an error is detected.

Copy Code
HRESULT
    get_ErrorFlags
   (
    LONG*
    plFlags

);

Parameters

plFlags

[out] Points to an integer that contains the flags.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The IAppVerifierStop interface is for metadata only and does not indicate the status of the flags for any particular image. To check the flags for a particular image, use the IAppVerifierImageStop interface that is associated with the image.

See Also

Reference

IAppVerifierStop interface
IAppVerifierImageStop interface


IAppVerifierStop::get_ErrorReporting method
See Also

Retrieves the settings that determine the method of reporting when Application Verifier encounters an error.

Copy Code
HRESULT
    get_ErrorReporting
   (
    VerifierErrorReporting*
    pVerifierErrorReporting

);

Parameters

pVerifierErrorReporting

[out] Points to an enumeration value that represents the method of reporting errors.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The IAppVerifierStop interface is for metadata only and does not indicate the status of error reporting for any particular image. To check error reporting for a particular image, use the IAppVerifierImageStop interface that is associated with the image.

See Also

Reference

IAppVerifierStop interface
IAppVerifierImageStop interface


IAppVerifierStop::get_Severity method
See Also

Retrieves the severity of the stop.

Copy Code
HRESULT
    get_Severity
   (
    VerifierStopSeverity*
    pVerifierStopSeverity

);

Parameters

pVerifierStopSeverity

[out] Points to an enumeration value that represents the severity of the stop.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The IAppVerifierStop interface is for metadata only and does not indicate the severity for any particular image. To check the severity for a particular image, use the IAppVerifierImageStop interface that is associated with the image.

See Also

Reference

IAppVerifierStop interface
IAppVerifierImageStop interface


IAppVerifierStop::get_StopCode method
See Also

Retrieves the stop code that is associated with the stop.

Copy Code
HRESULT
    get_StopCode
   (
    LONG*
    plStopCode

);

Parameters

plStopCode

[out] Points to the stop code for the verifier stop.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The stop code uniquely identifies the stop for a check. Stop codes should be unique across all checks, but their uniqueness is not guaranteed.

The IAppVerifierStop interface is for metadata only and does not indicate the stop code for any particular image. To check the stop code for a particular image, use the IAppVerifierImageStop interface that is associated with the image.

See Also

Reference

IAppVerifierStop interface
IAppVerifierImageStop interface


IAppVerifierStop::get_StopFlags method
See Also

Retrieves a set of default flags that configure the behavior of Application Verifier when the stop is encountered.

Copy Code
HRESULT
    get_StopFlags
   (
    LONG*
    plFlags

);

Parameters

plFlags

[out] Points to the default stop flags for the verifier stop.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

Remarks

The IAppVerifierStop interface is for metadata only and does not indicate the status of the flags for any particular image. To check the flags for a particular image, use the IAppVerifierImageStop interface that is associated with the image.

See Also

Reference

IAppVerifierStop interface
IAppVerifierImageStop interface


IAppVerifierStops interface
See Also

Represents a collection of Application Verifier stops that are associated with a check.

Methods

IAppVerifierStops::get__NewEnum method

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of stops. Use the interface to retrieve objects from the collection.

IAppVerifierStops::get_Count method

Retrieves the number of stops in the collection.

IAppVerifierStops::get_Item method

Retrieves the specified IAppVerifierImageStop object from the collection.

Inherits from

IDispatch interface

Requirements

Header: Vrfauto.h

Library: Vrfauto.dll

See Also

Reference

IAppVerifierStop interface

Other Resources

Interfaces for Application Verifier


IAppVerifierStops::get__NewEnum method
See Also

Retrieves the IEnumVARIANT or IEnumUnknown enumerator interface for the collection of stops. Use the interface to retrieve objects from the collection.

Copy Code
HRESULT
    get_NewEnum
   (
    LPUNKNOWN*
    ppunk

);

Parameters

ppunk

[out] Points to the enumerator interface.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

E_OUTOFMEMORY

Ran out of memory during procedure.

Remarks

The enumerator interface supports both IEnumVARIANT and IEnumUnknown . You can find information about these interfaces in the Platform SDK.

See Also

Reference

IAppVerifierStops interface


IAppVerifierStops::get_Count method
See Also

Retrieves the number of stops in the collection.

Copy Code
HRESULT
    get_Count
   (
    long*
    plCount

);

Parameters

plCount

[out] Points to the number of images in the collection.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierStops interface


IAppVerifierStops::get_Item method
See Also

Retrieves the specified IAppVerifierImageStop object from the collection.

Copy Code
HRESULT
    get_Item
   (
    LONG
    lStopCode
  ,
    IAppVerifierStop**
    ppStop

);

Parameters

lStopCode

[in] Stop code of the stop to retrieve from the collection.

ppStop

[out] Points to the stop object.

Return Value

The following list includes the most like return values. However, other return values are possible.

S_OK

The method succeeded.

E_FAIL

The method failed.

E_POINTER

Pointer is invalid.

See Also

Reference

IAppVerifierStops interface
IAppVerifierStop interface


How to use Application Verifier

You should use Application Verifier throughout your Software Development Lifecycle (SDL also referred to as the Security Development Lifecycle):

  • Requirements Phase - AppVerifier should be planned and time allocated for its execution and follow up.

  • Design Phase - Plan for the use of Application Verifier and define which components (modules, DLLs or EXEs) will be tested.

  • Implementation Phase - Run Application Verifier on stable builds (from Alpha to RTM) of the different components under development (it is important to test the components individually and collectively).

  • Verification Phase - Testers should execute all of their tests (both manual and automatic) with Application Verifier since this will be the first time that the application will be pushed to the limits and unexpected behavior and data will be submitted. AppVerifier is also a powerful tool for security consultants doing audits (black box and white box) since it will allow the quick enumeration of real (or potential) attack/exploit vectors.

  • Release Phase - Clients and security consultants can use AppVerifier on the released binaries to identify potential security vulnerabilities.

  • Support and Servicing Phase - Use Application Verifier to ensure that code changes (e.g. updates, service packs) do not introduce regressions.

  • For more information, please see the published whitepaper on MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/appverifier_sdl.asp.

Installing and configuring

  1. Install: Download the latest version of Application Verifier from http://www.microsoft.com/technet/prodtechnol/windows/appcompatibility/appverifier.mspx where you will find setup binaries for the supported architectures: x86, ia64, amd64.

  2. Debugger setup: The application being verified should run under a user-mode debugger or the system should run under a kernel debugger since it will break into a debugger when an error occurs. Please see the Application Verifier help contents for more debugger details.

  3. Settings: Application Verifier cannot be enabled for a running process. As a result, you need to make settings as described below and then start the application. The settings are persistent until explicitly deleted. Therefore, no matter how many times you launch an application it will start with AppVerifier enabled until the settings are deleted.

Using Application Verifier with WOW64

In Windows 7, you can use either the 32-bit or the 64-bit version of Application Verifier to verify a 32-bit application running under WOW64.

In Windows Vista and earlier operating systems, you should use the 32-bit version of Application Verifier to verify 32-bit applications, and you should use the 64-bit version of Application Verifier to verify 64-bit applications.

In Windows Vista and earlier operating systems, be sure that 32-bit applications are enabled only in the 32-bit version of Application Verifier. That is, do not enable a given 32-bit application in both the 32-bit and 64-bit versions of Application Verifier.

Using Application Verifier Basics Test

The scenarios below showcase the recommended command line and user interface options. These should be run during all tests that exercise the code to ensure complete coverage. The expectation for these scenarios is that application does not break into debugger and all tests pass with the same pass rate as when run without AppVerifier enabled.

  1. Enable verifier for the application(s) you wish to test using. From the command line: appverif /verify MyApp.exe. From the user interface: Add your application by right clicking within the Applications area and selecting Add Application . Select the Basics from the Tests area. Click the Save button.

Notes:

  • /verify will enable the basics tests

  • If you are testing a DLL, Application Verifier has to be enabled for the test executable that is exercising the DLL.

  • Run the verification layers separately. For example, in one session enable all Basics and on another one enable all LuaPriv checks.

  1. Run ALL your tests exercising the application.

  2. Analyze any debugger break(s) encountered. If a break occurs you will need to understand it and fix it. NOTE: The help contents provide details on the breaks and how to investigate them.

  3. When finished, delete all settings. From the command line: appverif /n MyApp.exe. From the user interface:

  • Remove your application by right clicking within the Applications area and selecting Delete Application

  • Click the Save button.

Using AppVerifier Low Resource Simulation (fault injection)

The expectation for this scenario is that the application does not break into debugger. By not breaking into the debugger means that you have no errors that need to be addressed.

The pass rate for the tests may decrease significantly since random fault injections are introduced into the normal operation.

  1. Enable Application Verifier Low Resource Simulation (fault injection) for the application(s). From the command line: Appverif /verify MyApp.exe /faults . From the user interface: Add your application by right clicking within the Applications area and selecting Add Application . Select the Low Resource Simulation from the Tests area. Click the Save button.

    Note: If you are testing a DLL, you can apply low resource simulation (fault injection) on a certain DLL instead of the whole process. The command line format would be: appverif /verify TARGET [/faults [PROBABILITY [TIMEOUT [DLL …]]]]

    Example: appverif /verify mytest.exe /faults 50000 1000 d3d9.dll

  2. Run ALL your tests exercising the application

  3. Analyze any debugger break(s) encountered. If a break occurs you will need to understand it and fix it.

  4. When finished, delete all settings. From the command line: appverif /n MyApp.exe. From the user interface: remove your application by right clicking within the Applications area and selecting Delete Application , clicking the Save button.

  5. Note: Running with and without fault injection exercises largely different code paths in an application and therefore both scenarios must be run in order to get the full benefit of AppVerifier.

Analyzing AppVerifier Data

  • All data created during AppVerifier analysis is stored in the %USERPROFILE%\AppVerifierLogs folder in a binary format. These logs can then be converted to XML via the user interface or command line for further analysis.

  • To view the XML files, you can use of one of the following techniques:

  • Web Browser – All modern web browsers are able to display XML files in a structured and color-coded format.

  • Using XSL Transformations – Create an XSLT which converts the raw XML content into reports containing only information relevant to you.

  • Import into Microsoft Excel - Import the XML file into Excel and use filters or Pivot Tables to reorganize and analyze the collected data.

  • Import into Database – Save the XML files and import them into a SQL, Access, etc. database.


Stop Codes and Definitions

An Application Verifier stop code is data provided when an error is found by the verification layer that is being run on a project. The stop codes that may be encountered are based on the checks selected to run. Within this topic section, you will find a page per stop code that provides you with the break message, probable cause, information displayed by Application Verifier, and additional information.

How to find the details

There are a few ways to find out the details of a stop code:

  1. I know the stop code: If you know the stop code number (e.g. 000c), you can go directly to the index and click on it. OR you can do a search. Both of these will display the stop code page.

  2. I know the error message: If you know the error message, search with in the help contents to display the page.


Basics Stops

An Application Verifier stop code is data provided when an error is found by the verification layer that is being run on the solution or project. The stop codes that may be encountered are based on the checks selected to run.

List of Stop Codes

Stop codes are based on the verification layer. To see a complete list of stops please see:

  • Exceptions Stop Details

  • Handles Stop Details

  • Heaps Stop Details

  • Leak Stop Details

  • Locks Stop Details

  • SRWLock Stop Details

  • Memory Stop Details

  • TLS Stop Details

  • Threadpool Stop Details


Exceptions Stop Details

The Exception checks ensure that applications do not hide access violations by using structured exception handling.

Following is a list of verifier stops that may occur when running the Exception verifier against a program:

Error message | Stop code
Attempt to execute code in non-executable memory (first chance) | 0650


Attempt to execute code in non-executable memory (first chance)

Application Verifier break message

Attempt to execute code in non-executable memory (first chance).

Probable cause

This stop is generated if the application is trying to run code from an address that is non-executable or free.

Information displayed by Application Verifier

Parameter1 - Address being accessed

Parameter2 - Code performing invalid access

Parameter3 - Exception record. Use .exr to display it.

Parameter4 - Context record. Use .cxr to display it

Description - Attempt to execute code in non-executable memory (first chance)

Additional information

Verifier stop code 0650.

To debug this stop:

u parameter2 - to unassemble the culprit code

.exr parameter3 - to display the exception information;

.cxr parameter4 followed by kb - to display the exception context information and the stack trace for the time when the exception was raised.


Handles Stop Details

The Handles tests ensure that an application does not attempt to use invalid handles. This includes the following checks:

  • Ensures that handles are valid when passed to APIs that take a handle. If a NULL value or an INVALID_HANDLE_VALUE value is passed, the handle is clearly invalid and further investigation is necessary.

  • Ensures that TLS indexes passed to TLS functions are valid.

  • Ensures that APIs are not called with handles that have been closed.

  • Following is a list of verifier stops that may occur when running the Handles verifier against a solution or project on different platforms:

Error message | Stop code
Invalid handle exception for current stack trace | 0300
Invalid TLS index used in current stack | 0301
Invalid parameters for WaitForMultipleObjects call | 0302
NULL handle passed as parameter. A valid handle must be used | 0303
Waiting on a thread handle in DllMain | 0304
Incorrect object type for handle | 0305

Properties

There is one property that you can change for the Handles check:

Traces - Enter in the amount of handle traces to be saved. For example 1024 will save 1k handle traces.


Invalid handle exception for current stack trace

Application Verifier break message

Invalid handle exception for current stack trace.

Probable cause

This break is generated if the function on the top of the stack passed an invalid handle to system routines.

Typically this break occurs because the handle is used after it was closed.

Information displayed by Application Verifier

Parameter1 - Exception code

Parameter2 - Exception record. Use .exr to display it

Parameter3 - Context record. Use .cxr to display it

Parameter4 - Not used

Description - Invalid handle exception for current stack trace

Additional information

Verifier stop code 0300.

Call Stack – current call stack of last operation when handle was found to be invalid.

Frequency of this error is high.

To debug:
Usually a simple kb command will reveal what is the value of the handle passed (must be one of the parameters – usually the first one). If the value is null then this is clearly wrong. If the value looks ok you need to use !htrace debugger extension to get a history of operations pertaining to this handle value.


Invalid TLS index used in current stack

Application Verifier break message

Invalid TLS index used for current stack trace.

Probable cause

Invalid TLS index used for current stack trace.

Information displayed by Application Verifier

Parameter1 – Invalid TLS index

Parameter2 – Expected lower part of the index.

Parameter3 – Not Used

Parameter4 – Not Used

Description – This stop is generated if the function on the top of the stack passed an invalid TLS index to the TLS routines. Usually a simple kb command will reveal what is wrong. The typical bug here is to assume a certain value for a TLS index instead of calling TlsAlloc. This can happen either by thinking that you always get value ‘N’ therefore there is no need to call TlsAlloc or more frequently due to an uninitialized variable.

Additional information

Verifier stop code 0301.


Invalid parameters for WaitForMultipleObjects call

Application Verifier break message

Invalid parameters for WaitForMultipleObjects call.

Probable cause

This stop is generated if the function on the top of the stack called WaitForMultipleObjects with NULL as the address of the array of handles to wait for or with zero as the number of handles. A simple kb command will reveal the function calling this API incorrectly.

Information displayed by Application Verifier

Parameter1 - Address of object handle vectors

Parameter2 - Number of handles

Parameter3 - Not used

Parameter4 - Not used

Description - Invalid parameters for WaitForMultipleObjects call

Additional information

Verifier stop code 0302.

Call Stack – current call stack of last operation when the invalid parameters were passed to the wait function.

Frequency of this error is low.


NULL handle passed as parameter. A valid handle must be used

Application Verifier break message

NULL handle passed as parameter. A valid handle must be used.

Probable cause

This stop is generated if the function on the top of the stack passed a NULL handle to system routines. Usually a simple kb command will reveal what is the value of the handle passed (must be one of the parameters - usually the first one).

Information displayed by Application Verifier

Parameter1 - ID of the handle

Parameter2 - Not used

Parameter3 - Not used

Parameter4 - Not used

Description - NULL handle passed as parameter. A valid handle must be used

Additional information

Verifier stop code 0303.

Call stack - current call stack where a NULL handle is being used.

Frequency of this stop is high.


Waiting on a thread handle in DllMain

Application Verifier break message

Waiting on a thread handle in DllMain.

Probable cause

This stop is generated when the current thread is running code inside the DllMain function of one of the DLLs loaded in the current process and it calls WaitForSingleObject or WaitForMultipleObjects to wait on a thread handle in the same process.

This condition will most likely lead to a deadlock because the thread handle will not get signaled unless that second thread is exiting. When the second thread calls ExitThread it will try to acquire the DLL loader lock then call DllMain (DLL_THREAD_DETACH) for all DLLs in the current process. But the loader lock is owned by the first thread (the one that is waiting on the thread handle) so the two threads will deadlock.

Information displayed by Application Verifier

Parameter1 - Thread handle

Parameter2 - Not used

Parameter3 - Not used

Parameter4 - Not used

Description - Waiting on a thread handle in DllMain

Additional information

Verifier stop code 0304.

Frequency of this error is low.

The debugee hangs. 'StopDebugging' required


Incorrect object type for handle

Application Verifier break message

Incorrect object type for handle.

Probable cause

This stop is generated if the current thread is calling an API with a handle to an object with an incorrect object type. For example, calling SetEvent with a semaphore handle as parameter will generate this stop.

Information displayed by Application Verifier

Parameter1 - Handle value

Parameter2 - Object type name. Use du to display it

Parameter3 - Expected object type name. Use du to display it

Parameter4 - Not used

Description - Object type name. Use du to display it

Additional information

Verifier stop code 0305.

Frequency of this error is low.

To debug this stop:

kb – to display the current stack trace. The culprit is probably the DLL that is calling into verifier.dll;

du parameter2 – to display the actual type of the handle. The handle value is parameter1.

du parameter3 – to display the object type expected by the API.

!htrace parameter1 might be helpful because it will display the stack trace for the recent open/close operations on this handle.


Heaps Stop Details

The Heap Verifier uses guard pages (or not depending on the properties selected) to check for memory corruption issues in the heap. Following is a list of verifier stops that may occur when running the Heap verifier against a solution or project on different platforms:

Error message | Stop code
Unknown Error (Heap) | 0001
Access Violation Exception | 0002
Multithreaded access in a heap created with HEAP_NO_SERIALIZE | 0003
Extreme size request | 0004
Heap handle with incorrect signature | 0005
Corrupted heap pointer or using wrong heap | 0006
Heap block already freed | 0007
Corrupted heap block | 0008
Attempt to destroy process heap | 0009
Unexpected exception raised while executing heap management code | 000A
Exception raised while verifying heap block header | 000B
Exception raised while verifying the heap block | 000C
Heap block corrupted after being freed | 000D
Corrupted infix pattern for freed heap block | 000E
Corrupted suffix pattern for heap block | 000F
Corrupted start stamp for heap block | 0010
Corrupted end stamp for heap block | 0011
Corrupted prefix pattern for heap block | 0012
First chance access violation for current stack trace | 0013
Invalid process heap list count | 0014

System Requirements

The Page Heap test uses guard pages to detect memory corruption issues in the heap. To gain the most useful information from this test, the computer should contain at least 256MB of RAM and have a 1GB page file.

Properties

There are several properties for the Heaps check that can be altered:

  • Full – Check to implement full page heap. If unselect it’s normal page heap

  • Dlls - Page heap allocations for target dlls only. Name of the binaries with extension (dll or something else). If you wish to enter in more than one, enter a space between the dll names.

  • Size - Page heap allocations for size range. Specify the size range in the Size Start and Size End.

  • SizeStart - Beginning of the size range

  • SizeEnd - Ending of the size range.

  • Random - Page heap allocations with probability. If selected, you need to enter in a RandRate.

  • RandRate - Decimal integer in range [0..100] representing probability to make page heap allocation vs. a normal heap allocation.

  • Backward - Catch backwards overruns. If selected, this will check buffer underruns.

  • Unalign - No alignment for allocations.

  • Traces - Collect stack traces

  • Protect - Protect heap internal structures. Can be used to detect random corruptions but execution is slower. Note that this is turned off by default and should only be set to True by an advanced user who knows how to debug the problems that it may uncover.

  • NoLock - Disable critical section verifier.

  • Faults – Enable heap fault injection. Note that the preferred method for running fault injection is the Low Resource Simulation Stops.

  • FaultRate - Probability (1..10000) for heap calls failures

  • TimeOut - Time during process initialization (in milliseconds) when faults are not allowed.

  • Addr - Page heap allocations for address range. If selected, please specify the address range in AddrStart and AddrEnd.

  • AddrStart - Beginning of the address range

  • AddrEnd - Ending of the address range

  • UseLFHGuardPage - Turns on LFH guard pages, which is turned off by default.

  • DelayFreeSize (MB) - Maximum amount of memory, in megabytes, to use for delayed free list. The Heap Verifier checks this list to detect double freeing of an allocation and the use of an allocation after it has been freed. The default value of this property varies by processor architecture.

Additional information

Heap detects almost any heap related bug that is detectable. It is focused on corruption issues and not on leaks. The Page Heap tests in Application Verifier are not able to capture information about most heap memory leaks, so a different tool would be useful for that category of heap problem.

One of the great advantages of the Page Heap test in Application Verifier is that many errors can be detected in the instant they happen. For example, an off by one byte error at the end of a dynamically allocated buffer might cause an instant access violation. However, there are a few error categories that cannot be detected instantly and the error report is delayed until the block is freed.

The Page Heap functionality provides the following tests to Application Verifier:

  • Invalid heap pointer - All Microsoft Win32 and NT level heap interfaces take as first parameter a pointer to the heap where the operation should happen. The page heap manager detects at the moment of the call an invalid heap pointer.

  • Invalid heap block pointer - After a block is allocated it can be used as a parameter for several heap interfaces (most notably free() class of interfaces). The page heap manager detects immediately an invalid heap block pointer. See the debugging techniques section for a way to determine if the invalid address is just meaningless information or is a few bytes off.

  • Multithreaded unsynchronized access to the heap - some applications call into a heap from multiple threads. This type of scenario requires setting a flag (by the user) that triggers acquiring a heap lock. The page heap manager detects this type of violation in the moment two threads attempt to call simultaneously into the heap.

  • Assumptions about reallocation of a block at the same address - Although it is thoroughly documented that a reallocation operation is not guaranteed to return the same address, once in a while applications contain this assumption. This is especially the case when the reallocation reduces the size of the block. The page heap manager always allocates a new block during a reallocation and frees the old block. The free block is protected for R/W access and therefore any access to it raises an access violation.

  • Double free - It is a bug noticed with high frequency. Heap blocks are freed several times. This is detected immediately by the page heap manager because on the second free the block does not have the proper prefix header and cannot be found among the allocated blocks. See the debugging techniques section for ways to figure out the stack trace of the first free operation. This error can be a variant of the reallocation problem because when the application frees what it thinks is the address of the block, that block was already freed as part of the reallocation.

  • Access of block after free - The memory blocks freed are kept for a while by the page heap manager in a pool of protected memory. Any access to such a block raises an access violation. Based on the "locality" principle, it is expected to catch most of the problems if the free protected pool is large enough. If the freed block is still in the protected pool then the bug is caught instantly. If the memory was reused, the chances of finding the bug decrease considerably.

  • Access after the end of allocated block - The page heap manager places an inaccessible page right after the allocated block. Any access after the end of the block raises an access violation. There is one little caveat. Some applications (for example, Microsoft Internet Explorer) expect allocations to be 8-byte aligned. This is a feature supported since the heap manager in Microsoft Windows NT 3.5. This means that a request size that is not 8-byte aligned gets an 8-byte aligned address and this leaves a few bytes after the end of the block that are still accessible. If the application corrupts only those few bytes then the error is caught only when the block gets freed by checking the block suffix pattern.

  • Access before the start of allocated block - The page heap manager can be instructed through setting a flag to place the inaccessible page at the beginning rather than at the end of the block. Any access before the start of the block raises an access violation.

For more information, see the Heap details topic.


Access Violation Exception

Application Verifier break message

Access Violation Exception.

Probable cause

This is the most common application verifier stop. Typically it is caused by a buffer overrun error. The heap verifier places a non-accessible page at the end of a heap allocation and a buffer overrun will cause an exception by touching this page.

There are several other causes for this stop. For example accessing a heap block after being freed.

Information displayed by Application Verifier

Parameter1 - Invalid address causing the exception

Parameter2 - Code address executing the invalid access

Parameter3 - Exception record

Parameter4 - Context record

Additional information

Verifier Stop code 0002.

To debug: Identify the access address that caused the exception and then use the following debugger commands: !heap -p -a ACCESS_ADDRESS.


Attempt to destroy process heap

Application Verifier break message

Attempt to destroy process heap.

Probable cause

It is incorrect to try to destroy the default process heap (the one returned by GetProcessHeap() interface). This message can happen if while calling GetProcessHeaps() interface the page heap manager detects some internal inconsistencies. This can be caused by random corruption in the process space.

Information displayed by Application Verifier

Parameter1 - Heap handle used with HeapDestroy

Parameter2 - not used

Parameter3 - not used

Parameter4 - not used

Description - Attempt to destroy process heap

Additional information

Verifier stop code 0009.

Frequency of this error is very low.


Heap block corrupted after being freed

Application Verifier break message

Heap block corrupted after being freed.

Probable cause

This situation happens if a block of memory is written to after being freed.

Information displayed by Application Verifier

Parameter1 - Heap handle for the heap owning the block

Parameter2 - Heap block that is corrupted

Parameter3 - Size of the block or zero if size cannot be determined

Parameter4 - Not used

Description - Heap block corrupted after being freed.

Additional information

Verifier stop code 000D.


Corrupted end stamp for heap block

Application Verifier break message

Corrupted end stamp for heap block.

Probable cause

This error is hit when the end-stamp of the header of the block is corrupted. This occurs during buffer underruns.

Information displayed by Application Verifier

Parameter1 - Heap handle used in the call

Parameter2 - Heap block involved in the operation

Parameter3 - Size of the heap block

Parameter4 - Corrupted stamp value

Description - Corrupted end stamp for heap block

Additional information

Verifier stop code 0011.

Frequency of this error is low.


Corrupted heap block

Application Verifier break message

Corrupted heap block.

Probable cause

This break is used as a generic message if the error cannot be categorized in any of the other heap errors.

Information displayed by Application Verifier

Parameter1 - Heap handle used in the call

Parameter2 - Heap block involved in the operation

Parameter3 - Size of the heap block

Parameter4 - not used

Description - Corrupted heap block

Additional information

Verifier stop code 0008.


Exception raised while verifying heap block header

Application Verifier break message

Exception raised while verifying heap block header.

Probable cause

This error is hit if a particular type of corruption block cannot be determined. For instance, this stop will happen when the heap block address passed to a heap free points to a non-accesible memory area (corrupted pointer, uninitialized pointer, etc.).

Information displayed by Application Verifier

Parameter1 - Heap handle for the heap owning the block

Parameter2 - Heap block that is corrupted

Parameter3 - Size of the block or zero if size cannot be determined

Parameter4 - Not Used

Description - Exception raised while verifying heap block header

Additional information

Verifier stop code 000B.


Corrupted infix pattern for freed heap block

Application Verifier break message

Corrupted infix pattern for freed heap block.

Probable cause

Freed blocks are sometimes marked non-accessible and a program touching them will access violate (different verifier stop). In other cases (normal page heap) the block is marked with a magic pattern and will be kept for a while. Eventually in a FIFO fashion the blocks get really freed. At this moment the infix pattern is checked and if it has been modified you will get this break. The stack at the break moment is not relevant. You need to find out the nature of the block and review the code that might be wrong. This error is hit when there is a corrupted infix pattern for freed block.

Information displayed by Application Verifier

Parameter1 - Heap handle for the heap owning the block

Parameter2 - Heap block being freed

Parameter3 - Size of the heap block

Parameter4 - Not used

Description - Corrupted infix pattern for freed heap block.

Additional information

Verifier stop code 000E.

Frequency of this error is high


Corrupted prefix pattern for heap block

Application Verifier break message

Corrupted prefix pattern for heap block.

Probable cause

This happens for buffer underruns and when the prefix pattern is corrupted.

Information displayed by Application Verifier

Parameter1 - Heap handle used in the call

Parameter2 - Heap block involved in the operation

Parameter3 - Size of the heap block

Parameter4 - Not used

Description - Corrupted prefix pattern for heap block

Additional information

Verifier stop code 0012.

Frequency of this error is low.


Corrupted start stamp for heap block

Application Verifier break message

Corrupted start stamp for heap block.

Probable cause

This error is hit when the start-stamp of the header of the block is corrupted. This occurs during buffer underruns.

Information displayed by Application Verifier

Parameter1 - Heap handle used in the call

Parameter2 - Heap block involved in the operation

Parameter3 - Size of the heap block

Parameter4 - Corrupted stamp value

Description - Corrupted start stamp for heap block

Additional information

Verifier stop code 0010.

Frequency of this error is low.


Corrupted suffix pattern for heap block

Application Verifier break message

Corrupted suffix pattern for heap block.

Probable cause

Most typically this happens for buffer overrun errors. Sometimes the application verifier places non-accessible pages at the end of the allocation and buffer overruns will cause an access violation (full page heap) and sometimes the heap block is followed by a magic pattern (normal or light page heap). If this pattern is changed when the block gets freed you will get this break. These breaks can be quite difficult to debug because you do not have the actual moment when corruption happened. You just have access to the free moment (stop happened here) and the allocation stack trace. This error is hit when the trail fill pattern is corrupted.

Information displayed by Application Verifier

Parameter1 - Heap handle used in the call

Parameter2 - Heap block involved in the operation

Parameter3 - Size of the heap block

Parameter4 - Not Used

Description - Corrupted suffix pattern for heap block

Additional information

Verifier stop code 000F.

Frequency of this error is high.

To debug use: !heap –p –a HEAP_ADDRESS.


Extreme size request

Application Verifier break message

Extreme size request.

Probable cause

This break will be generated if in a HeapAlloc() or HeapReAlloc() operation the size of the block is above any reasonable value. Typically this value is 0x80000000 on 32-bit platforms and 0x8000000000000000 on 64-bit platforms. This error is hit when the allocation size is a negative number treated as a positive one.

Information displayed by Application Verifier

Parameter1 - Heap in which operation happens

Parameter2 - Size requested

Parameter3 - Not used

Parameter4 - Not used

Description - Excessive size of <bytes> for the current operation.

Additional information

Verifier stop code 0004

Call stack - Current call stack when the block was allocated using either HeapAlloc() or Heap ReAlloc().

Frequency of this error is very low.


First chance access violation for current stack trace

Application Verifier break message

First chance access violation for current stack trace.

Probable cause

This is the most common application verifier stop. Typically it is caused by a buffer overrun error. The heap verifier places a non-accessible page at the end of a heap allocation and a buffer overrun will cause an exception by touching this page. There are several other causes for this stop. For example, accessing a heap block after being freed. The same debugger command will be useful for this case too.

Information displayed by Application Verifier

Parameter1 - Invalid address causing the exception

Parameter2 - Code address executing the invalid access

Parameter3 - Exception record. Context Record

Parameter4 - Context record

Description - First chance access violation for current stack trace

Additional information

Verifier Stop code 0013.

To debug this stop identify the access address that caused the exception and then use the following debugger command:

!heap -p -a ACCESS_ADDRESS This command will give details about the nature of the error and what heap block is overrun. It will also give the stack trace for the block allocation.


Heap handle with incorrect signature

Application Verifier break message

Heap handle with incorrect signature.

Probable cause

This break can occur if somehow the internal heap structure maintained by the Application Verifier got corrupted due to a random corruption or when a false value is used as a heap handle.

Note: If you switch a valid heap handle with another valid one in a heap operation you will not get this stop (the handle looks valid after all). However the heap verifier detects this situation and reports it with the CORRUPTED_HEAP_BLOCK stop.

Information displayed by Application Verifier

Parameter1 - Heap handle used in the call to a heap interface

Parameter2 - Not Used

Parameter3 - Not Used

Parameter4 - Not Used

Description - Heap handle with incorrect signature

Additional information

Verifier stop code 0005

Call stack - Current call stack when the block was allocated using either HeapAlloc() or Heap ReAlloc().

To get a list of valid heap handle values use the following debugger commands: !heap -p


Heap block already freed

Application Verifier break message

Heap block already freed.

Probable cause

This break occurs if the block is freed twice. Freed blocks are marked in a special way and are kept around for a while. If a buggy program tries to free the block again this is caught using this break.

Information displayed by Application Verifier

Parameter1 - Heap handle of the heap owning the block

Parameter2 - Heap block being freed again

Parameter3 - Size of the heap block

Parameter4 - Not used

Description - Heap block already freed

Additional information

Verifier stop code 0007.

Frequency of this stop is high.


Corrupted heap pointer or using wrong heap

Application Verifier break message

Corrupted heap pointer or using wrong heap. Heap operation performed on an invalid heap handle: <handle ID> was expected.

Probable cause

The heap structures are tagged with a specific value. If the heap handle used in the call to a heap interface does not have this specific value then this stop will be generated. This bug can happen if the internal heap structure got corrupted or an invalid handle was used.

Information displayed by Application Verifier

Parameter1 - Heap handle used in the call

Parameter2 - Heap block involved in the operation

Parameter3 - Size of the heap block

Parameter4 - Heap that actually owns the block

Description - Corrupted heap pointer or using wrong heap

Additional information

Verifier stop code 0006.

To debug use the !heap –p command to get a list of all valid heap handle values.


Multithreaded access in a heap created with HEAP_NO_SERIALIZE

Application Verifier break message

Multithreaded access in a heap created with HEAP_NO_SERIALIZE: thread <thread ID> is in a running state conflicting with thread <thread ID>.

Probable cause

A heap created with HEAP_NO_SERIALIZE flag is not supposed to be accessed simultaneously from two threads. The typical way this situation creeps into a program is by linking with a single-threaded version of the C runtime. Visual C++ can for instance link statically such a library when proper flags are used. The bug is very difficult to debug in real life because it will show up as mysterious data corruptions.

Information displayed by Application Verifier

Parameter1 - Heap in which operation happens

Parameter2 - Thread ID for current owner of the heap critical section

Parameter3 - Thread ID of current thread trying to enter

Parameter4 - Not Used

Description - Multithreaded access in a heap created with HEAP_NO_SERIALIZE: thread 0xae8 is in a running state conflicting with thread 0xac8

Additional information

Verifier stop code 0003.

Frequency of this error is low.


Unexpected exception raised while executing heap management code

Application Verifier break message

Unexpected exception raised while executing heap management code.

Probable cause

This stop is generated if while executing the heap manager code an access violation is raised in illegitimate situations. There are very few situations where this is ok, for example when calling HeapValidate() or HeapSize(). The exception record information can be used to find the exact context of the exception. This stop can also happen if there is some random corruption in the internal heap structures or for double free situations if the block among full page heap blocks cannot be found and its probed as a light page heap block.

Information displayed by Application Verifier

Parameter1 - Heap handle used in the call

Parameter2 - Exception record

Parameter3 - Context record

Parameter4 - Exception code

Description - Unexpected exception raised while executing heap management code

Additional information

Verifier code stop 000A.

Frequency of this error is low.

To debug use:

  • dd parameter2 L2

  • .exr first_dword

  • .cxr second_dword


Invalid process heap list count

Application Verifier break message

Invalid process heap list count.

Probable cause

This message can happen if while calling GetProcessHeaps() interface the page heap manager detects some internal inconsistencies. This can be caused by some random corruption in the process space.

Information displayed by Application Verifier

Parameter1 - Actual heap count

Parameter2 - Page heap count

Parameter3 - Not used

Parameter4 - Not used

Description - Invalid process heap list count

Additional information

Verifier Stop code 0014.


Unknown Error (Heap)

Application Verifier break message

Unknown Error.

Probable cause

This message can happen if the error encountered cannot be classified in any way

Not used right now.

Information displayed by Application Verifier

Parameter1 - Not Used

Parameter2 - Not Used

Parameter3 - Not Used

Parameter4 - Not Used

Description - Unknown Error

Additional information

Verifier Stop code 0001.


Heap details

The structure of a page heap block

With full page heap enabled for end of buffer overrun type of bugs the program will access violate instantly. These failures are easy to debug because the current stack trace points directly to the broken code. If normal page heap is used or the corruption happens in the small fill pattern at end of buffer for alignment reasons (see subsection about unaligned allocations) the corruption will be detected only when the block is freed. In these cases more involved detective techniques are required. To make life easier in such cases the page heap manager places a header before all allocations (full and normal). This header contains a few valuable bits of information (owning heap, user requested size and stack trace for the allocation in some cases). The structure of the full and normal page heap blocks is described below.

Normal page heap block structure

Full page heap block structure

The Heap field stores the owning heap. The user requested size for the block is in RequestedSize. The stack can be obtained by issuing a dds debugger command at StackTrace address. The best way to get a dump of this structure is to use the dt debugger command:

dt DPH_BLOCK_INFORMATION ADDRESS

The StackTrace field will not always contain a non-null value for various reasons. First of all stack trace detection is supported only on x86 platforms and second, even on x86 machines the stack trace detection algorithms are not completely reliable. If the block is an allocated block the stack trace is for the allocation moment. If the block was freed, the stack trace is for the free moment.

Special fill pointers

The page heap manager fills the user allocation with values that will look as kernel pointers. This happens when the block gets freed (fill value is F0) and when the block gets allocated but no request is made for the block to be zeroed (fill value is E0 for normal page heap and C0 for full page heap). The non-zeroed allocations are typical for malloc/new users. If there is a failure (access violation) where a read/write is attempted at addresses like F0F0F0F0, E0E0E0E0, C0C0C0C0 then most probably you hit one of these cases.

A read/write at F0F0F0F0 means a block has been used after it got freed. Unfortunately you will need some detective work to find out which block caused this. You need to get the stack trace of the failure and then inspect the code for the functions on the stack. One of them might make a wrong assumption about an allocation being alive.

A read/write at E0E0E0E0/C0C0C0C0 means the application did not initialize properly the allocation. This requires also code inspection of the functions in the current stack trace. Here it is a contorted example of this kind of failure. In a test process an access violation while doing a HeapFree on address E0E0E0E0 is noticed. It turned out that the test allocated a structure, did not initialize it correctly and then called the destructor of the object. Since a certain field was not null (it had E0E0E0E0 in it) it called delete on it.


Exception raised while verifying the heap block

Application Verifier break message

Exception raised while verifying the heap block.

Probable cause

This error is hit if a particular type of corruption block cannot be determined. For instance you will get this if during a heap free operation you pass an address that points to a non-accessible memory area.

This can also happen for double free situations if the block among full page heap blocks cannot be found and it is probed as a light page heap block.

Information displayed by Application Verifier

Parameter1 - Heap handle used in the call

Parameter2 - Heap block involved in the operation

Parameter3 - Size of the heap block

Parameter4 - Not Used

Description - Exception raised while verifying the heap block

Additional information

Verifier stop code 000C.


Leak Stop Details

Leak Verifier tracks resources allocated by DLL or EXE modules. If a resource that was allocated by a DLL or EXE module is not released by the time the module is unloaded, Leak Verifier issues a stop. Leak Verifier is designed to catch virtual reservation, registry, handle, and heap leaks. Leak Verifier is enabled by default.

Caution:
Leak Verifier does not report any resource leaks until the DLL or EXE that allocated the resource is unloaded. To inspect resource allocations in a loaded DLL or EXE, use the !avrf -leak debugger extension.

Leak Verifier is available starting with Windows 7.

Leak Verifier Stops

Following list identifies the Leak Verifier stops.

Error message | Stop code
A heap allocation was leaked | 900
A Handle was leaked | 901
An HKEY was leaked | 902
A virtual reservation was leaked | 903
A BSTR was leaked | 904
A power notification was not unregistered | 905

Properties

The following property is available for the Leak verification layer. To set the property, select the Leak layer in the Application Verifier user interface, and open the Property Window.

Property | Description
ExcludeDlls | A comma-separated list of DLLs to exclude from leak verification. Maximum size is 255 characters.

The following command line enables leak verification for myApp.exe and all binaries loaded by myApp.exe except KnownLeaker.dll.

Copy Code
appverif –enable Leak –for myApp.exe –with Leak.ExcludeDlls=KnownLeaker.dll

If you enable leak verification as shown the preceding example, the Leak verification layer still tracks the resources for KnownLeaker.dll, but it does not report any leaks caused by KnownLeaker.dll.

Additional information

You can use the !avrf –leak debugger extension to look at all outstanding resources in a loaded module.

Copy Code
!avrf -leak  [-m <DllName>]  [-r  <ResourceType>] [ -a <address>] [-t] [/?] [-?]

Display all the outstanding resources in myModule.dll.
!avrf -leak -m myModule.dll

Display all the outstanding heap resources in myModule.dll.
!avrf -leak -m myModule.dll -r heap

Display resource with <address> in outstanding heap resources in myModule.dll.
!avrf -leak -m myModule.dll -r heap -a <address>

Display resource with <address> in outstanding heap resources in myModule.dll with stack trace.
!avrf -leak -m myModule.dll -r heap -a <address> -t

ResourceTypes:

Heap
Heap allocations using Win32 Heap APIs

Local
Local/Global allocations

CRT
Heap allocations using C runtime functions

Virtual
Virtual reservations

BSTR
BSTR allocations (These resources are tracked, but not reported as leaks by the leak check.)

Registry
Registry keys

Power
Power notifications

Handle
Certain types of handles (thread, file, event)


A heap allocation was leaked

Application Verifier break message

A heap allocation was leaked.

Probable Cause

A DLL allocated memory in a heap, and the allocation was not freed before the DLL was dynamically unloaded.

Information Displayed by Application Verifier

Parameter 1 – Address of the heap allocation.

Parameter 2 – Address to the allocation stack trace.

Parameter 3 – Address of the name of the DLL that made the heap allocation.

Parameter 4 – Base address of the DLL that made the heap allocation.

Additional Information

Verifier stop code 900

To debug this stop:

Run !heap -p -a Parameter 1 to get additional information about the allocation.

dps Parameter 2 to get the stack trace of the allocation

du Parameter 3 to get the name of the DLL that made the heap allocation

.reload dll_name= Parameter 4 to reload the DLL

lm to get more information about the loaded and unloaded modules


An HKEY was leaked

Application Verifier break message

An HKEY was leaked.

Probable Cause

A DLL allocated an HKEY object, and the HKEY was not released before the DLL was dynamically unloaded.

Information Displayed by Application Verifier

Parameter 1 – Value of the HKEY.

Parameter 2 – Address of the allocation stack trace.

Parameter 3 – Address of the name of the DLL that allocated the HKEY.

Parameter 4 – Not used.

Additional Information

Verifier stop code 902

To debug this stop:

dps Parameter 2 to get the stack trace of the allocation

du Parameter 3 to get the name of the DLL that allocated the HKEY


A Handle was leaked

Application Verifier break message

A handle was leaked.

Probable Cause

A DLL obtained a handle, and the handle was not released before the DLL was dynamically unloaded.

Information Displayed by Application Verifier

Parameter 1 – Value of the handle.

Parameter 2 – Address of the allocation stack pointer.

Parameter 3 – Address of the name of the DLL that obtained the handle.

Parameter 4 – not used.

Additional Information:

Verifier stop code 901

To debug this stop:

!htrace Parameter1 to get additional information about the handle.

dps Parameter 2 to get the stack trace of the allocation

du Parameter 3 to get the name of the DLL that allocated the resource


A virtual reservation was leaked

Application Verifier break message

A virtual reservation was leaked.

Probable Cause

A DLL reserved a range of virtual addresses, and the range of virtual addresses was not freed before the DLL was dynamically unloaded.

Information Displayed by Application Verifier

Parameter 1 – Starting address of the range of reserved addresses.

Parameter 2 – Address of the allocation stack trace.

Parameter 3 – Address of the name of the DLL that owns the allocation.

Parameter 4 – Base address of the DLL that owns the allocation.

Additional Information

Verifier stop code 903

To debug this stop:

dps Parameter 2 to get the stack trace of the allocation

du Parameter 3 to get the name of the DLL that owns the allocation

.reload dll_name = Parameter 4 to reload the DLL that owns the allocation

lm to get more information about loaded and unloaded modules


A BSTR was leaked

Application Verifier break message

A BSTR was leaked.

Probable Cause

A DLL allocated a BSTR, and the BSTR was not freed before the DLL was dynamically unloaded.

Information Displayed by Application Verifier

Parameter 1 – Address of the BSTR.

Parameter 2 – Address of the allocation stack trace.

Parameter 3 – Address of the name of the DLL that allocated the BSTR.

Parameter 4 – Base address of the DLL.

Additional Information

Verifier stop code 904

To debug this stop:

!heap –p –a Parameter 1 to get additional information about the allocation.

dps Parameter 2 to view the allocation stack

du Parameter 3 to view the DLL name.

.reload dll_name = Parameter 4 to reload the owner DLL.

lm to get more information about the loaded and unloaded modules.


A power notification was not unregistered

Application Verifier break message

A power notification was not unregistered.

Probable Cause

A DLL registered for power notification, and the request was not unregistered before the DLL was dynamically unloaded.

Information Displayed by Application Verifier

Parameter 1 – Address of the power notification registration.

Parameter 2 – Address of the registration stack trace.

Parameter 3 – Address of the name of the DLL.

Parameter 4 – Base address of the DLL.

Additional Information:

Verifier stop code 905

To debug this stop:

dps Parameter 2 to view the allocation stack trace

du Parameter 3 to view the DLL name

.reload dll_name = Parameter 4 to reload the DLL

lm to get more information about the loaded and unloaded modules


Locks Stop Details

The Lock Verifier checks for errors (or stops) in the file lock usages. The primary purpose of the Locks test is to ensure that the application uses critical sections properly.
Following is a list of verifier stops that may occur when running the lock verifier against a solution or project on different platforms:

Error message | Stop code
Thread that is exiting owns a critical section | 0200
Unloading dll containing active critical section | 0201
Freeing heap block containing an active critical section | 0202
Double initialized or corrupted critical section | 0203
Free memory containing an active critical section | 0204
Corrupted critical section | 0205
Invalid critical section owner thread | 0206
Invalid critical section recursion count | 0207
Deleting critical section with invalid lock count | 0208
Critical section over released or corrupted | 0209
Critical section not initialized | 0210
Critical section is already initialized | 0211
Freeing virtual memory containing an active critical section | 0212
Unmapping memory region containing an active critical section | 0213
Current thread does not own any critical sections | 0214
Using Critical Section that is Private to Another DLL | 0215

Additional information

Other details regarding lock checks:

  • Checks for the unload of a DLL that contains an active critical section. This leads to resource leaks.

  • Checks for a heap block free that contains an active critical section. This also leads to resource leaks.

  • Ensures that an application does not attempt to initialize a critical section more than once. This causes undefined behavior.

  • Checks for corruption of a critical section. The DebugInfo field of the critical section must not point to freed memory.

  • Checks for an owner thread ID which is invalid in the current context.

  • Ensures that the recursion count field of the critical section is not invalid in the current context.

  • Checks that the critical section was initialized before being deleted.

  • Ensures that the critical section is not released more times than the current thread acquired it.

  • Checks that the critical section has been initialized prior to being used.


Double initialized or corrupted critical section

Application Verifier break message

Double initialized or corrupted critical section.

Probable cause

Usually this stop is generated if a critical section has been initialized more than one time. Some other times it is possible to get this stop if the critical section or its debug information structure has been corrupted. In this case it is possible that the first initialization stack track and second are invalid and useless.

Information displayed by Application Verifier

Parameter1 - Critical section address. Run !cs –s address to get more information.

Parameter2 - Address of the debug information structure found in the active list

Parameter3 - First initialization stack trace. Run dps address to dump the stack trace.

Parameter4 - Second initialization stack trace. Run dps address to dump the stack trace.

Description - Double initialized or corrupted critical section.

Additional information

Verifier stop code 0203.

Check the contents of the current call stack when the memory was released.

Frequency of this error is high.

To debug this stop:

!cs –s –d parameter2 - dump information about this critical section.

ln parameter1 – to show symbols near the address of the critical section. This might help identify the critical section if this is a global variable.

dds parameter3 and dds parameter4 - to identify the two code paths for initializing this critical section.


Unloading dll containing active critical section

Application Verifier break message

Unloading dll containing active critical section.

Probable cause

This stop is generated if a DLL has a global variable containing a critical section and the DLL is unloaded but the critical section has not been deleted.

Information displayed by Application Verifier

Parameter1 - Critical section address. Run !cs –s address to get more information.

Parameter2 - Critical section initialization stack trace. Run dps address to dump the stack trace.

Parameter3 - DLL name address

Parameter4 - DLL base address

Description - Unloading dll containing active critical section

Additional information

Verifier stop code 0201.

Check the contents of the current call stack when the DLL with the active lock was unloaded.

Frequency of this error is high.

To debug this stop use the following debugger commands:

du parameter3 – to dump the name of the culprit DLL.

.reload dllname or .reload dllname = parameter4 - to reload the symbols for that DLL.

!cs –s parameter1 - dump information about this critical section.

ln parameter1 – to show symbols near the address of the critical section. This should help identify the leaked critical section.

dds parameter2 – to dump the stack trace for this critical section initialization.


Freeing virtual memory containing an active critical section

Application Verifier break message

Freeing virtual memory containing an active critical section. The region of virtual memory at <location> of size <size> contains an active lock <lock address>.

Probable cause

This break is generated if the current thread is calling VirtualFree on a memory block that contains an active critical section. The application should call DeleteCriticalSection on this critical section before if frees this memory.

kb – to display the current stack trace, that is calling VirtualFree. The probable culprit is the DLL that calls VirtualFree.

Information displayed by Application Verifier

Parameter1 - Critical section address. Run !cs –s address to get more information.

Parameter2 - Critical section initialization stack trace. Use dps to dump it if non-NULL.

Parameter3 - Memory block address

Parameter4 - Memory block size

Description - Freeing virtual memory containing an active critical section.

Additional information

Verifier stop code 0212.

Call Stack – Current call stack when the virtual memory is released using VirtualFree

Frequency of this error is low.

To debug:

!cs –s parameter1- dump information about this critical section.

dds parameter2 - to identify the code path for the initialization of this critical section


Freeing heap block containing an active critical section

Application Verifier break message

Freeing heap block containing an active critical section. Memory location at <lock address> of size <size> contains an active lock.

Probable cause

This break is generated if a heap allocation contains a critical section, the allocation is freed and the critical section has not been deleted.

Information displayed by Application Verifier

Parameter1 - Critical section address. Run !cs –s address to get more information.

Parameter2 - Critical section initialization stack trace. Run dps address to dump the stack trace.

Parameter3 - Heap block address

Parameter4 - Heap block size

Description - Freeing heap block containing an active critical section

Additional information

Verifier stop code 0202.

Check the contents of the current call stack. The culprit is usually the caller of HeapFree or HeapDestroy on the current stack trace.

Frequency of this error is high.

To debug this stop use the following debugger commands:

!cs –s parameter1 - dump information about this critical section.

ln parameter1 – to show symbols near the address of the critical section. This should help identify the leaked critical section.

dds parameter2 – to dump the stack trace for this critical section initialization.

parameter3 and parameter4 might help understand where was this heap block allocated (the size of the allocation is probably significant).


Deleting critical section with invalid lock count

Application Verifier break message

Deleting critical section with invalid lock count

Probable cause

This break is generated if a critical section is owned by another thread and the critical section is being deleted by the current thread. If the owning thread is 0, the critical section has not been initialized.

Information displayed by Application Verifier

Parameter1 - Critical section address. Run !cs –s address to get more information.

Parameter2 - Lock count

Parameter3 - Expected lock count

Parameter4 - Owning thread

Description - Deleting critical section with invalid lock count

Additional information

Verifier stop code 0208.

Call Stack – current call stack when thread exited.

Frequency of this stop is high

To debug this stop:

!cs –s parameter1 - dump information about this critical section. If the owning thread is 0 the critical section has not been initialized.

ln parameter1 – to show symbols near the address of the critical section. This should help identify the critical section.


Critical section is already initialized

Application Verifier break message

Critical section is already initialized.

Probable cause

This break is generated if a critical section is reinitialized by the current thread.

Information displayed by Application Verifier

Parameter1 - Critical section address. Run !cs –s address to get more information.

Parameter2 - Critical section debug information address

Parameter3 - First initialization stack trace. Use dds to dump it if non-NULL.

Parameter4 - Not used

Description - Critical section is already initialized.

Additional information

Verifier stop code 0211.

Call Stack – Stack trace of the lock's re-initialization.

Frequency of this error is high.

To debug this stop:

!cs –s parameter1or !cs –s –d parameter2 - dump information about this critical section.

ln parameter1 – to show symbols near the address of the critical section. This might help identify the critical section if this is a global variable

dds parameter3 - to identify the code path for the first initialization of this critical section.

kb – to display the current stack trace, that is reinitializing this critical section.


Critical section over released or corrupted

Application Verifier break message

Critical section over-released or corrupted

There are several messages that you may receive when hitting this stop. Locks violation detected:

  • The lock <lock address> has been release more often than necessary: actual lock count <count>, expected <count>

  • Thread not supposed to be owning a lock. Number of locks owned is <count>

  • The owner of the lock is invalid, owner <owner> was expected

  • The recursion count is invalid : actual recursion count <count> - expected <count>

  • The lock had been released more that it should: actual lock count -<count> - expected <count>

Probable cause

This break is generated if a critical section is released more times than the current thread acquired it.

Information displayed by Application Verifier

Parameter1 - Critical section address. Run !cs –s address to get more information.

Parameter2 - Lock count

Parameter3 - Expected lock count

Parameter4 - Critical section debug information address

Description - Critical section over-released or corrupted

Additional information

Verifier stop code 0209.

Call Stack – current call stack where lock is being used.

Frequency of this error is high.

To debug this stop:

!cs –s parameter1 - dump information about this critical section.

!cs –s –d parameter4 - dump information about this critical section.

ln parameter1 – to show symbols near the address of the critical section. This should help identify the critical section.


Corrupted critical section

Application Verifier break message

Corrupted critical section

Probable cause

This break is usually generated if a critical section has been initialized more than one time.

This stop is generated if the DebugInfo field of the critical section is pointing to freed memory. Usually another valid DebugInfo structure is found in the active critical section list. Without corruption the two pointers should be identical.

Information displayed by Application Verifier

Parameter1 - Critical section address. Run !cs –s address to get more information.

Parameter2 - Invalid debug information address of this critical section

Parameter3 - Address of the debug info found in the active list

Parameter4 - Initialization stack trace. Run dps address to dump the stack trace.

Description - Corrupted critical section

Additional information

Verifier stop code 0205.

Check the contents of the current call stack when the heap lock was reinitialized (misused).

Frequency of this error is low.

To debug this stop use the following debugger commands:

!cs –s –d parameter3 - dump information about this critical section based on the current contents of the debug info structure found in the active list (this structure is rarely corrupted so usually this information is trustworthy).

!cs –s parameter1 - dump information about this critical section based on the current contents of the critical section structure (the structure is corrupted already so sometimes this information is NOT trustworthy).

dds parameter4 - to identify the code path for initializing this critical section

Dump the critical section at address parameter1 and look for the corruption pattern. With good symbols for ntdll.dl you can use the following commands:

dt ntdll!_RTL_CRITICAL_SECTION LOCK_ADDRESS

dt ntdll!_RTL_CRITICAL_SECTION_DEBUG DEBUG_ADDRESS


Invalid critical section owner thread

Application Verifier break message

Invalid critical section owner thread

Probable cause

This break is generated if the owner thread ID is invalid in the current context. For example, the critical section is being released by a thread other than the one that acquired it.

Information displayed by Application Verifier

Parameter1 - Critical section address. Run !cs –s address to get more information.

Parameter2 - Owning thread

Parameter3 - Expected owning thread

Parameter4 - Critical section debug information address

Description - Invalid critical section owner thread

Additional information

Verifier stop code 0206.

Check the contents of the current call stack where the thread calls EnterCriticalSection or LeaveCriticalSection.

Frequency of this stop is low.

To debug this stop:

!cs –s parameter1 - dump information about this critical section.

ln parameter1 – to show symbols near the address of the critical section. This should help identify the critical section.


Invalid critical section recursion count

Application Verifier break message

Invalid critical section recursion count.

Probable cause

This break is generated if the recursion count field of the critical section structure is invalid in the current context.

Information displayed by Application Verifier

Parameter1 - Critical section address. Run !cs –s address to get more information.

Parameter2 - Recursion count

Parameter3 - Expected recursion count

Parameter4 - Critical section debug information address

Description - Invalid critical section recursion count

Additional information

Verifier stop code 0207.

Call Stack – current call stack when the thread calls EnterCriticalSection or TryEnterCriticalSection

Frequency of this error is low.

To debug this stop:

!cs –s parameter1 - dump information about this critical section.

ln parameter1 – to show symbols near the address of the critical section. This should help identify the critical section.


Unmapping memory region containing an active critical section

Application Verifier break message

Unmapping memory region containing an active critical section.

Probable cause

This break is generated if the current thread is calling UnmapViewOfFile on a memory block that contains an active critical section. The application should call DeleteCriticalSection on this critical section before it releases this memory.

kb – to display the current stack trace, that is calling UnmapViewOfFile . The probable culprit is the DLL that calls UnmapViewOfFile.

Information displayed by Application Verifier

Parameter1 - Critical section address. Run !cs –s address to get more information.

Parameter2 - Critical section initialization stack trace. Use dps to dump it if non-NULL.

Parameter3 - Memory block address

Parameter4 - Memory block size

Description - Unmapping memory region containing an active critical section

Additional information

Verifier Stop Code 0213.

Frequency of this error is low.

To debug:

!cs –s parameter1- dump information about this critical section.

dps parameter2 - to identify the code path for the initialization of this critical section.


Thread that is exiting owns a critical section

Application Verifier break message

Thread that is exiting owns a critical section.

Probable cause

This stop is generated if a thread is terminated, suspended or is in a state (worker thread finished a work item) in which it cannot hold a critical section. The current thread is the culprit.

If the current thread is the owner of the critical section, it is probably calling ExitThread. The current thread should have released the critical section before exiting. If the current thread is calling TerminateThread() or SuspendThread() then it should not do this while holding a critical section.

Information displayed by Application Verifier

Parameter1 - Thread ID of the thread that is exiting while owning a critical section

Parameter2 - Critical section address. Run !cs –s address to get more information.

Parameter3 - Critical section debug information address

Parameter4 - Critical section initialization stack trace. Run dps address to dump the stack trace.

Description - Thread cannot own a critical section

Additional information

Verifier stop code 0200.

Check the contents of the current call stack when the thread exited.

Frequency of this error is low.

To debug this stop use the following debugger commands:

kb – to get the current stack trace. If the current thread is the owner of the critical section it is probably calling ExitThread. The current thread should have released the critical section before exiting. If the current thread is calling TerminateThread or SuspendThread then it should not do this for a thread holding a critical section.

!cs –s parameter2 - dump information about this critical section.

ln parameter2 – to show symbols near the address of the critical section. This should help identify the leaked critical section.

dds parameter4 – to dump the stack trace for this critical section initialization.


Current thread does not own any critical sections

Application Verifier break message

Current thread does not own any critical sections.

Probable cause

This break is generated if the current thread calls LeaveCriticalSection but, according to the internal application verifier bookkeeping, it does not own any critical section.

If the number of locks owned is 0, the current thread is attempting to release a critical section it did not acquire or it is calling LeaveCriticalSection more often than it called EnterCriticalSection for a given critical section.

Information displayed by Application Verifier

Parameter1 - Critical section address. Run !cs –s address to get more information.

Parameter2 - Number of critical sections owned by current thread

Parameter3 - Not used

Parameter4 - Not used

Description - Current thread does not own any critical sections

Additional information

Verifier stop code 0214.

Call Stack – Current call stack when the thread attempts to release a lock it does not own.

Frequency of this error is low.

If parameter2 is zero, probably this is a bug in the current thread. It either tries to leave a critical section that it didn’t enter, or maybe it is calling LeaveCriticalSection more times than it called EnterCriticalSection for the same critical section.

If parameter2 is not zero (it is a negative integer number) the internal verifier data structures are probably corrupted.


Free memory containing an active critical section

Application Verifier break message

Free memory containing an active critical section.

Probable cause

This stop is generated if the memory containing a critical section was freed but the critical section has not been deleted using DeleteCriticalSection.

The critical section must have been in a memory range freed by kernel-mode code or freed cross-process by APIs like VirtualFreeEx. Typically, this stop will be encountered if a previous break was continued. For example, if you encountered the Released heap memory of size <size> at <address> containing an active lock <lock address> break and then chose to continue running the code you may expect to encounter this break message as well. In most cases the lock verifier detects immediately leaked critical sections contained in a heap allocation, a DLL range, a virtual memory allocation or a MapViewOfFile mapped memory range and issues different stops in these cases. So there are very few cases left for this verifier stop.

Information displayed by Application Verifier

Parameter1 - Critical section address. Run !cs –s address to get more information.

Parameter2 - Critical section debug info address

Parameter3 - Critical section initialization stack trace. Run dps address to dump the stack trace.

Parameter4 - Not used

Description - Free memory containing an active critical section

Additional information

Verifier Stop Code 0204.

Check the contents of the current call stack when the memory was released.

Frequency of this error is low.

To debug this stop use the following debugger commands:

!cs –s –d parameter2 - dump information about this critical section.

dds parameter3 - to identify the code path for initializing this critical section.


Using Critical Section that is Private to Another DLL

Application Verifier break message

Using critical section that is private to another DLL.

Probable cause

This break is generated if the current thread tries to use a private lock that lives inside another DLL. For example, a DLL tries to enter a critical section defined inside ntdll.dll. Private locks cannot be used across DLLs.

Information displayed by Application Verifier

Parameter1 - Critical section address. Run !cs –s address to get more information.

Parameter2 - Not used

Parameter3 - Not used

Parameter4 - Not used

Description - Using critical section that is private to another DLL

Additional information

Verifier stop code 0215.


Critical section not initialized

Application Verifier break message

Critical section not initialized.

Probable cause

This stop is generated if a critical section is reinitialized by the current thread.

Information displayed by Application Verifier

Parameter1 - Critical section address. Run !cs –s address to get more information.

Parameter2 - Critical section debug info address

Parameter3 – Used to identify the code path for the first initialization of this critical section.

Parameter4 - Not used

Description - Critical section not initialized

Additional information

Verifier Stop Code 0210.

To debug this stop:

!cs -s parameter1 or !cs -s -d parameter2 - dump information about this critical section.

ln parameter1 - to show symbols near the address of the critical section. This might help identify the critical section if this is a global variable.

dds parameter3 - to identify the code path for the first initialization of this critical section.

kb - to display the current stack trace, that is reinitializing this critical section


SRWLock Stop Details

The slim reader/writer (SRW) lock checks ensure that applications initialize, acquire, and release SRW locks correctly.

Error message | Stop code
The SRW lock is not initialized | 0250
The SRW lock is already initialized | 0251
Mismatched Acquire-Release on the SRW lock | 0252
The SRW lock is being acquired recursively by the same thread | 0253
The thread that is exiting or being terminated owns an SRW lock | 0254
The SRW lock being released was not acquired by this thread | 0255
The memory being freed contains an active SRW lock | 0256
The DLL that is being unloaded contains an active SRW lock | 0257


The SRW lock is not initialized

Application Verifier break message

The SRW lock is not initialized.

Probable cause

This stop is generated if a thread tries to use an SRW lock that is not initialized.

Information displayed by Application Verifier

Parameter 1 – SRW lock address

Parameter 2 – Not used

Parameter 3 – Not used

Parameter 4 – Not used

Additional Information

Verifier Stop Code 0250.

To debug this stop, use the following debugger command:

kb - to get the current stack trace. The trace will show you where the SRW lock is being used.

The SRW lock must be initialized by calling InitializeSRWLock before it can be used.


The SRW lock is already initialized

Application Verifier break message

The SRW lock is already initialized.

Probable cause

This stop is generated if an SRW lock is being reinitialized.

Information displayed by Application Verifier

Parameter 1 – SRW lock address

Parameter 2 – Thread ID of the thread that initialized the SRW lock

Parameter 3 – Address of the initialization stack trace

Parameter 4 – Not used

Additional Information

Verifier Stop Code 0251.

If an SRW lock is being actively used by other threads, reinitializing the lock can result in unpredictable behavior, including a hang or a crash.

To debug this stop, use the following debugger commands:

kb - to get the current stack trace. The trace shows you where the lock is being reinitialized.

dps parameter 3 – to get the SRW lock initialization stack trace. If the lock was statically initialized, this stack trace will show the acquisition of the lock.


Mismatched Acquire-Release on the SRW lock

Application Verifier break message

Mismatched Acquire-Release on the SRW lock.

Probable cause

This stop is generated in the following situations:

  • An SRW lock was acquired by calling AcquireSRWLockShared and is being released by calling ReleaseSRWLockExclusive.

  • An SRW lock was acquired by calling AcquireSRWLockExclusive and is being released by calling ReleaseSRWLockShared.

Information displayed by Application Verifier

Parameter 1 – SRW lock address

Parameter 2 – Thread ID of the thread that acquired the SRW lock

Parameter 3 – Address of the “acquire” stack trace

Parameter 4 – Not used

Additional Information

Verifier Stop Code 0252.

A mismatch between the functions called to acquire and release an SRW lock can result in unpredictable behavior, including a hang or a crash.

To debug this stop, use the following debugger commands:

kb - to get the current stack trace. The stack trace shows you where the SRW lock is being released by the wrong function.

dps parameter 3 – to get the “acquire” stack trace. The “acquire” stack trace shows you where the lock was acquired.


The SRW lock is being acquired recursively by the same thread

Application Verifier break message

The SRW lock is being acquired recursively by the same thread.

Probable cause

This stop is generated if an SRW lock is being acquired recursively by the same thread.

Information displayed by Application Verifier

Parameter 1 – SRW lock address

Parameter 2 – Address of the first “acquire” stack trace.

Parameter 3 – Not used

Parameter 4 – Not used

Additional Information

Verifier Stop Code 0253.

If you acquire an SRW lock recursively, the result can be a deadlock and a thread that blocks indefinitely. Recursive acquisition of an SRW lock in exclusive mode will cause a deadlock. Recursive acquisition of an SRW lock in shared mode will cause a deadlock when there is a thread waiting for exclusive access. Consider the example below.

  1. Thread A acquires the SRW lock in shared mode.

  2. Thread B tries to acquire the SRW lock in exclusive mode and waits.

  3. Thread A tries to acquire the SRW lock in shared mode recursively. This will be successful as long as there is no exclusive waiter (in this case B). Since SRW locks do not have writer starvation, thread A waits behind thread B. Now Thread B is waiting for Thread A, which is in turn waiting for Thread B, This is a circular wait, which results in a deadlock.

To debug this stop, use the following debugger commands:

kb - to get the current stack trace. The stack trace shows you where the SRW lock is being acquired recursively.

dps parameter 2 – to get the first “acquire” stack trace. The first “acquire” stack trace shows you where the lock was acquired.


The thread that is exiting or being terminated owns an SRW lock

Application Verifier break message

The thread that is exiting or being terminated owns an SRW lock.

Probable cause

This stop is generated if a thread that owns an SRW lock is exiting or being terminated.

Information displayed by Application Verifier

Parameter 1 – SRW lock address

Parameter 2 – Thread ID of the thread that is exiting or being terminated

Parameter 3 –Address of the “acquire” stack trace

Parameter 4 – Not used

Additional Information

Verifier Stop Code 0254.

If a thread that owns an SRW lock exits or is terminated, the lock becomes orphaned, and other threads that try to acquire the lock will be blocked indefinitely.

To debug this stop, use the following debugger commands:

kb - to get the current stack trace. The trace shows you where the thread is exiting or being terminated.

dps parameter 3 – to get the “acquire” stack trace. The “acquire” stack trace shows you where the SRW lock was acquired.


The SRW lock being released was not acquired by this thread

Application Verifier break message

The SRW lock being released was not acquired by this thread.

Probable cause

This stop is generated if an SRW lock is being released by a thread that did not acquire the lock.

Information displayed by Application Verifier

Parameter 1 – SRW lock address

Parameter 2 – Thread ID of the current thread

Parameter 3 –Thread ID of the thread that acquired the SRW lock

Parameter 4 – Address of the “acquire” stack trace

Additional Information

Verifier Stop Code 0255.

Releasing an SRW lock from a thread that did not acquire the lock can lead to unpredictable behavior.

To debug this stop, use the following debugger commands:

kb – to get the stack trace. The stack trace shows you where the current thread is releasing an SRW lock that it did not acquire.

dps parameter 4 – to get the “acquire” stack trace. The “acquire” stack trace shows you where the lock was acquired.


The memory being freed contains an active SRW lock

Application Verifier break message

The memory being freed contains an active SRW lock.

Probable cause

This stop is generated if a memory address being freed contains an active SRW lock that is still in use.

Information displayed by Application Verifier

Parameter 1 – SRW lock address

Parameter 2 – Address of the memory being freed

Parameter 3 – Thread ID of the thread that acquired the SRW lock

Parameter 4 – Address of the “acquire” stack trace

Additional Information

Verifier Stop Code 0256.

Freeing memory that contains an active SRW lock can result in unpredictable behavior, including a crash or a hang.

To debug this stop, use the following debugger commands:

kb – to get the stack trace. The stack trace shows you where the memory is being freed.

dps parameter 4 – to get the “acquire” stack trace. The “acquire” stack trace shows you where the lock was acquired.


The DLL that is being unloaded contains an active SRW lock

Application Verifier break message

The DLL being unloaded contains an active SRW lock.

Probable cause

This stop is generated if a DLL that is being unloaded contains an active SRW lock that is still in use.

Information displayed by Application Verifier

Parameter 1 – SRW lock address

Parameter 2 – Address of the name of the DLL being unloaded

Parameter 3 – Thread ID of the thread that acquired the SRW lock

Parameter 4 – Address of the “acquire” stack trace

Additional Information

Verifier Stop Code 0257.

Unloading a DLL that contains an active SRW lock can result in unpredictable behavior, including a crash or a hang.

To debug this stop, use the following debugger commands:

kb - to get the current stack trace. The stack trace shows you where the DLL is being unloaded.

du parameter 2 – to get the name of the DLL that is being unloaded.

dps parameter 4 – to get the “acquire” stack trace. The “acquire” stack trace shows you where the lock was acquired.


Memory Stop Details

The Memory checks ensure APIs for virtual space manipulations are used correctly (e.g. VirtualAlloc, VirtualFree, MapViewOfFile).

Following is a list of verifier stops that may occur when running the memory checks against a solution or project on different platforms:

Error message | Stop code
Freeing virtual memory block with invalid size or start address | 0600
Incorrect virtual allocation call | 0601
Incorrect map view call | 0602
Probing invalid address | 0603
Probing free memory | 0604
Probing a guard page | 0605
Probing null address | 0606
Probing memory block with invalid start address or size | 0607
Unloading DLL with invalid size or start address | 0608
Freeing memory block inside current thread's stack address range | 0609
Incorrect FreeType parameter for VirtualFree operation | 060A
Trying to free virtual memory block that is already freed | 060B
Incorrect size parameter for VirtualFree (MEM_RELEASE) operation | 060C
Unexpected exception raised in DLL entry point routine | 060D
Unexpected exception raised in thread function | 060E
Unexpected exception raised while probing memory | 060F
Trying to reset NULL address | 0610
Freeing heap memory block inside current thread's stack address range | 0612
Unmapping memory region inside current thread's stack address range | 0613
Incorrect RTL_RESOURCE address | 0614
Invalid critical section address | 0615
Attempt to execute code in non-executable memory | 0616
Unexpected exception raised while initializing output buffer | 0617
Unexpected exception when trying to find heap block size | 0618
Freeing memory block within invalid start address | 0619
Unmapping memory block with invalid start address | 061A
Unexpected exception raised in threadpool callback function. | 061B
Code in non-executable memory. | 061C
Creating executable heap | 061D
Allocating executable memory | 061E

Properties

There is one property for the memory tests: ExecWritePage. This property when turned on (off by default) will generate two stops.

  1. Creating executable heap

  2. Allocating executable memory

Double click the property to edit it. Click the check box to turn the value to True, which turns on the test.


Allocating executable memory

Application Verifier break message

Allocating executable memory.

Probable cause

This stop is generated if the application is allocating executable memory.

Information displayed by Application Verifier

Parameter1 - Page protection specified by caller

Parameter2 - Not used

Parameter3 - Not used

Parameter4 - Not used

Description - This stop is generated if the application is allocating executable memory. This can be a security risk.

Additional information

Verifier stop code 061E.


Attempt to execute code in non-executable memory

Application Verifier break message

Attempt to execute code in non-executable memory.

Probable cause

This stop is generated if the application is trying to run code from an address that is non-executable or free.

Information displayed by Application Verifier

Parameter1 - Address being accessed

Parameter2 - Code performing invalid access

Parameter3 - Exception record. Use .exr to display it.

Parameter4 - Context record. Use .cxr to display it

Description - Attempt to execute code in non-executable memory

Additional information

Verifier stop code 0616.

To debug this stop:

u parameter2 - to unassemble the culprit code

.cxr parameter4 followed by kb - to display the exception context information and the stack trace for the time when the exception was raised.


Creating executable heap

Application Verifier break message

Creating executable heap.

Probable cause

This stop is generated if the application is creating an executable heap.

Information displayed by Application Verifier

Parameter1 - Not used

Parameter2 - Not used

Parameter3 - Not used

Parameter4 - Not used

Description - This stop is generated if the application is creating an executable heap. This can be a security risk.

Additional information

Verifier stop code 061D.


Freeing memory block inside current thread's stack address range

Application Verifier break message

Freeing memory block inside current thread's stack address range.

Probable cause

This stop is generated if Application Verifier detects a VirtualFree for a block of memory that is actually part of the current thread's stack (!).

Information displayed by Application Verifier

Parameter1 - Allocation base address

Parameter2 - Memory region size

Parameter3 - Stack low limit address

Parameter4 - Stack high limit address

Description - Freeing memory block inside current thread's stack address range

Additional information

Verifier stop code 0609.

To debug this stop look at the current stack trace (kb) and try to understand why the function that called VirtualFree thought that the memory block was dynamically allocated or mapped but that was actually memory allocated from the stack.


Freeing heap memory block inside current thread's stack address range

Application Verifier break message

Freeing heap memory block inside current thread's stack address range.

Probable cause

This stop is generated if Application Verifier detects a VirtualFree for a block of memory that is actually part of the current thread's stack (!).

Information displayed by Application Verifier

Parameter1 - Allocation base address

Parameter2 - Memory region size

Parameter3 - Stack low limit address

Parameter4 - Stack high limit address

Description - Freeing heap memory block inside current thread's stack address range

Additional information

Verifier stop code 0612.

To debug this stop look at the current stack trace (kb) and try to understand why the function that called HeapFree thought that the memory block was dynamically allocated or mapped but that was actually memory allocated from the stack.


Freeing memory block within invalid start address

Application Verifier break message

Freeing memory block within invalid start address.

Probable cause

This stop is generated if the program calls VirtualFree (MEM_RELEASE) with an lpAddress parameter that is not the base address returned by the VirtualAlloc or VirtualAllocEx function when the region of pages was reserved.

Information displayed by Application Verifier

Parameter1 - Address of memory block being freed

Parameter2 - Expected correct memory block address

Parameter3 - Not used

Parameter4 - Not used

Description - Freeing memory block with invalid start address

Additional information

Verifier stop code 0619.

To debug this stop:

kb - to display the current stack trace, that is calling VirtualFree. The probable culprit is the DLL that calls VirtualFree.


Freeing virtual memory block with invalid size or start address

Application Verifier break message

Freeing virtual memory block with invalid size or start address.

Probable cause

This stop is generated if Application Verifier detects a VirtualFree or a DLL unload with an invalid start address or size of the memory allocation. In the case of DLL unload this probably means a memory corruption inside the loaded DLL list.

Information displayed by Application Verifier

Parameter1 - Allocation base address

Parameter2 - Memory region size

Parameter3 - Not used

Parameter4 - Not used

Description - Freeing virtual memory block with invalid size or start address

Additional information

Verifier stop code 0600.

To debug this stop look at the current stack trace and the memory address and size that is about to be freed and try to determine why they are invalid.


Invalid critical section address

Application Verifier break message

Invalid critical section address.

Probable cause

This stop is generated if the application is trying to use NULL or some other incorrect address (e.g. a kernel-mode address) as the address of a valid object. EnterCriticalSection(NULL) is an incorrect API call that will trigger this kind of verifier stop.

Information displayed by Application Verifier

Parameter1 - Address

Parameter2 - not used

Parameter3 - not used

Parameter4 - not used

Description - Invalid critical section address

Additional information

Verifier stop code 0615.

To debug: Parameter1 is the incorrect address used and the culprit is on the stack trace (display it with kb).


Incorrect FreeType parameter for VirtualFree operation

Application Verifier break message

Incorrect FreeType parameter for VirtualFree operation.

Probable cause

This stop is generated if Application Verifier detects a VirtualFree with an incorrect value for the FreeType parameter. The only two valid values for this parameter are MEM_DECOMMIT and MEM_RELEASE. If VirtualFree is called with any other value except these two, VirtualFree will fail to free the memory.

Information displayed by Application Verifier

Parameter1 - Incorrect value used by the application

Parameter2 - Expected correct value 1

Parameter3 - Expected correct value 2

Parameter4 - Not used

Description - Incorrect FreeType parameter for VirtualFree operation

Additional information

Verifier stop code 060A.

To debug this stop look at the current stack trace (kb): the caller of VirtualFree is probably the culprit.


Incorrect map view call

Application Verifier break message

Incorrect map view call.

Probable cause

This stop is generated if Application Verifier detects a MapViewOfFile call with an invalid base address or size of the mapping.

Information displayed by Application Verifier

Parameter1 - Pointer to mapping base address

Parameter2 - Pointer to view size

Parameter3 - Not used

Parameter4 - Not used

Description - Incorrect map view call

Additional information

Verifier stop code 0602

To debug this stop look at the current stack trace (kb) and the memory address and size that is about to be mapped and try to determine why they are invalid.


Incorrect RTL_RESOURCE address

Application Verifier break message

Incorrect RTL_RESOURCE address.

Probable cause

This stop is generated if the application is trying to use NULL or some other incorrect address (e.g. a kernel-mode address) as the address of a valid object. RtlInitializeResource (NULL) is an incorrect API call that will trigger this kind of verifier stop.

Information displayed by Application Verifier

Parameter1 - Address

Parameter2 - not used

Parameter3 - not used

Parameter4 - not used

Description - Incorrect RTL_RESOURCE address

Additional information

Verifier stop code 0614.

To debug: Parameter1 is the incorrect address used and the culprit is on the stack trace (display it with kb).


Incorrect size parameter for VirtualFree (MEM_RELEASE) operation

Application Verifier break message

Incorrect size parameter for VirtualFree (MEM_RELEASE) operation.

Probable cause

This stop is generated if Application Verifier detects a VirtualFree (MEM_RELEASE) with a non-zero value for the dwSize parameter. When using MEM_RELEASE, the only valid value for this parameter is 0. If VirtualFree is called with any other value except 0, VirtualFree will fail to free the memory.

Information displayed by Application Verifier

Parameter1 - Incorrect size used by the application

Parameter2 - Expected correct size (0)

Parameter3 - not used

Parameter4 - not used

Description - Incorrect Size parameter for VirtualFree (MEM_RELEASE) operation

Additional information

Verifier stop code 060C.

To debug this stop look at the current stack trace (kb): the caller of VirtualFree is probably the culprit.


Incorrect virtual allocation call

Application Verifier break message

Incorrect virtual allocation call.

Probable cause

This stop is generated if Application Verifier detects a VirtualAlloc call with an invalid start address or size of the memory allocation.

Information displayed by Application Verifier

Parameter1 - Pointer to allocation base address

Parameter2 - Pointer to memory region size

Parameter3 - Not used

Parameter4 - Not used

Description - Incorrect virtual allocation call

Additional information

Verifier stop code 0601.

To debug this stop look at the current stack trace (kb) and the memory address and size that is about to be allocated and try to determine why they are invalid.


Probing a guard page

Application Verifier break message

Probing a guard page.

Probable cause

This stop is generated if Application Verifier detects an IsBadXXXPtr call for a memory allocation that contains as least on GUARD_PAGE. This is very bad because it is very possible that this GUARD_PAGE is the end of the current stack of a thread. As documented in the MSDN library: Dereferencing potentially invalid pointers can disable stack expansion in other threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information.

Information displayed by Application Verifier

Parameter1 - Start address

Parameter2 - Memory block size

Parameter3 - Address of guard page

Parameter4 - Not used

Description - Probing a guard page

Additional information

Verifier stop code 0605.

To debug this stop look at the current stack trace (kb) and try to determine why the caller of the IsBadXXXPtr function ended up probing a GUARD_PAGE.

MSDN library lists a few reasons why applications should not use the IsBadXXXPtr APIs:

  • In a preemptive multitasking environment, it is possible for some other thread to change the process's access to the memory being tested.

  • Dereferencing potentially invalid pointers can disable stack expansion in there threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information.

  • Threads in a process are expected to cooperate in such a way that one will not free memory that the other needs. Use of this function does not negate the need to do this. If this is not done, the application may fail in an unpredictable manner.

Because of all these reasons, it is recommended to never use these APIs.


Probing free memory

Application Verifier break message

Probing free memory.

Probable cause

This stop is generated if Application Verifier detects an IsBadXXXPtr call for a memory allocation that is free. This is very bad because it is possible that, in some other cases, this memory was already reused for some other allocation. Since the current code path (kb) doesn't own that memory, it could end up corrupting someone else's memory, with disastrous effects.

Information displayed by Application Verifier

Parameter1 - Start address

Parameter2 - Memory block size

Parameter3 - Address of free memory page

Parameter4 - Not used

Description - Probing free memory

Additional information

Verifier stop code 0604.

To debug this stop look at the current stack trace (kb) and try to determine why the caller of the IsBadXXXPtr function ended up probing free memory. The address could be plain bogus (e.g. uninitialized pointer) or maybe already freed memory. If the memory was already freed by one of the VirtualFree or UnmapViewOfFile APIs, "!avrf -vs -a parameter3" will search for a log of stack traces of the code paths that allocated/freed that address and display these stack traces if they are available. This might show the stack trace that freed up this memory. More often, the memory is an already freed heap allocation. To check for that possibility, "!avrf -hp -a parameter3" will search for a log of stack traces of the code paths that allocated/freed that address from/to the heap and display these stack traces if they are available.

MSDN library lists a few reasons why applications should not use the IsBadXXXPtr APIs:

  • In a preemptive multitasking environment, it is possible for some other thread to change the process's access to the memory being tested.

  • Dereferencing potentially invalid pointers can disable stack expansion in there threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information.

  • Threads in a process are expected to cooperate in such a way that one will not free memory that the other needs. Use of this function does not negate the need to do this. If this is not done, the application may fail in an unpredictable manner.

Because of all these reasons, it is recommended to never use these APIs.


Probing invalid address

Application Verifier break message

Probing invalid address.

Probable cause

This stop is generated if Application Verifier detects an IsBadXXXPtr call with an invalid address (e.g. a kernel-mode address, instead of a normal user-mode address) for the memory buffer to be probed.

Information displayed by Application Verifier

Parameter1 - Start address

Parameter2 - Memory block size

Parameter3 - Invalid address

Parameter4 - Not used

Description - Probing invalid address

Additional information

Verifier stop code 0603.

To debug this stop look at the current stack trace (kb) and try to determine why the caller of the IsBadXXXPtr function ended up with an invalid address. Many times, the address is plain bogus, e.g. an uninitialized pointer.

MSDN library lists a few reasons why applications should not use the IsBadXXXPtr APIs:

  • In a preemptive multitasking environment, it is possible for some other thread to change the process's access to the memory being tested.

  • Dereferencing potentially invalid pointers can disable stack expansion in there threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information.

  • Threads in a process are expected to cooperate in such a way that one will not free memory that the other needs. Use of this function does not negate the need to do this. If this is not done, the application may fail in an unpredictable manner.

Because of all these reasons, the recommendation is to never use these APIs.


Probing memory block with invalid start address or size

Application Verifier break message

Probing memory block with invalid start address or size.

Probable cause

This stop is generated if Application Verifier detects an IsBadXXXPtr call with an invalid start address (e.g. a kernel-mode address, instead of a normal user-mode address) or invalid size for the memory buffer to be probed.

Information displayed by Application Verifier

Parameter1 - Start address

Parameter2 - Memory block size

Parameter3 - Not used

Parameter4 - Not used

Description - Probing memory block with invalid start address or size

Additional information

Verifier stop code 0607.

To debug this stop look at the current stack trace (kb) and try to determine why the caller of the IsBadXXXPtr function ended up with an invalid address or size. Many times, the address or size are plain bogus, for example un-initialized variables.

MSDN library lists a few reasons why applications should not use the IsBadXXXPtr APIs:

  • In a preemptive multitasking environment, it is possible for some other thread to change the process's access to the memory being tested.

  • Dereferencing potentially invalid pointers can disable stack expansion in there threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information.

  • Threads in a process are expected to cooperate in such a way that one will not free memory that the other needs. Use of this function does not negate the need to do this. If this is not done, the application may fail in an unpredictable manner.

Because of all these reasons, it is recommended to never use these APIs.


Probing null address

Application Verifier break message

Probing null address.

Probable cause

This stop is generated if Application Verifier detects an IsBadXXXPtr call with a NULL address.

Information displayed by Application Verifier

Parameter1 - Not used

Parameter2 - Not used

Parameter3 - Not used

Parameter4 - Not used

Description - Probing null address

Additional information

Verifier stop code 0606.

To debug this stop look at the current stack trace (kb) and try to determine why the caller of the IsBadXXXPtr function ended up with the NULL address. This is typically the sign of someone not checking the return value of one of the memory allocation functions. For example the code below is incorrect:

int main (void)

{

PVOID p;

p = malloc (1024);

Use (p);

return 0;

}

void Use (PVOID p)

{
if (IsBadReadPtr (p)) {

return;

}

//

// p is safe to be used here.

//

}

This code should be re-written as this:

int main (void)

{

PVOID p;

p = malloc (1024);

if (NULL == p)) {

return -1;

}

Use (p);

return 0;

}

void Use (PVOID p)

{

//

// p is safe to be used here.

/

}

MSDN library lists a few reasons why applications should not use the IsBadXXXPtr APIs:

  • In a preemptive multitasking environment, it is possible for some other thread to change the process's access to the memory being tested.

  • Dereferencing potentially invalid pointers can disable stack expansion in there threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information.

  • Threads in a process are expected to cooperate in such a way that one will not free memory that the other needs. Use of this function does not negate the need to do this. If this is not done, the application may fail in an unpredictable manner.

Because of all these reasons, it is recommended to never use these APIs.


Trying to free virtual memory block that is already freed

Application Verifier break message

Trying to free virtual memory block that is already freed.

Probable cause

This stop is generated if Application Verifier detects a VirtualFree for an address that is already free.

Information displayed by Application Verifier

Parameter1 - Memory block address

Parameter2 - not used

Parameter3 - not used

Parameter4 - not used

Description - Trying to free virtual memory block that is already free

Additional information

Verifier stop code 060B.

To debug this stop look at the current stack trace (kb) and try to determine why the memory is already free but the application is trying to free it again. "!avrf -vs -a parameter1" will search for a log of stack traces of the code paths that allocated/freed that address and display these stack traces if they are available. This might show the stack trace that freed up this memory.


Trying to reset NULL address

Application Verifier break message

Trying to reset NULL address.

Probable cause

This stop is generated if Application Verifier detects a VirtualFree (MEM_RESET) call with a NULL first parameter. MEM_RESET should be used only for already allocated memory, so NULL is not a valid first parameter in this case.

Information displayed by Application Verifier

Parameter1 - Not used

Parameter2 - Not used

Parameter3 - Not used

Parameter4 - Not used

Description - Trying to reset NULL address

Additional information

Verifier stop code 0610.


Unexpected exception raised in DLL entry point routine

Application Verifier break message

Unexpected exception raised in DLL entry point routine.

Probable cause

This stop is generated if a DLL's entry point (DllMain) function is raising an exception. One example why this is bad is: if DllMain (DLL_PROCESS_ATTACH) is raising an exception, the Microsoft Windows DLL loader will:

  • Catch and hide the exception

  • Unload the DLL without calling its DllMain(DLL_PROCESS_DETACH).

So in many cases the DLL allocated some resources already, then it raised the exception, and it will not have a chance to release these resources on DllMain (DLL_PROCESS_DETACH).

Information displayed by Application Verifier

Parameter1 - DLL name (use du to dump it)

Parameter2 - Exception record. Use .exr to display it

Parameter3 - Context record. Use .cxr to display it

Parameter4 - Verifier dll descriptor

Description - Unexpected exception raised in DLL entry point routine

Additional information

Verifier stop code 060D.

To debug this stop:

.exr parameter2 - to display the exception information;

.cxr parameter3 followed by kb - to display the exception context information and the stack trace for the time when the exception was raised; parameter4 is the address of an internal verifier structure and doesn't have any significance for most of the verifier users.


Unexpected exception raised in thread function

Application Verifier break message

Unexpected exception raised in thread function.

Probable cause

This stop is generated if a thread function is raising an exception. This is bad because the whole process will be killed.

Information displayed by Application Verifier

Parameter1 - Exception code

Parameter2 - Exception record. Use .exr to display it

Parameter3 - Context record. Use .cxr to display it

Parameter4 - Not used

Description - Unexpected exception raised in thread function

Additional information

Verifier stop code 060E.

To debug this stop:

parameter1 might be significant for the type of exception. For example, an exception code C0000005 means Access Violation;

.exr parameter2 - to display the exception information;

.cxr parameter3 followed by kb - to display the exception context information.


Unexpected exception raised while initializing output buffer

Application Verifier break message

Unexpected exception raised while initializing output buffer.

Probable cause

This stop if an exception is generated while initializing a buffer specified as output parameter for a Microsoft Win32 or CRT API. This typically means that the specified output buffer size is incorrect.

Information displayed by Application Verifier

Parameter1 - Buffer start address

Parameter2 - Buffer size

Parameter3 - Exception record. Use .exr to display it.

Parameter4 - Context record. Use .cxr to display it

Description - Unexpected exception raised while initializing output buffer

Additional information

Verifier stop code 0617.

To debug this stop:

.exr parameter3 - to display the exception information;

.cxr parameter4 followed by kb - to display the exception context information and the stack trace at the time when the exception was raised.


Unexpected exception raised while probing memory

Application Verifier break message

Unexpected exception raised while probing memory.

Probable cause

This stop is generated if there is an exception during an IsBadXXXPtr call. This means that the memory buffer that is being probe doesn't actually have the protection assumed by the caller, or that the memory was freed already, etc.

Information displayed by Application Verifier

Parameter1 - Exception code

Parameter2 - Exception record. Use .exr to display it

Parameter3 - Context record. Use .cxr to display it

Parameter4 - not used

Description - Unexpected exception raised while probing memory

Additional information

Verifier stop code 060F.

See PROBE_INVALID_ADDRESS, PROBE_FREE_MEM, PROBE_GUARD_PAGE, PROBE_NULL, PROBE_INVALID_START_OR_SIZE) for examples of why using the IsBadXXXPtr APIs is not recommended.

To debug this stop:

parameter1 will typically be C0000005 and that means Access Violation;

.exr parameter2 - to display the exception information;

.cxr parameter3 followed by kb - to display the exception context information and stack trace at the time when the exception was raised


Unexpected exception when trying to find heap block size

Application Verifier break message

Unexpected exception when trying to find heap block size.

Probable cause

This stop is generated if there is an exception while calling HeapSize for a heap block that is being freed. This typically means that the specified heap block address is incorrect or the heap is corrupted.

Information displayed by Application Verifier

Parameter1 - Address of the heap block being freed

Parameter2 - Heap handle

Parameter3 - Exception record. Use .exr to display it

Parameter4 - Context record. Use .cxr to display it

Description - Unexpected exception when trying to find heap block size

Additional information

Verifier stop code 0618.

To debug this stop:

.exr parameter3 - to display the exception information;

.cxr parameter4 followed by kb - to display the exception context information and the stack trace at the time when the exception was raised.


Unloading DLL with invalid size or start address

Application Verifier break message

Unloading DLL with invalid size or start address.

Probable cause

This stop is generated if Application Verifier detects a DLL unload with an invalid start address or size of the DLL memory range. This probably means a memory corruption inside the internal ntdll.dll loaded DLL list.

Information displayed by Application Verifier

Parameter1 - DLL memory base address

Parameter2 - DLL memory range size

Parameter3 - DLL name address. Use du to dump it

Parameter4 - Not used

Description - Unloading DLL with invalid size or start address

Additional information

Verifier stop code 0608.


Unmapping memory block with invalid start address

Application Verifier break message

Unmapping memory block with invalid start address.

Probable cause

This stop is generated if the program calls UnmapViewOfFile with an lpBaseAddress parameter that is not identical to the value returned by a previous call to the MapViewOfFile or MapViewOfFileEx function.

Information displayed by Application Verifier

Parameter1 - Address of memory block being unmapped

Parameter2 - Expected correct memory block address

Parameter3 - Not used

Parameter4 - Not used

Description - Unmapping memory block with invalid start address

Additional information

Verifier stop code 061A.

To debug this stop: kb - to display the current stack trace that is calling UnmapViewOfFile. The probable culprit is the DLL that calls UnmapViewOfFile.


Unmapping memory region inside current thread's stack address range

Application Verifier break message

Unmapping memory region inside current thread's stack address range.

Probable cause

This stop is generated if the AppVerifier detects an UnmapViewOfFile, for a block of memory that is actually part of the current thread's stack (!).

Information displayed by Application Verifier

Parameter1 - Allocation base address

Parameter2 - Memory region size

Parameter3 - Stack low limit address

Parameter4 - Stack high limit address

Description - Unmapping memory region inside current thread's stack address range

Additional information

Verifier stop code 0613.

To debug this stop look at the current stack trace (kb) and try to understand why the function that called UnmapViewOfFile thought that the memory block was dynamically allocated or mapped but that was actually memory allocated from the stack.


Code in non-executable memory.

Application Verifier break message

Code in non-executable memory.

Probable cause

This stop is generated if the application is trying to run code from an address that is non-executable or free.

Information displayed by Application Verifier

Parameter1 – Address being accessed

Parameter2 – Code performing invalid access

Parameter3 – Exception record (use .exr to display it)

Parameter4 – Context record (use .cxr to display it)

Description - This stop is generated if the application is trying to run code from an address that is non-executable or free.

To debug this stop:

u parameter2 – to unassembled to culprit code.

.exr parameter3 – to display the exception information

.cxr parameter4 followed by kb – to display the exception context information and the stack trace for the time when the exception was raised.

Additional information

Verifier stop code 061C.


Unexpected exception raised in threadpool callback function.

Application Verifier break message

Unexpected exception raised in threadpool callback function.

Probable cause

This stop is generated if a callback function in the threadpool thread is raising an exception.

Information displayed by Application Verifier

Parameter1 – Exception code

Parameter2 – Exception record (use .exr to display it)

Parameter3 – Context record (use .cxr to display it)

Parameter4 – Not Used

Description - This stop is generated if a callback function in the threadpool thread is raising an exception.

To debug this stop:

Parameter1 might be significant for the type of exception (E.g. and exception code c0000005 means Access Violation).

.exr parameter2 – to display the exception information

.cxr parameter3 followed by kb – to display the exception context information.

Additional information

Verifier stop code 061B.


TLS Stop Details

The TLS checks to ensure that Thread Local Storage APIs are used correctly.

Following is a list of verifier stops that may occur when running the TLS checks against a solution or project on different platforms:

Error message | Stop code
Unloading DLL that allocated TLS index that was not freed | 0350
Corrupted verifier TLS structure | 0351
Using an invalid TLS index | 0352


Unloading DLL that allocated TLS index that was not freed

Application Verifier break message

Unloading DLL that allocated TLS index that was not freed.

Probable cause

This stop is generated if a DLL that allocated a TLS index is being unloaded before freeing that TLS index.

Information displayed by Application Verifier

Parameter1 - TLS index

Parameter2 - Address of the code that allocated this TLS index

Parameter3 - DLL name address. Use du to dump it

Parameter4 - DLL base address

Description - Unloading DLL that allocated TLS index that was not freed

Additional information

Verifier stop code 0350.

To debug this stop:

du parameter3 - display the name of the culprit DLL;

.reload xxx.dll=parameter4 - reload symbols for the culprit DLL (if needed) xxx.dll is the name of the DLL displayed in the above step;

u parameter2 - disassemble the code that allocated the TLS. This should point to the function that allocated the TLS but forgot to free it before the DLL was unloaded.


Using an invalid TLS index

Application Verifier break message

Using an invalid TLS index.

Probable cause

This stop is generated if an invalid TLS index is used. In most cases, it's because code is still using this index when TlsFree is called. Here's an example for the threadpool thread:

T1: Dll loads and TlsAlloc

T1: Queue callback

T1: Shipped waited/canceled callback

T1: TlsFree

T2: Callback runs and calls TlsSetValue

T1: Dll unloads

Information displayed by Application Verifier

Parameter1 - TLS Index

Parameter2 - Stack traces of freeing this TLS index (if applicable). Use dps to dump it.

Parameter3 - Stack trace of creating the threadpool object if not NULL.

Parameter4 - Not used

Description - Using an invalid TLS index

Additional information

Verifier stop code 0352.


Corrupted verifier TLS structure

Application Verifier break message

Corrupted verifier TLS structure.

Probable cause

This stop is generated if the internal verifier structures used to store the state of a TLS slot for a thread are corrupted. This is very likely due to some random corruption in the process.

Information displayed by Application Verifier

Parameter1 – TEB Address

Parameter2 –.Expected TEB Address

Parameter3 – Thread ID

Parameter4 – Expected Thread ID

Description – Corrupted verifier TLS structure.

Additional information

Verifier stop code 0351.


Threadpool Stop Details

The most common mistake made by developers using threadpool is to leave a worker thread in a dirty state after executing a callback function.

The application verifier helps detect these subtle errors, and helps in the development of a robust application.

The verifier hooks into all threadpool APIs that execute a callback (Work, Timer, Wait and I/O). It then substitutes its own contexts and parameter while encapsulating the users original data. The callback is then executed using the original context and parameters. The Verifier then compares the thread state before and after and generates warning and error messages if it differs.

The following state is checked for changes.

  • Thread priority

  • Thread affinity

  • Orphaned critical sections

  • Unclosed window resource

  • Unprocessed messages in queue (window messages, etc)

The Application Verifier also checks for API misuse.

Following is a list of verifier stops that may occur when running the threadpool checks against a solution or project on different platforms:

Error message | Stop code
The priority of this threadpool thread has been changed | 700
The affinity of this threadpool thread has been changed | 701
Unprocessed msg in the msg pool of current thread | 702
Unclosed window belonged to the current thread | 703
ExitThread() called on a threadpool thread | 704
Thread is in impersonation state when it's returned to a threadpool thread. | 705
The parameters for the timer object are inconsistent | 709
A function which requires persistent thread is called within the callback | 706
Thread is in dirty transaction state | 707
This threadpool state has unbalanced CoInit and CoUnInit calls | 708
The loader lock has been held by the threadpool thread within the callback . | 70A
The preferred language is set by the threadpool thread within the callback. | 70B
The background priority is set by the threadpool thread within the callback. | 70C
TerminateThread() called on a threadpool thread | 70D

Properties

One property is available for the Threadpool tests and that is to turn on the AsynchCheck. This will check asynchronous calls that require a persistent thread. The default is turned off. To turn it on, change the Boolean from false to true.


The priority of this threadpool thread has been changed

Application Verifier break message

The priority of this threadpool thread has been changed

Probable cause

This stop is generated if the thread priority is changed when it's returned to thread pool.

Information displayed by Application Verifier

Parameter1 - Callback function where the priority has been changed

Parameter2 - Context

Parameter3 - Threadpool Object allocation stack trace, use dds to dump it.

Parameter4 - Current Priority

Description - This stop is generated if the thread priority is changed when it's returned to thread pool.

Additional information

Verifier stop code 700.


The affinity of this threadpool thread has been changed

Application Verifier break message

The affinity of this threadpool thread has been changed.

Probable cause

This stop is generated if the thread affinity is changed when it's returned to threadpool.

Information displayed by Application Verifier

Parameter1 - Callback function where the affinity has been changed

Parameter2 - Context

Parameter3 - Threadpool Object allocation stack trace, use dds to dump it.

Parameter4 - Current affinity

Description - This stop is generated if the thread affinity is changed when it's returned to threadpool.

Additional information

Verifier stop code 701.


Unprocessed msg in the msg pool of current thread

Application Verifier break message

Unprocessed msg in the msg pool of current thread.

Probable cause

This stop is generated if any message is left as unprocessed when this threadpool thread is returned to the pool. It's dangerous because the message will be processed in a totally different context.

Information displayed by Application Verifier

Parameter1 - Callback function that posted the message

Parameter2 - Context

Parameter3 - Threadpool Object allocation stack trace, use dds to dump it.

Parameter4 - Threadpool thread ID. Use !avrf –tp threadid to see the messages posted to this thread.

Description - This stop is generated if any message is left as unprocessed when this threadpool thread is returned to the pool. It's dangerous since it will be processed in a totally different context. Use !avrf –tp Param4 to see the messages posted to this thread.

Additional information

Verifier stop code 702.

The stack traces for the Post*Message calls are tracked in the thread pool tracker. Please run !avrf -tp <thread_id> to get the stack trace for the Post*Message calls by this thread.

Example: !avrf -tp 0xE58 where 0xE58 is the thread id of the thread that ran into the verifier stop.


Unclosed window belonged to the current thread

Application Verifier break message

Unclosed window belonged to the current thread.

Probable cause

This stop is generated if any window is kept live when this threadpool thread is returned to the pool.

Information displayed by Application Verifier

Parameter1 - Callback function

Parameter2 - Context

Parameter3 - Threadpool Object allocation stack trace, use dds to dump it.

Parameter4 – Threadpool thread ID.

Description - This stop is generated if any window kept live when this threadpool thread is returned to the pool.

Additional information

Verifier stop code 703.


ExitThread() called on a threadpool thread

Application Verifier break message

ExitThread() called on a threadpool thread

Probable cause

This stop is generated if ExitThread is called on a threadpool thread. Calling ExitThread on a threadpool thread makes the system unstable and can cause a resource leak, a hang, or an access violation.

Information displayed by Application Verifier

Parameter1 - Callback function

Parameter2 - Context

Parameter3 - Threadpool Object allocation stack trace, use dds to dump it.

Parameter4 - Not used

Additional information

Verifier stop code 704.


Thread is in impersonation state when it's returned to a threadpool thread.

Application Verifier break message

Thread is in impersonation state when it's returned to a threadpool thread.

Probable cause

This stop is generated if call back function change the thread token to impersonate another user and forgot to reset it before returning it back to the threadpool.

Information displayed by Application Verifier

Parameter1 - Callback function where the thread was impersonated

Parameter2 - Context

Parameter3 - Threadpool Object allocation stack trace, use dds to dump it.

Parameter4 - Not used

Description - This stop is generated if call back function change the thread token to impersonate another user and forgot to reset it before returning it back to the threadpool.

Additional information

Verifier stop code 705.


A function which requires persistent thread is called within the callback

Application Verifier break message

A function which requires persistent thread is called within the callback.

Probable cause

Some Microsoft Windows APIs need to be called inside a dedicated or persistent thread. In the threadpool you should generally avoid using thread local storage and queuing asynchronous calls that require a persistent thread, such as the RegNotifyChangeKeyValue function. However, such functions can be queued to a persistent worker thread using QueueUserWorkItem with the WT_EXECUTEINPERSISTENTTHREAD option. A kb in debugger will reveal the caller.

Information displayed by Application Verifier

Parameter1 - Callback function

Parameter2 - Context

Parameter3 - Threadpool Object allocation stack trace, use dds to dump it.

Parameter4 - Not used

Description - Some Microsoft Windows APIs need to be called inside a dedicated or persistent thread. In the threadpool you should generally avoid using thread local storage and queuing asynchronous calls that require a persistent thread, such as the RegNotifyChangeKeyValue function. However, such functions can be queued to a persistent worker thread using QueueUserWorkItem with the WT_EXECUTEINPERSISTENTTHREAD option. A kb in debugger will reveal the caller.

Additional information

Verifier stop code 706.


Thread is in dirty transaction state

Application Verifier break message

Thread is in dirty transaction state.

Probable cause

This stop is generated if call back function forgot to close or reset the current transaction handle.

Information displayed by Application Verifier

Parameter1 - Callback function where the transaction context was changed

Parameter2 - Context

Parameter3 - Threadpool Object allocation stack trace, use dds to dump it.

Parameter4 - Not used

Description - This stop is generated if call back function forgot to close or reset the current transaction handle.

Additional information

Verifier stop code 707.

This stop will only appear in Microsoft Windows Vista.


This threadpool state has unbalanced CoInit and CoUnInit calls

Application Verifier break message

This threadpool state has unbalanced CoInit and CoUnInit calls.

Probable cause

This stop is generated if call back function calls CoInit and CoUnInit unbalanced.

Information displayed by Application Verifier

Parameter1 - Callback function that left the thread in a dirty com state

Parameter2 - Context

Parameter3 - Threadpool Object allocation stack trace, use dds to dump it.

Parameter4 - Balanced call counts

Description - This stop is generated if call back function calls CoInit and CoUnInit unbalanced.

Additional information

Verifier stop code 708.


The parameters for the timer object are inconsistent

.

Application Verifier break message

The parameters for the timer object are inconsistent. Period should be 0 when WT_EXECUTEONLYONCE is specified when creating the timer.

Probable cause

Application Verifier generates this stop if the parameters for the timer object are inconsistent. The Period to signal the timer is not zero when the timer is set to signal only once with the WT_EXECUTEONLYONCE flag.

Information displayed by Application Verifier

The parameters for the timer object are inconsistent. Period should be 0 when WT_EXECUTEONLYONCE is specified when creating the timer.

Parameter 1 – Period specified

Parameter 2 – Flags specified

Parameter 3 – Not used

Parameter 4 – Not used

Additional information

Verifier stop code 709.


The loader lock has been held by the threadpool thread within the callback .

Application Verifier break message

The loader lock has been held by the threadpool thread within the callback.

Probable cause

The stop is generated if the loader lock is held within the callback and is not released when the thread is returned to the threadpool.

Information displayed by Application Verifier

The loader lock has been held by the threadpool thread within the callback.

Parameter 1 – Callback function

Parameter 2 – Context

Parameter 3 –Threadpool object allocation stack trace, use ‘dps’ to dump it.

Parameter 4 – Not used

Additional information

Verifier stop code 70A.


The preferred language is set by the threadpool thread within the callback.

Application Verifier break message

The preferred language is set by the threadpool thread within the callback.

Probable cause

The stop is generated if the preferred language is set within the callback and is not cleared when the thread is returned to the threadpool.

Information displayed by Application Verifier

The preferred language is set by the threadpool thread within the callback.

Parameter 1 – Callback function

Parameter 2 – Context

Parameter 3 –Threadpool object allocation stack trace, use ‘dps’ to dump it.

Parameter 4 – Not used

Additional information

Verifier stop code 70B.


The background priority is set by the threadpool thread within the callback.

Application Verifier break message

The background priority is set by the threadpool thread within the callback.

Probable cause

The stop is generated if the background priority is set within the callback and is not disabled when the thread is returned to the threadpool.

Information displayed by Application Verifier

The background priority is set by the threadpool thread within the callback.

Parameter 1 – Callback function

Parameter 2 – Context

Parameter 3 –Threadpool object allocation stack trace, use ‘dps’ to dump it.

Parameter 4 – Not used

Additional information

Verifier stop code 70C.


TerminateThread() called on a threadpool thread

Application Verifier break message

TerminateThread() called on a threadpool thread.

Probable cause

This stop is generated if TerminateThread is called on a threadpool thread. Calling TerminateThread on a threadpool thread makes the system unstable and can cause a resource leak, a hang, or an access violation.

Information displayed by Application Verifier

Parameter1 – Not used

Parameter2 – Not used

Parameter3 – Not used.

Parameter4 - Not used

Additional information

Verifier stop code 70D.


Compatibility Stops

High Version Lie Stop

These Version Handling stops identify problems responsible for some of the most common application compatibility issues in Windows. Improperly detecting the version of the operating system or using hard-coded version information can cause the application to fail on newer operating systems.


File Paths Stop Details

The File Path stops, which were available in earlier versions of Application Verifier, are no longer supported.


High Version Lie Stop Details

The Version Lie tests identify problems responsible for some of the most common application compatibility issues in Windows. Improperly detecting the version of the Microsoft Windows operating system or using hard-coded version information can cause the application to fail when the operating system is upgraded.

Properties

  • Major version

  • This is the major version of the Windows OS. The default value used for the check is current major version + 2. If the value is changed by the user, the check is done against the value provided. The property can be provided as a DWORD or HEX value.

  • Minor version

  • This is the minor version of the Windows OS. The default value used for the check is current minor version + 2. If the value is changed by the user, the check is done against the value provided. The property can be provided as a DWORD or HEX value.

  • Build number

  • This is the build number associated with the OS version. The default value used for the check is current minor version + 1000. If the value is changed by the user, the check is done against the value provided. The property can be provided as a DWORD or HEX value.

  • Service pack major

  • This is the major version of the service pack applied to the OS. The default value used for the check is 0 and no check is done by default. If the value is changed by the user, the check is done against the value provided. The property can be provided as a DWORD or HEX value.

  • Service pack minor

  • This is the minor version of the service pack applied to the OS. The default value used for the check is 0 and no check is done by default. If the value is changed by the user, the check is done against the value provided. The property can be provided as a DWORD or HEX value.

  • Suite mask

  • This is the product suite for the Windows OS (example: Professional, Home, Business, and Ultimate etc.) The default value used for the check is 0 and no check is done by default. If the value is changed by the user, the check is done against the value provided. The property can be provided as a DWORD or HEX value.

  • Product type

  • The default value used for the check is 0 and no check is done by default. If the value is changed by the user, the check is done against the value provided. The property can be provided as a DWORD or HEX value.

  • CSD version

  • The default value used for the check is NULL and no check is done by default. If the value is changed by the user, the check is done against the value provided. The property should be provided as a STRING value.

Additional information

The primary purpose of the HighVersionLie test is to ensure that applications that run on Windows Vista run correctly as future versions of Windows are released. This test is not intended for internal system components or applications that ship with the operating system. Running this test on these components causes unforeseen results as these components expect a certain version to be returned. This test is designed for applications that perform version checking and respond based on the operating system version information returned.

You can configure this test to provide the major version, minor version, and build number that you want returned to the application.

This test records all calls to the GetVersion and GetVersionEx APIs.

A debugger is not required to gain information from this test.

Error | Stop Code
Called the GetVersionEx API | 2200, 2201, 2202, 2203
Called the GetVersion API | 2204


Called the GetVersionEx API

Application Verifier break message

Called the GetVersionEx API.

Probable cause

The application called the GetVersionEx API. This is an informational message; no action is required.

Information displayed by Application Verifier

Returned %lu.%lu build number: %lu.

Returned %lu.%lu build number: %lu, CSD version: %ls.

Returned %lu.%lu build number: %lu, service pack: %lu.%lu, suite mask: 0x%08X, product type: %hs.

Returned %lu.%lu build number: %lu, service pack: %lu.%lu, suite mask: 0x%08X, product type: %hs, CSD version: %ls

Returned %lu.%lu build number: %lu.

Additional information

Verifier stop code 2200, 2201, 2202, 2203.


HighVersionLie - Checks Version Handling

These Version Handling stops identify problems responsible for some of the most common application compatibility issues in Microsoft Windows operating System. Improperly detecting the version of the operating system or using hard-coded version information can cause the application to fail on newer operating systems.

Application Verifier break message

This stop is not a verifier break. This is a warning stop only. It indicates that one of the GetVersion APIs were used to check the OS version.

Probable cause

The application checks OS version and may fail if the version number is higher than expected.


Called the GetVersion API

Application Verifier break message

Called the GetVersion API.

Probable cause

The application called the GetVersion API. This is an informational message; no action is required.

Information displayed by Application Verifier

Returned %lu.%lu build number: %lu.

Returned %lu.%lu build number: %lu, CSD version: %ls.

Returned %lu.%lu build number: %lu, service pack: %lu.%lu, suite mask: 0x%08X, product type: %hs.

Returned %lu.%lu build number: %lu, service pack: %lu.%lu, suite mask: 0x%08X, product type: %hs, CSD version: %ls

Returned %lu.%lu build number: %lu.

Additional information

Verifier stop code 2204.


Interactive Services Stop Details

The Interactive Services stops, which were available in earlier versions of Application Verifier, are no longer supported.


Kernel-mode Driver Install Stop Details

The Kernel-mode Driver Install stops, which were available in earlier versions of Application Verifier, are no longer supported.


Low Resource Simulation Stops

Low resource simulation (also known as fault injection) tries to simulate an environment under low resources, for example out of memory. This will identify bug within low memory conditions.

Properties

To edit the properties, check the Low Resource Simulation check box in the Tests area, right click, and select properties:

  • Include – Limit faults happens only in the specified dlls. One dll name without path per row. If '*' is specified, faults will happen for all the modules.

  • Exclude – Exclude faults for the specified modules. One dll name without path per row.

  • Timeout – Give a time slot (in millisecond) when there is no fault at process initialization.

  • Wait – A number [0 – 1000000] that indicates the fault probability for the WaitForXXXX API.

  • Heap_Alloc - A number [0 – 1000000] that indicates the fault probability for the Heap Allocation API.

  • Virtual_Alloc - A number [0 – 1000000] that indicates the fault probability for the Virtual Memory allocation API.

  • Registry - A number [0 – 1000000] that indicates the fault probability for the Registry API.

  • File- A number [0 – 1000000] that indicates the fault probability for the File API such as CreateFile.

  • Event - A number [0 – 1000000] that indicates the fault probability for the Event API such as CreateEvent

  • MapView - A number [0 – 1000000] that indicates the fault probability for the MapView API such as CreateMapView.

  • Ole_Alloc - A number [0 – 1000000] that indicates the fault probability for the Ole API such as SysAllocString.

  • Stacks - Each Microsoft Windows application thread starts with a stack reserve and a stack commit size. Under normal usage, the stack commit grows whenever there is need for more space on the stack. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createthread.asp and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/thread_stack_size.asp for more information.

    If the system is experiencing low memory conditions, the stack commit growth might fail. The thread that fails to grow its stack and the whole application will most likely crash. That kind of crash is unacceptable for important system processes (e.g. for services). The Stacks check will disable any the stack growth for the application that is being verified so it will simulate the stack growth failures without the need to simulate the whole system low memory conditions.

  • Exceptions will be thrown when the application tries to expand the stack. No verifier stops are generated by this.


Miscellaneous Stops

The Miscellaneous verification layer consists of two checks:

  1. Dirty Stacks Stop Details: When this check is enabled, the verifier will fill [periodically] the unused portion of the stack with a memory pattern. This can help detect uninitialized variables in future function calls in that thread’s context. For example, if a future function allocates a pointer variable on the stack but forgets to initialize it:

    • Without the verifier there is a chance that the pointer will happen to be NULL and the function will handle it (bug goes undetected);

    • With the verifier, the pointer will be initialized with the verifier memory pattern and will likely AV when trying to use that pointer (bug identified).

  2. Dangerous APIs Stop Details: Detect the dangerous API usage such as calling TerminateProcess/TerminateThread or calling LoadLibary within DllMain.

  3. Time Rollover: This test forces the GetTickCount and TimeGetTime APIs to roll over faster than they normally would. This allows applications to test their handling of time rollover more easily.


Dangerous APIs Stop Details

The Dangerous API Verifier checks to see whether the application is using unsafe APIs (e.g. TerminateThread).

The following list contains the verifier stops that may occur when running the Dangerous API verifier against a solution or project.

Error message | Stop code
Dangerous call to TerminateThread | 0100
Potential stack overflow in low memory conditions | 0101
Exit process called while multiple threads still running | 0102
LoadLibrary is called during DllMain | 0103
FreeLibrary is called during DllMain | 0104
SetProcessWorkingSetSize is called with MinimumWorkingSetSize = 0xFFFFFFFF | 0105
SetProcessWorkingSetSize is called with MaximumWorkingSetSize = 0xFFFFFFFF | 0106
SetProcessWorkingSetSizeEx is called with MinimumWorkingSetSize = 0xFFFFFFFF | 0107
SetProcessWorkingSetSizeEx is called with MaximumWorkingSetSize = 0xFFFFFFFF | 0108

Properties

Dangerous APIs check has one property that can be altered:

  • DllMainCheck - Check LoadLibrary/FreeLibrary calling when DllMain is active.


Dangerous call to TerminateThread

Application Verifier break message

Dangerous call to TerminateThread.

Probable cause

This stop is generated if a thread (thread ID is parameter1) is terminated explicitly using TerminateThread(). This function is very dangerous because it introduce data corruption and deadlocks (as per MSDN).

Information displayed by Application Verifier

Paramater1 - Thread ID for the caller of Terminatethread()

Paramater2 - Not used

Parameter3 - Not used

Parameter4 - Not used

Description - Dangerous call to TerminateThread

Additional information

Verifier stop code 0100.


Potential stack overflow in low memory conditions

Application Verifier break message

Potential stack overflow in low memory conditions.

Probable cause

This stop is generated if the initial stack commit size of a thread is such that a stack overflow can be raised in low memory conditions if the stack cannot be extended.

Information displayed by Application Verifier

Parameter 1 - Not used

Parameter 2 - Not used

Parameter 3 - Not used

Parameter 4 - Not used

Additional information

Verifier stop code 0101.


Exit process called while multiple threads still running

Application Verifier break message

ExitProcess called while multiple threads still running.

Probable cause

This stop is generated if a thread calls ExitProcess while there are several threads running. In such a case, TerminateThread is called for each thread and this can create deadlocks or data corruptions.

Information displayed by Application Verifier

Paramater 1 - Number of threads running

Paramater 2 - Not used

Parameter 3 - Not used

Parameter 4 - Not used

Additional information

Verifier stop code 0102.


LoadLibrary is called during DllMain

Application Verifier break message

LoadLibrary is called during DllMain.

Probable cause

This stop is generated if the code inside DllMain calls LoadLibrary or FreeLibrary. It’s the behavior forbidden by MSDN.

Information displayed by Application Verifier

Parameter1 - Dll Name (use du to dump)

Parameter2 - Dll base address

Parameter3 - Not used

Parameter4 - Not used

Description - LoadLibrary is called during DllMain

Additional information

Verifier stop code 0103.


FreeLibrary is called during DllMain

Application Verifier break message

FreeLibrary is called during DllMain.

Probable cause

This stop is generated if the code inside DllMain calls LoadLibrary or FreeLibrary. It’s the behavior forbidden by MSDN.

Information displayed by Application Verifier

Parameter1 - Dll Name (use du to dump)

Parameter2 - Dll base address

Parameter3 - Not used

Parameter4 - Not used

Additional information

Verifier stop code 0104.


SetProcessWorkingSetSize is called with MinimumWorkingSetSize = 0xFFFFFFFF

Application Verifier break message

SetProcessWorkingSetSize is called with MinimumWorkingSetSize = 0xFFFFFFFF.

Probable cause

This stop is generated if SetProcessWorkingSetSize is called with the dwMinimumWorkingSetSize parameter set to 0xFFFFFFFF. The correct value for dwMinimumWorkingSetSize is (SIZE_T)(-1).

Information displayed by Application Verifier

Parameter 1 - Not used

Parameter 2 - Not used

Parameter 3 - Not used

Parameter 4 - Not used

Additional information

Verifier stop code 0105.


SetProcessWorkingSetSize is called with MaximumWorkingSetSize = 0xFFFFFFFF

Application Verifier break message

SetProcessWorkingSetSize is called with MaximumWorkingSetSize = 0xFFFFFFFF.

Probable cause

This stop is generated if SetProcessWorkingSetSize is called with the dwMaximumWorkingSetSize parameter set to 0xFFFFFFFF. The correct value for dwMaximumWorkingSetSize is (SIZE_T)(-1).

Information displayed by Application Verifier

Parameter 1 - Not used

Parameter 2 - Not used

Parameter 3 - Not used

Parameter 4 - Not used

Additional information

Verifier stop code 0106.


SetProcessWorkingSetSizeEx is called with MinimumWorkingSetSize = 0xFFFFFFFF

Application Verifier break message

SetProcessWorkingSetSizeEx is called with MinimumWorkingSetSize = 0xFFFFFFFF.

Probable cause

This stop is generated if SetProcessWorkingSetSizeEx is called with the dwMinimumWorkingSetSize parameter set to 0xFFFFFFFF. The correct value for dwMinimumWorkingSetSize is (SIZE_T)(-1).

Information displayed by Application Verifier

Parameter 1 - Not used

Parameter 2 - Not used

Parameter 3 - Not used

Parameter 4 - Not used

Additional information

Verifier stop code 0107.


SetProcessWorkingSetSizeEx is called with MaximumWorkingSetSize = 0xFFFFFFFF

Application Verifier break message

SetProcessWorkingSetSizeEx is called with MaximumWorkingSetSize = 0xFFFFFFFF.

Probable cause

This stop is generated if SetProcessWorkingSetSizeEx is called with the dwMaximumWorkingSetSize parameter set to 0xFFFFFFFF. The correct value for dwMaximumWorkingSetSize is (SIZE_T)(-1).

Information displayed by Application Verifier

Parameter 1 - Not used

Parameter 2 - Not used

Parameter 3 - Not used

Parameter 4 - Not used

Additional information

Verifier stop code 0108.


Dirty Stacks Stop Details

When the Dirty Stacks are enabled, the verifier will fill [periodically] the unused portion of the stack with a memory pattern. This can help detect uninitialized variables in future function calls in that thread's context. For example, if a future function allocates a pointer variable on the stack but forgets to initial it:

  • Without the verifier there is a chance that the pointer will happen to be NULL and the function will handle it and the bug goes undectected.

  • With the verifier, the pointer will be initialized with the verifier memory pattern and will AV when trying to use that pointer.

  • No stops are provided by this set of tests, only exceptions.


Time Rollover

This test forces the GetTickCount and TimeGetTime APIs to roll over faster than they normally would. This allows applications to test their handling of time rollover more easily. This test does not generate any stops.


Limited User Account Predictor Stops

The Limited User Account Privilege Predictor (LuaPriv) has two primary goals:

  1. Predictive: While running an application with administrative privilege, predict whether that application would work as well if run with less privilege (generally, as a normal user).

    For example, if the application writes to files that only allow members of the Administrators group access, then that application will not be able to write to the same file if run as a non-administrator.

  2. Diagnostic: When running as a non-administrator, identify potential problems that may already exist with the current run.

    Continuing the previous example, if the application tries to write to a file that only grants members of the Administrators group access, the application will get an ACCESS_DENIED error. If the application does not operate correctly, this operation may be the culprit.


Access Restricted

Application Verifier break message

Access was restricted to trusted users only.

Probable cause

The application opened an object (such as a file or registry key) and requested access permissions that were granted solely to trusted users. This indicates that untrusted users will have difficulty running the application correctly.

Information displayed by Application Verifier

%hs (%hs) %ws only grants requested %hs to %ws.

Verifier stop code

ID: RESTRICTED_RIGHT

Code: 0x331B

Error level

Error


Called GetTokenInfo

Application Verifier break message

The application called the GetTokenInformation function.

Probable cause

The application called the GetTokenInformation function and requested the listed class of information. This will work as a standard user, but it generally indicates that the application expects to be run by an administrator and is examining the access token to determine this.

Information displayed by Application Verifier

Called GetTokenInformation, requesting %hs.

Verifier stop code

ID: GETTOKENINFO

Code: 0x330C

Error level

Warning


Cannot canonicalize privilege

Application Verifier break message

Cannot find the canonical name for a privilege.

Probable cause

This privilege probably does not exist on your version of the Microsoft Windows operating system. This break message is no cause for concern and is purely diagnostic information.

Information displayed by Application Verifier

Could not determine %ws's displayname (error 0x%x).

Verifier stop code

ID: UNKNOWN_PRIVILEGE

Code: 0x330D

Error level

Information


Could not interpret HKEY_CURRENT_USER

Application Verifier break message

Could not interpret HKEY_CURRENT_USER.

Probable cause

The Verifier was unable to interpret HKEY_CURRENT_USER in the way it was listed. Without knowing the canonical path to HKCU, registry keys there may be inappropriately flagged as restrictive by the Verifier.

Information displayed by Application Verifier

The Verifier was unable to interpret HKEY_CURRENT_USER in the way listed. Without knowing the canonical path to HKCU, registry keys there may be inappropriately flagged as restrictive by the Verifier.

Verifier stop code

ID: BADHKCU

Code: 0x3303

Error level

Warning


Could not open an object's parent

Application Verifier break message

The Verifier could not open an object's parent.

Probable cause

The Verifier was unable to open the parent of the given object (to determine whether standard users would be able to create child objects). As a result, the parent has not been analyzed.

Information displayed by Application Verifier

Could not open %hs %ws to validate call to %hs (%ws). Error 0x%x.

Verifier stop code

ID: CANT_OPEN_PARENT

Code: 0x3309

Error level

Warning


Could not open an object

Application Verifier break message

The Verifier could not open an object.

Probable cause

The Verifier tried unsuccessfully to open an object to obtain information from it. The object was not analyzed.

Information displayed by Application Verifier

Cannot open %hs %ws for %hs (error 0x%x).

Verifier stop code

ID: CANTOPEN_NONCRITICAL

Code: 0x3302

Error level

Warning


Could not parse an INI file mapping

Application Verifier break message

The Verifier could not parse an INI file mapping.

Probable cause

The application used an INI file that was mapped to a registry key by the system. While parsing the structure of that INI file mapping, the Verifier encountered unknown syntax. The API call has not been checked.

Information displayed by Application Verifier

Don't understand the '%ws' in '%ws' -- unknown INI file mapping prefix.

Verifier stop code

ID: UNKNOWN_MAPPING

Code: 0x3315

Error level

Warning


Could not query registry value

Application Verifier break message

The Verifier could not query a registry value.

Probable cause

The Verifier tried unsuccessfully to query a registry value.

Information displayed by Application Verifier

Could not query value %ws: 0x%x.

Verifier stop code

ID: CANT_QUERY_VALUE

Code: 0x3314

Error level

Warning


Couldn't get parent directory

Application Verifier break message

The Verifier could not find the parent directory.

Probable cause

The Verifier attempted to determine where a file or directory resided, but an error prevented this.

Information displayed by Application Verifier

%hs: Could not canonicalize %ws (error 0x%x)

Verifier stop code

ID: CANTGETPARENT

Code: 0x3308

Error level

Warning


Deny ACE encountered

Application Verifier break message

Deny Access Control Entry (ACE) encountered.

Probable cause

The application opened an object (such as a file or registry key) and requested access that was explicitly denied to one or more entities. Depending on who is denied access, this might prevent access by less-privileged users.

Information displayed by Application Verifier

%hs: %ws denies %hs to %ws.

Verifier stop code

ID: DENY_ACE

Code: 0x331A

Error level

Warning


Denied access to object

Application Verifier break message

The application was denied access to an object.

Probable cause

The application was denied access to the given profile section due to insufficient privilege. If the application's functionality is imparied, this access problem may be the cause.

Information displayed by Application Verifier

%hs: Denied access to profile %ws (error 0x%x).

Verifier stop code

ID: INI_PROFILE_ACCESS_DENIED

Code: 0x3316

Error level

Warning


Failed to enable a non-security-relevant privilege

Application Verifier break message

Failed to enable a non-security-relevant privilege.

Probable cause

The application requested the listed privilege unsuccessfully. Although this privilege is not security-relevant (E.G. a standard user might have the privilege), this could be indicative of administrative privilege requirements in the application. In this case, the application may generate excessive audit traffic or its functionality may be impaired.

Information displayed by Application Verifier

Could not enable %ws (the '%ws' privilege) with %hs.

Verifier stop code

ID: IRRELEVANT_PRIVILEGE_DENIED

Code: 0x3312

Error level

Warning


Granted access to object

Application Verifier break message

The application was granted access to an object.

Probable cause

The application was granted access to the given profile section. The profile section has not yet been analyzed for security relevance. This message is for debugging purposes only.

Information displayed by Application Verifier

%hs: Granted access to profile %ws.

Verifier stop code

ID: INI_PROFILE_ACCESS_GRANTED

Code: 0x3325

Error level

Information


Inaccessible Object

Application Verifier break message

Inaccessible object.

Probable cause

The application opened an object (such as a file or registry key) that grants no explicit access to anyone. Barring administrative intervention (such as SE_TAKEOWNERSHIP_PRIVILEGE or SE_BACKUP_PRIVILEGE), the operation being performed by the application should never succeed. Therefore, what the application is doing will not work for standard users.

Information displayed by Application Verifier

%hs (%ws)'s DACL allows no access by anyone.

Verifier stop code

ID: EMPTY_DACL

Code: 0x331F

Error level

Error


Initialization Failed

Application Verifier break message

Initialization failed.

Probable cause

The USERPROFILE environment variable could not be found. Because of this, the current user's profile could not be identified and opened; therefore, the Verifier might falsely identify some files and/or directories as being excessively restrictive.

Information displayed by Application Verifier

The USERPROFILE environment variable could not be found.

Verifier stop code

ID: NO_USERPROFILE

Code: 0x3304

Error level

Warning


Object opened/created in restricted namespace

Application Verifier break message

Object opened/created in a restricted namespace.

Probable cause

This object was found in the listed namespace, which is not writable by standard users. Use the Local\ prefix for standard user account compliance.

Information displayed by Application Verifier

%hs: %hs %ws is in restricted namespace %ws.

Verifier stop code

ID: RESTRICTED_NAMESPACE

Code: 0x3306

Error level

Error


Object's Security Descriptor

Application Verifier break message

The application was able to access the object's security descriptor.

Probable cause

The application was granted the requested access to this object. A standard user should also be able to access this object.

Information displayed by Application Verifier

%hs (%ws, access 0x%x) is okay (%hs)

Verifier stop code

ID: OK_OBJECT_DUMP

Code: 0x3317

Error level

Information


Missing part of a security descriptor

Application Verifier break message

Part of a security descriptor is missing.

Probable cause

The Verifier attempted to analyze the object's security descriptor, but received an unexpected error when attempting to break it into pieces for scrutiny. This may suggest that the object's security descriptor could be invalid.

Information displayed by Application Verifier

Could not query %hs (%ws)'s %hs: 0x%x.

Verifier stop code

ID: MISSING_PIECE

Code: 0x3320

Error level

Warning


Object opened/created without a namespace

Application Verifier break message

Object opened/created without a namespace.

Probable cause

This object was created without a namespace, which can cause it to be created in Session\ or Global\, depending on whether Terminal Server is used. Use the Local\ prefix for standard user account compliance. Note: In Windows Vista, the object will be created in the Local\ namespace.

Information displayed by Application Verifier

%hs: %hs %ws has no namespace.

Verifier stop code

ID: NO_NAMESPACE

Code: 0x3307

Error level

Error


Okay Object

Application Verifier break message

Okay object.

Probable cause

The Verifier assumed that this object was inherently 'safe' due to its location.

Information displayed by Application Verifier

%hs: %hs %ws look okay because it exists in %ws

Verifier stop code

ID: OK_OBJECT_PREFIX

Code: 0x3305

Error level

Information


Privilege could not be looked up

Application Verifier break message

The Verifier could not look up the privilege.

Probable cause

The Verifier was prevented from looking up the name of the privilege with the listed LUID. This will prevent the Verifier from producing certain diagnostics.

Information displayed by Application Verifier

Could not determine name of privilege for %hs (error 0x%x).

Verifier stop code

ID: PRIV_LOOKUP_FAILED

Code: 0x330E

Error level

Warning


Requested a security-relevant privilege

Application Verifier break message

Requested a security-relevant privilege.

Probable cause

The application requested (and received) the listed privilege, which is not granted to standard users. This API call will fail as a standard user account, which may have performance and audit implications in addition to having an impact on the functionality of the application.

Information displayed by Application Verifier

Requested %ws%hs%ws%hs with %hs successfully.

Verifier stop code

ID: USED_PRIVILEGE_LUID

Code: 0x330F

Error level

Error


Requested MAXIMUM_ALLOWED access

Application Verifier break message

The application requested MAXIMUM_ALLOWED access.

Probable cause

The application requested MAXIMUM_ALLOWED access to an object (such as a file or registry key). Because of this, the open function will always succeed, even if no permission is actually granted to the user. This is unacceptable programming practice. In addition, the Verifier cannot authoritatively determine what rights the application actually needs in order to operate. The Verifier has attempted to analyze the application as if all access privileges granted were actually required, which may cause false-positives.

Information displayed by Application Verifier

Opened %hs %ws with %hs for 0x%x (%hsMAXIMUM_ALLOWED), was granted 0x%x access.

Verifier stop code

ID: MAXIMUM_ALLOWED

Code: 0x3322

Error level

Warning


Restricted to Owner

Application Verifier break message

Access is restricted solely to the owner.

Probable cause

The application opened an object (such as a file or registry key) and requested access that is granted to privileged entities AND TO THE OWNER. The owner is also currently privileged, suggesting that this object will not be accessible by unprivileged entities.

Information displayed by Application Verifier

%hs (%hs) %ws grants %hs to Creator/Owner. The current owner is %ws.

Verifier stop code

ID: CREATOR_OWNER

Code: 0x331D

Error level

Error


Running with Privilege

Application Verifier break message

The application is running with privilege.

Probable cause

The verifier discovered that the application was being run by an administrative user. This may be already known, but when intentionally running as a standard user, the user account should not be a member of the listed group.

Information displayed by Application Verifier

Running as a user in privileged group %ws

Additional information

ID: NON_LUA_USER

Code: 0x330A

Error level

Information


Safe Object

Application Verifier break message

Safe object.

Probable cause

The application opened an object (such as a file or registry key) and requested access that is granted to at least one non-privileged entity (listed). This suggests that the same operation will work when attempted by non-privileged/standard users.

Information displayed by Application Verifier

%hs (%ws) looks okay because it grants to %ws.

Verifier stop code

ID: OK_OBJECT_GRANT

Code: 0x331E

Error level

Information


Sid conversion failed

Application Verifier break message

SID conversion failed.

Probable cause

The Verifier failed to convert a static (configuration) Security Identifier (SID) from the human-readable form to the form usable by the Microsoft Windows operating system.

Information displayed by Application Verifier

Failed to convert %hs to sid. Error 0x%x.

Verifier stop code

ID: STRING2SID_FAILED

Code: 0x330B

Error level

Warning


Skipped unknown permissions

Application Verifier break message

Skipped unknown permissions.

Probable cause

The application requested permissions that are unknown to the Verifier. Lacking context, the Predictor cannot currently diagnose problems relating to these access bits.

Information displayed by Application Verifier

Did not check unknown permissions 0x%x on %hs %ws.

Verifier stop code

ID: UNKNOWN_PERMS

Code: 0x3324

Error level

Warning


The Verifier could not get an object's name

Application Verifier break message

The Verifier could not get an object's name.

Probable cause

The Verifier attempted to canonicalize the name of an object opened by the application, but was unable to do so. This indicates that some diagnostic information may be missing from reports of security issues.

Information displayed by Application Verifier

Unable to query the object's name: 0x%x.

Verifier stop code

ID: CANNOTQUERYOBJECT

Code: 0x3300

Error level

Warning


The Verifier could not get an object's path name.

Application Verifier break message

The Verifier could not get an object's path name.

Probable cause

The Verifier could not find the canonical path to the object. As a result, the object's name will probably be incomplete. This may make it difficult to locate the source of any problems the Predictor does find.

Information displayed by Application Verifier

Could not get %hs from pathname %ws due to error 0x%x.

Verifier stop code

ID: CANTCANONICALIZEPATH

Code: 0x3301

Error level

Warning


Unable to display Security Descriptor

Application Verifier break message

Unable to display a security descriptor.

Probable cause

The Verifier attempted to display a security descriptor, but could not render it into human-readable form. This is probably due to low memory, but could be the result of a non-standard security descriptor.

Information displayed by Application Verifier

Could not convert %hs %ws's security descriptor to text: 0x%x.

Verifier stop code

ID: SD2TEXT

Code: 0x3319

Error level

Warning


Verifier requested unknown MAXIMUM_ALLLOWED access

Application Verifier break message

The application requested MAXIMUM_ALLOWED access.

Probable causes

The application requested MAXIMUM_ALLOWED access to an object (such as a file or registry key). Because of this, the open function will always succeed, even if no permission is actually granted to the user. This is unacceptable programming practice. In addition, the Verifier cannot authoritatively determine what rights the application actually needs in order to operate. The Verifier has attempted to determine what rights might have been granted to the application by the object, but failed to do so.

Information displayed by Application Verifier

%hs: Openned (%ws) with '%hs' for 0x%x (%hsMAXIMUM_ALLOWED), but granted access could not be determined due to error 0x%x. The object should be checked manually.

Stop code

ID: UNKNOWN_MAXIMUM_ALLOWED

Code: 0x3323

Error level

Warning


The application performed a hard administrator check

Application Verifier break message

The application performed a hard administrator check.

Probable cause

The application asked the operating system whether the listed SID was present in the user's access token. The SID corresponds to a privileged entity; this means that the application performs somewhat differently if the user is a member of the listed group (usually, administrators).

Information displayed by Application Verifier

Called CheckTokenMembership against trusted entity %ws (%hs).

Verifier stop code

ID: CHECKTOKENMEMBERSHIP_TRUSTED

Code: 0x3326

Error level

Error


The application called CheckTokenMembership

Application Verifier break message

The application called CheckTokenMembership.

Probable cause

The application asked the operating system whether the listed SID was present in the user's access token. The SID was not identifiable as a trusted entity, so this message is informational only.

Information displayed by Application Verifier

The application called CheckTokenMembership against entity %ws (%hs).

Verifier stop code

ID: CHECKTOKENMEMBERSHIP_UNTRUSTED

Code: 0x3327

Error level

Information


Access was restricted to trusted users only (more)

Application Verifier break message

Access was restricted to trusted users only.

Probable cause

The application opened an object (such as a file or registry key) and requested access permissions that were granted solely to trusted users. This indicates that untrusted users will have difficulty running the application correctly. This message will always be followed by other messages.

Information displayed by Application Verifier

(%hs) %hs (%ws) only grants requested %hs to %ws (and others -- see subsequent stops).

Verifier stop code

ID: RESTRICTED_RIGHT_MORE

Code: 0x331C

Error level

Error


The application failed to enabled an unknown non-security relevant privilege

Application Verifier break message

The application failed to enable a non-security relevant privilege.

Probable cause

The application requested the listed privilege unsuccessfully. Although this privilege is not security-relevant (E.G. a standard user might potentially have the privilege), this could be indicative of nonstandard privilege requirements in the application. In this case, the application may generate excessive audit traffic or its functionality may be impaired.

Information displayed by Application Verifier

Could not enable unknown privilege %ws with %hs.

Verifier stop code

ID: IRRELEVANT_UNKNOWN_PRIVILEGE_DENIED

Code: 0x3313

Error level

Warning


The Verifier was unable to access the object's security descriptor

Application Verifier break message

The object's security descriptor is inaccessible.

Probable cause

The application was granted the requested access to this object. A standard user, however, may have trouble accessing this object.

Information displayed by Application Verifier

%hs (%ws, access 0x%x) was granted to %hs.

Verifier stop code

ID: BAD_OBJECT_DUMP

Code: 0x3318

Error level

Warning


Missing security descriptor - ACE

Application Verifier break message

Missing part of a security descriptor.

Probable cause

The Verifier attempted to analyze the object's security descriptor, but received an unexpected error when attempting to break it into pieces for scrutiny. This may suggest that the object's security descriptor could be invalid.

Information displayed by Application Verifier

Could not retrieve ACE number %Id from %hs (%ws) DACL due to error 0x%x.

Stop code

ID: MISSING_ACE

Code: 0x3321

Error level

Warning


Request for security-relevant privilege failed

Application Verifier break message

The application requested a security-relevant privilege.

Probable cause

The application unsuccessfully requested the listed privilege, which is not granted to standard users. The API call will fail as a standard user, which may have performance and audit implications, in addition to having an impact on the application's functionality.

Information displayed by Application Verifier

Requested %ws%hs%ws%hs with %hs, but was denied.

Stop code

ID: FAILED_PRIVILEGE_LUID

Code: 0x3310

Error level

Error


Running as privileged user

Application Verifier break message

The application is running with privilege.

Probable cause

The application was launched by a user with access to the listed privilege. This indicates that the user is not a standard user. This may already be known, but to run as a standard user, the user should NOT be granted the given listed privilege.

Information displayed by Application Verifier

Running as user with access to %ws%hs%ws%hs.

Stop code

ID: PRIVILEGED_USER

Code: 0x3311

Error level

Information


The application failed to set the active power scheme.

Application Verifier break message

The application failed to set the active power scheme.

Probable cause

The application called SetActivePwrScheme that might fail under standard user accounts.

Information displayed by Application Verifier

SetactivePwrScheme (ID: %d) called to set the active power scheme and failed with error 0x%x.

Verifier stop code

SETACTIVEPWRSCHEME_FAILED (code 0x3337)

Error level

Error


The application called SetActivePwrScheme.

Application Verifier break message

The application called SetActivePwrScheme.

Probable cause

The application called SetActivePwrScheme which might fail under a standard-user account.

Information displayed by Application Verifier

SetActivePwrScheme (ID: %d) called to set the active power scheme.

Verifier stop code

SETACTIVEPWRSCHEME (code 0x3336)

Error level

Error


The application called NetUserGetInfo.

Application Verifier break message

The application called NetusergetInfo

Probable cause

The application called NetUserGetInfo and requested the user privilege information. This will work as a standard user, but it generally indicates that the application expects to be run by an administrator and is examining the access token to determine this..

Information displayed by Application Verifier

NetUserGetInfo (level: %d) called.

Verifier stop code

NETUSERGETINFO (code 0x3335)

Error level

Warning


The application failed to set a Windows hook.

Application Verifier break message

The application failed to set a Windows hook.

Probable cause

The application failed to set a global Windows hook, which might be caused by inadequate privileges.

Information displayed by Application Verifier

%hs %d (%hs) failed to set a Windows hook with error 0x%x

Verifier stop code

SET_HOOK_FAILED (code 0x3334)

Error level

Error


The application tried to set a global Windows hook.

Application Verifier break message

The application tried to set a global Windows hook.

Probable cause

The application tried to set a global Windows hoo, which does not work for a standard user account.

Information displayed by Application Verifier

%hs %d (%hs) called to set a global Windows hook.

Verifier stop code

SET_GLOBAL_HOOK (code 0x3333)

Error level

Error


The application was denied access to an INI file entry.

Application Verifier break message

The application was denied access to an INI file entry.

Probable cause

The application was denied access to the given profile section due to insufficient privileges. If the application’s functionality is impaired, this access problem may be the cause.

Information displayed by Application Verifier

Ini: %hs called with Ini file ‘%ws’, Section ‘%ws’, Key ‘%ws’, failed with error 0x%x

Verifier stop code

INI_PROFILE_FAILED (code 0x3330)

Error level

Error


The application opened the Security eventlog.

Application Verifier break message

The application opened the Security eventlog.

Probable cause

The application opened the Security log, which requires SE_SECURITY_PRIVILEGE to read or write. The SECURITY privilege is, by default, only granted to Administrators.

Information displayed by Application Verifier

%hs was invoked on the (Security) Eventlog. The Security log always requires SE_SECURITY_PRIVILEGE to access.

Verifier stop code

SECURITY_LOG_OPENED (code 0x332F)

Error level

Error


The application called an API that failed unexpectedly, possibly due to bad parameters.

Application Verifier break message

The application called an API that failed unexpectedly, possibly due to bad parameters.

Probable cause

The application called the listed API, which failed with an access error suggesting a potential LUA issue.

Information displayed by Application Verifier

%hs: %hs (%ws) is denied ‘%hs’ access with the error 0x%x

Verifier stop code

FALIED_API_CALL (code 0x332E)

Error level

Warning


The application was denied access to an object.

Application Verifier break message

The application was denied access to an object

Probable cause

The application called the listed API, which failed with an access error suggesting a potential LUA issue.

Information displayed by Application Verifier

%hs: %hs (%ws) is denied ‘%hs’ access with the error 0x%x

Verifier stop code

OBJECT_INACCESSIBLE (code 0x332D)

Error level

Error


The application tried to launch a process that might need to run elevated on Windows Vista.

Application Verifier break message

The application tried to launch a process that might need to run elevated on Windows Vista

Probable cause

The application tried to use CreateProcess family API to launch a process that might need to run elevated on Windows Vista. It should use the ShellExecute API instead.

Information displayed by Application Verifier

%hs (‘%ws’, ‘%ws’) tried to launch a process that might need to run elevated on Windows Vista.

Verifier stop code

ELEVATION_DETECTED (code 0x332C)

Error level

Error


The application tried to launch a process that needs to run elevated on Windows Vista

Application Verifier break message

The application tried to launch a process that needs to run elevated on Windows Vista

Probable cause

The application tried to use CreateProcess family API to launch a process that needs to run elevated on Windows Vista. It should use ShellExecute family API instead.

Information displayed by Application Verifier

%hs ‘(%ws, ‘%ws) tried to launch a process that needs to run elevated on Windows Vista.

Verifier stop code

ELEVATION_REQUIRED (code 0x332B)

Error level

Error


The predictor was unable to query required information from a handle

Application Verifier break message

The predictor was unable to query required information from a handle.

Probable cause

The predictor was unable to query the access granted on a handle on which the application had requested MAXIMUM_ALLOWED.

Information displayed by Application Verifier

The operating system returned an unexpected error 0x%x when querying handle 0x%p

Verifier stop code

CANNOT_QUERY_ACCESS (code 0x332A)

Error level

Warning


The application performed an operation that required privilege

Application Verifier break message

The application performed an operation that required privilege

Probable cause

The application used MAXIMUM_ALLOWED to get access required to call this function. This function would fail if called by a standard user.

Information displayed by Application Verifier

%hs: %hs (%ws) requires ‘%hs’ access. This access was restricted to trusted users when the application called %hs with ‘MAXIMUM_ALLOWED’. If the application were running as a standard user, the call to %hs would succeed, but the call to %hs would fail.

Verifier stop code

OP_REQUIRES ACCESS (code 0x3329)

Error level

Error


The application called a WriteProfile API with LUA

Application Verifier break message

The application called a WriteProfile API with LUA

Probable cause

The application called a WriteProfile API with parameters that might fail under a standard-user account.

Information displayed by Application Verifier

Ini: %hs called with Ini file ‘%ws’, Section ‘%ws’, Key ‘%ws’

Verifier stop code

INI_PROFILE_CONCERN (code 0x3328)

Error level

Error


Print Stops
See Also

When Application Verifier is run on a solution or project, the Print Verifier provides a stop code when an error is found. The stop codes that may be encountered depend on the tests selected to run.

The following is a list of all codes that may be encountered when running the Print Verifier. To find out more about the details of the stop, please refer to the specific error message.

PrintAPI test layer messages

These messages are returned by the Print Verifier when it is testing the PrintAPI test layer.

Error message | Stop code
Leaked printer handle detected | 0000A000
Leaked printer change notification handle detected | 0000A001
Leaked PRINTER_NOTIFY_INFO detected | 0000A002
Race condition detected while using a printer handle | 0000A003
Potential multi-threaded access to a printer handle detected | 0000A004
Attempt to use a closed printer handle | 0000A005
Attempt to use an unknown printer handle | 0000A006
Attempt to use a closed printer change notification handle | 0000A007
Attempt to use an invalid printer change notification handle | 0000A008
Attempt to use a freed PRINTER_NOTIFY_INFO object | 0000A009
Attempt to use an invalid PRINTER_NOTIFY_INFO object | 0000A00A
Too many open printer handles. | 0000A00B
OpenPrinter2W seems to be exported from winspool.drv of an earlier version of Microsoft Windows | 0000A00C
Too many open PrintTicket provider handles (HPTPROVIDER) | 0000A00D
Attempt to use a closed PrintTicket provider handle (HPTPROVIDER) | 0000A00E
Attempt to use an unknown PrintTicket provider handle (HPTPROVIDER) | 0000A00F
Race condition detected while using a PrintTicket provider handle | 0000A010
Potential multi-threaded access to a PrintTicket provider handle detected | 0000A011
Leaked PrintTicket provider handle detected | 0000A012
Too many open printer change notification handles | 0000A013
Too many open PRINTER_NOTIFY_INFO objects | 0000A014
Attempt to use an invalid PrintTicket | 0000A015
Attempt to use an invalid PrintCapabilities document | 0000A016
An invalid NULL argument was passed to a PrintTicket method | 0000A017
PTConform encountered an unexpected error (PrintAPI) | 0000A018
Illegal print API called from DllMain | 0000A019
Leaked spool file handle detected | 0000A01A
Attempt to use a closed spool file handle | 0000A01B
Attempt to use an unknown spool file handle | 0000A01C
Too many open spool file handles | 0000A01D
DEVMODE buffer parameter spans across non-readable memory page(s) | 0000A01E
Unloading module with active COM callback | 0000A01F
Async Notify handle returned by RegisterForPrintAsyncNotifications was not released properly | 0000A020
Attempt to use an invalid handle in UnRegisterForPrintAsyncNotifications | 0000A021
Attempt to use a closed handle in UnRegisterForPrintAsyncNotifications API function | 0000A022
Third-party function reports failure but increases reference count for input interface | 0000A023
Windows API function reports failure but increases reference count for input interface | 0000A024
IPrintAsyncNotifyChannel contract violation by the operating system | 0000A025
IPrintAsyncNotifyChannel contract violation by channel consumer | 0000A026
Race detected during closing of IPrintAsyncNotifyChannel | 0000A027
Calling a print API that makes network calls on a GUI thread | 0000A028
Calling an API that will pop up user interface in Session0 | 0000A029

PrintDriver test layer messages

These messages are returned by the Print Verifier when it is testing the PrintDriver test layer.

Error message | Stop code
First chance access violation detected | 0000D000
The thread tried to divide an integer value by an integer divisor of zero | 0000D001
The thread tried to read or write misaligned data on hardware that does not provide alignment | 0000D002
Invalid handle exception for current stack trace in Print Verifier | 0000D003
Core driver is sending a closed printer handle to the plug-in | 0000D004
Core driver is sending an unknown printer handle to the plug-in | 0000D005
The plug-in driver closed the printer handle | 0000D006
Invalid number of supported Print Schema major versions | 0000D007
Missing supported Print Schema versions | 0000D008
Invalid Print Schema major version | 0000D009
Invalid OEMPTOPTS value | 0000D00A
Missing Print Schema private namespace | 0000D00B
Incorrect reference counting detected in the plug-in | 0000D00C
pptl is NULL in OEMNextBand | 0000D00D
The plug-in returned a NULL PDEV after returning S_OK from the EnablePDEV method | 0000D00E
The plug-in returned a private DEVMODE that is smaller than the minimum size allowed | 0000D00F
The plug-in returned a private DEVMODE with a different size than the size returned by the DevMode(OEMDM_SIZE) call | 0000D010
The plug-in returned an invalid signature from the GetInfo(OEMGI_GETSIGNATURE) call | 0000D011
The plug-in returned a different signature in the private DEVMODE than it returned from the GetInfo call | 0000D012
The EnableDriver method in the plug-in failed. | 0000D013
The EnableDriver method in the plug-in failed without setting the last error code | 0000D014
The core driver called SetBandSize although the plug-in returned S_OK from DriverDMS | 0000D015
The core driver made the WritePrinter initialization call with invalid parameters | 0000D016
The WritePrinter method in the plug-in failed | 0000D017
Core driver sent an invalid PrintTicket to the plug-in | 0000D018
The plug-in returned an invalid PrintTicket to the core driver | 0000D019
Core driver sent an invalid PrintCapabilities document to the plug-in | 0000D01A
The plug-in returned an invalid PrintCapabilities document to the core driver | 0000D01B
PTConform encountered an unexpected error (PrintDriver) | 0000D01C
Print filter calls pipeline manager interface with invalid argument value | 0000D01D
Print filter call to IPrintPipelinePropertyBag overwrites or removes common property | 0000D01E
Print filter calls pipeline manager interface out of order | 0000D01F
Print filter has mismatch of AddRef/Release calls to pipeline manager interface | 0000D020
Print filter call to pipeline manager interface method is not expected | 0000D021
Pipeline manager calls print filter interface methods out of order | 0000D022
Pipeline manager calls print filter interface method with invalid argument value | 0000D023
Pipeline manager returns invalid value to print filter | 0000D024
A call to a printer driver changed the security context | 0000D025
Print filter sent an invalid PrintTicket to pipeline manager | 0000D026
Print filter received an invalid PrintTicket from pipeline manager | 0000D027
Unloading print driver DLL with active COM callback. | 0000D028
Attempt to use a released COM interface | 0000D029
A print driver called ExitThread | 0000D02A
A print driver called TerminateThread | 0000D02B

See Also

Concepts

PrintAPI Test Layer Stop Details
PrintDriver Test Layer Stop Details


PrintDriver Test Layer Stop Details
See Also

When Application Verifier is run on a solution or project in the Print, the Print Verifier provides a stop code when an error is found. The stop codes that may be encountered in the PrintDriver test layer are listed in the following table. Refer to the specific error message to learn more about the details of the stop.

PrintDriver test layer messages

Error message | Stop code
First chance access violation detected | 0000D000
The thread tried to divide an integer value by an integer divisor of zero | 0000D001
The thread tried to read or write misaligned data on hardware that does not provide alignment | 0000D002
Invalid handle exception for current stack trace in Print Verifier | 0000D003
Core driver is sending a closed printer handle to the plug-in | 0000D004
Core driver is sending an unknown printer handle to the plug-in | 0000D005
The plug-in driver closed the printer handle | 0000D006
Invalid number of supported Print Schema major versions | 0000D007
Missing supported Print Schema versions | 0000D008
Invalid Print Schema major version | 0000D009
Invalid OEMPTOPTS value | 0000D00A
Missing Print Schema private namespace | 0000D00B
Incorrect reference counting detected in the plug-in | 0000D00C
pptl is NULL in OEMNextBand | 0000D00D
The plug-in returned a NULL PDEV after returning S_OK from the EnablePDEV method | 0000D00E
The plug-in returned a private DEVMODE that is smaller than the minimum size allowed | 0000D00F
The plug-in returned a private DEVMODE with a different size than the size returned by the DevMode(OEMDM_SIZE) call | 0000D010
The plug-in returned an invalid signature from the GetInfo(OEMGI_GETSIGNATURE) call | 0000D011
The plug-in returned a different signature in the private DEVMODE than it returned from the GetInfo call | 0000D012
The EnableDriver method in the plug-in failed. | 0000D013
The EnableDriver method in the plug-in failed without setting the last error code | 0000D014
The core driver called SetBandSize although the plug-in returned S_OK from DriverDMS | 0000D015
The core driver made the WritePrinter initialization call with invalid parameters | 0000D016
The WritePrinter method in the plug-in failed | 0000D017
Core driver sent an invalid PrintTicket to the plug-in | 0000D018
The plug-in returned an invalid PrintTicket to the core driver | 0000D019
Core driver sent an invalid PrintCapabilities document to the plug-in | 0000D01A
The plug-in returned an invalid PrintCapabilities document to the core driver | 0000D01B
PTConform encountered an unexpected error (PrintDriver) | 0000D01C
Print filter calls pipeline manager interface with invalid argument value | 0000D01D
Print filter call to IPrintPipelinePropertyBag overwrites or removes common property | 0000D01E
Print filter calls pipeline manager interface out of order | 0000D01F
Print filter has mismatch of AddRef/Release calls to pipeline manager interface | 0000D020
Print filter call to pipeline manager interface method is not expected | 0000D021
Pipeline manager calls print filter interface methods out of order | 0000D022
Pipeline manager calls print filter interface method with invalid argument value | 0000D023
Pipeline manager returns invalid value to print filter | 0000D024
A call to a printer driver changed the security context | 0000D025
Print filter sent an invalid PrintTicket to pipeline manager | 0000D026
Print filter received an invalid PrintTicket from pipeline manager | 0000D027
Unloading print driver DLL with active COM callback. | 0000D028
Attempt to use a released COM interface | 0000D029
A print driver called ExitThread | 0000D02A
A print driver called TerminateThread | 0000D02B

See Also

Concepts

PrintAPI Test Layer Stop Details


First chance access violation detected

Application Verifier break message

First chance access violation detected

Probable cause

This stop is generated when the printer driver tries to access a virtual memory address that is not accessible because it is non-executable, it has been freed or decommitted, or it is reserved but not committed.

Troubleshooting steps

To debug this stop:

$ u parameter2 - to unassemble the suspect code

$ .exr parameter3 - to display the exception information;

$ .cxr parameter4 - to display the exception context information

$ kb - to display the stack trace when the exception was raised.

Information displayed by Application Verifier

Parameter 1 - Address being accessed.

Parameter 2 - Code performing invalid access.

Parameter 3 - Exception record. Use .exr to display it.

Parameter 4 - Context record. Use .cxr to display it.

Additional information

Test Layer: PrintDriver

Stop code: 0000D000

Severity: Error

One-time error: no

Non Continuable: yes

Error report: Break

Log to file: yes

Create backtrace: yes


The thread tried to divide an integer value by an integer divisor of zero

Application Verifier break message

The thread tried to divide an integer value by an integer divisor of zero

Probable cause

This stop is generated when the printer driver tries to divide an integer value by an integer divisor of zero.

Troubleshooting steps

To debug this stop:

$ u parameter1 - to unassemble the suspect code

$ .exr parameter2 - to display the exception information;

$ .cxr parameter3 - to display the exception context information

$ kb - to display the stack trace when the exception was raised.

Information displayed by Application Verifier

Parameter 1 - Code performing divide by zero operation.

Parameter 2 - Exception record. Use .exr to display it.

Parameter 3 - Context record. Use .cxr to display it.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D001

Severity: Error

One-time error: no

Non Continuable: yes

Error report: Break

Log to file: yes

Create backtrace: yes


The thread tried to read or write misaligned data on hardware that does not provide alignment

Application Verifier break message

The thread tried to read or write misaligned data on hardware that does not provide alignment

Probable cause

This stop is generated when the driver tries to read or write misaligned data on hardware that does not provide alignment. For example, 16-bit values must be aligned on 2-byte boundaries; 32-bit values on 4-byte boundaries, and so on.

Troubleshooting steps

To debug this stop:

$ u parameter1 - to unassemble the culprit code

$ .exr parameter2 - to display the exception information;

$ .cxr parameter3 - to display the exception context information

$ kb - to display the stack trace when the exception was raised.

Information displayed by Application Verifier

Parameter 1 - Code where the data type misalignment occurred.

Parameter 2 - Exception record. Use .exr to display it.

Parameter 3 - Context record. Use .cxr to display it.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D002

Severity: Error

One-time error: no

Non Continuable: yes

Error report: Break

Log to file: yes

Create backtrace: yes


Invalid handle exception for current stack trace in Print Verifier

Application Verifier break message

Invalid handle exception for current stack trace

Probable cause

This stop is generated when the function on the top of the stack passes an invalid handle to a system routine. Usually the kb command will reveal the value of the handle passed in the call stack. The handle will be one of the parameters of the call. Often it is the first parameter. A null handle value is one example of an invalid handle value. If the handle value appears to be valid, use the !htrace debugger extension to view the history of operations that involved the handle value. Sometimes a handle value that appears to be valid can be invalid if the handle is used after it was closed.

For example:

Copy Code
0:027> k
ChildEBP RetAddr
0765eb50 7c82ed53 ntdll!KiRaiseUserExceptionDispatcher+0x37
0765eb54 7c821144 ntdll!KiFastSystemCall+0x3
0765eb58 008f9cf0 ntdll!NtClose+0xc
0765eb68 77e6c1fe vfbasics!AVrfpNtClose+0x10
0765eb74 008f49c9 KERNEL32!CloseHandle+0x59
0765eb84 77c34a60 vfbasics!AVrfpCloseHandle+0x89
0765ebe4 761734a2 GDI32!GdiPlayPageEMF+0x186

0:027> !htrace b08

--------------------------------------
Handle = 0x00000b08 - *** BAD REFERENCE ***
Thread ID = 0x00000170, Process ID = 0x00000228

0x77e6c1fe: KERNEL32!CloseHandle+0x00000044
0x008f49c9: vfbasics!AVrfpCloseHandle+0x00000089
0x77c34a60: GDI32!GdiPlayPageEMF+0x00000186      <-------------------------- SECOND CLOSE
0x761734a2: localspl!SplLogWmiTraceEventExternal+0x00006f06
0x76151feb: localspl!SplResetPrinter+0x000096d4
0x76143faf: localspl!SplSetPrinterDataEx+0x00001a6e
0x76143b04: localspl!SplSetPrinterDataEx+0x000015c3
--------------------------------------
Handle = 0x00000b08 - CLOSE
Thread ID = 0x00000170, Process ID = 0x00000228

0x77e6c1fe: KERNEL32!CloseHandle+0x00000044
0x008f49c9: vfbasics!AVrfpCloseHandle+0x00000089
0x77c24bef: GDI32!SetWinMetaFileBits+0x00000923   <-------------------------------- FIRST CLOSE
0x77c38e55: GDI32!GdiDrawStream+0x00000d06
0x77c34a39: GDI32!GdiPlayPageEMF+0x0000015f
0x761734a2: localspl!SplLogWmiTraceEventExternal+0x00006f06

Information displayed by Application Verifier

Parameter 1 - Exception code.

Parameter 2 - Exception record. Use .exr to display it.

Parameter 3 - Context record. Use .cxr to display it.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D003

Severity: Error

One-time error: no

Non Continuable: yes

Error report: Break

Log to file: yes

Create backtrace: yes


Core driver is sending a closed printer handle to the plug-in

Application Verifier break message

Core driver is sending a closed printer handle to the plug-in

Probable cause

The core driver is sending the plug-in a printer handle that has already been closed. Report this error to Microsoft because it could be a problem in Microsoft's core printer driver module.

Troubleshooting steps

To identify the routine that tried to use the closed printer handle, dump the current stack trace by using the ‘k' command in the debugger.

To dump the stack trace of the routine that closed the handle, use the dps command with the second parameter of the stop.

Information displayed by Application Verifier

Parameter 1 - Printer handle being sent to the plug-in.

Parameter 2 - Stack trace of the closing routine.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D004

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Core driver is sending an unknown printer handle to the plug-in

Application Verifier break message

Core driver is sending an unknown printer handle to the plug-in

Probable cause

The core driver is sending the plug-in a printer handle that was not opened by calling OpenPrinterA, OpenPrinterW, OpenPrinter2W in Microsoft Windows Vista, AddPrinterA, or AddPrinterW.

Report this error to Microsoft because it could be a problem in Microsoft's core printer driver module.

Information displayed by Application Verifier

Parameter 1 - Printer handle being accessed.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D005

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


The plug-in driver closed the printer handle

Application Verifier break message

The plug-in closed the printer handle

Probable cause

The plug-in closed the printer handle that it received as input from the core driver. This violates the Windows Driver Kit (WDK) rules for a call from the core driver to the plug-in. Use dps on the second parameter of the stop in order to dump the stack trace of the routine that closed the handle.

For example:

Copy Code
=======================================
VERIFIER STOP 0000D006 : pid 0x1644: The plugin driver closed the printer handle.
00000000018F6898 : Printer handle that was closed.
0000000001E733B0 : Stack trace of the closing. Use dps to dump the stack trace if it is not NULL.
0000000000000000 : Not used.
0000000000000000 : Not used.

This verifier stop was caused by the GetSupportedVersions method in the plug-in module at C:\WINDOWS\system32\spool\DRIVERS\x64\3\PTPlug_GetSupVersions_1.dll
=======================================
0:000> k
Child-SP          RetAddr           Call Site
00000000'000aefe8 00000000'01d032d5 ntdll!DbgBreakPoint
00000000'000aeff0 00000000'01d49b98 vrfcore!VerifierStopMessageEx+0x5f5
00000000'000af2c0 00000000'01d3829e vfprint!CPrintVerifierCommonDriverHelper::PluginClosedPrinterHandleCheck+0xb8
00000000'000af330 00000000'4f4d3d31 vfprint!CPrintVerifierPrintTicketProvider::GetSupportedVersions+0x10e
00000000'000af3a0 00000000'01f05f31 UNIDRVUI!CPrintTicketProvider::GetSupportedVersions+0x1e1
00000000'000af480 00000000'01f05a07 prntvpt!PTOpenProviderExImp+0x471
00000000'000af620 00000000'01efe93c prntvpt!PTOpenProviderImp+0x97
00000000'000af6b0 00000000'01f02cc5 prntvpt!CPrintTicketServerBase::Bind+0x3c
00000000'000af6f0 00000000'01d47e57 prntvpt!PTOpenProvider+0x1c5
00000000'000af7b0 00000001'0000e87f vfprint!VfPTOpenProvider+0x97
00000000'000af810 00000001'00008ce5 ptutil!PTUGetDefaultTicket<_PRINTER_INFO_9W,9>+0x11f
00000000'000afcb0 00000001'000304b0 ptutil!main+0x205
00000000'000aff20 00000000'78d5965c ptutil!__tmainCRTStartup+0x144
00000000'000aff80 00000000'00000000 KERNEL32!BaseProcessStart+0x29

0:000> dps 0000000001E733B0
00000000'01e733b0  00000000'01d34441 vfprint!VfHookClosePrinter+0x71
00000000'01e733b8  00000000'50010c57 PTPlug_GetSupVersions_1!COemPrintTicketProvider::GetSupportedVersions+0xa7    <-------- Code that closed the handle
00000000'01e733c0  00000000'01d3821c vfprint!CPrintVerifierPrintTicketProvider::GetSupportedVersions+0x8c
00000000'01e733c8  00000000'4f4d3d31 UNIDRVUI!CPrintTicketProvider::GetSupportedVersions+0x1e1
00000000'01e733d0  00000000'01f05f31 prntvpt!PTOpenProviderExImp+0x471
00000000'01e733d8  00000000'01f05a07 prntvpt!PTOpenProviderImp+0x97
00000000'01e733e0  00000000'01efe93c prntvpt!CPrintTicketServerBase::Bind+0x3c
00000000'01e733e8  00000000'01f02cc5 prntvpt!PTOpenProvider+0x1c5
00000000'01e733f0  00000000'01d47e57 vfprint!VfPTOpenProvider+0x97
00000000'01e733f8  00000001'0000e87f ptutil!PTUGetDefaultTicket<_PRINTER_INFO_9W,9>+0x11f
00000000'01e73400  00000001'00008ce5 ptutil!main+0x205
00000000'01e73408  00000001'000304b0 ptutil!__tmainCRTStartup+0x144
00000000'01e73410  00000000'78d5965c KERNEL32!BaseProcessStart+0x29

Information displayed by Application Verifier

Format: - This verifier stop was caused by the %lS method in the plug-in module at %lS

Parameter 1 - Printer handle that was closed.

Parameter 2 - Stack trace of the closing. Use dps to dump the stack trace if it is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D006

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Invalid number of supported Print Schema major versions

Application Verifier break message

Invalid number of supported Print Schema major versions

Probable cause

The PrintTicket provider plug-in returned an invalid number of supported Print Schema major versions. The IPrintOemPrintTicketProvider::GetSupportedVersions method in the plug-in is expected to return at least one supported major version. Because Microsoft Windows Vista supports only one major version of the Print Schema, the plug-in is expected to return a value of one.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the %lS method in the plug-in module at %lS

Parameter 1 - Number of supported schema versions that were returned.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D007

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Missing supported Print Schema versions

Application Verifier break message

Missing supported Print Schema versions

Probable cause

The PrintTicket provider plug-in indicated that it was returning at least one supported Print Schema version but failed to return any. The call to the IPrintOemPrintTicketProvider::GetSupportedVersions method in the plug-in accepts two out pointers as arguments. The ppVersions argument points to an array of integers representing the supported major versions of the Print Schema. The cVersions argument points to the number of elements in the array of integers that is being returned.

This verifier stop occurs when the plug-in returns a valid number in cVersions but fails to return anything in the ppVersions array.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the %lS method in the plug-in module at %lS

Parameter 1 - Number of supported Print Schema versions that were returned.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D008

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Invalid Print Schema major version

Application Verifier break message

Invalid Print Schema major version

Probable cause

The PrintTicket provider plug-in returned an invalid Print Schema major version. The call to the IPrintOemPrintTicketProvider::GetSupportedVersions method in the plug-in is expected to return a value of one (1) because the only major version of the Print Schema supported by Microsoft Windows Vista is 1.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the %lS method in the plug-in module at %lS

Parameter 1 - Print Schema version that was returned.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D009

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Invalid OEMPTOPTS value

Application Verifier break message

Invalid OEMPTOPTS value

Probable cause

The PrintTicket provider plug-in returned an invalid OEMPTOPTS value. One of the arguments to the IPrintOemPrintTicketProvider::BindPrinter method in the plug-in is a pointer to an OEMPTOPTS enumeration. The plug-in is expected to set the value of this argument to one of the values supported by Microsoft Windows Vista. The values supported by Windows Vista are OEMPT_DEFAULT and OEMPT_NOSNAPSHOT.

This verifier stop occurs when the plug-in returns a value that is not one of these supported values.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the %lS method in the plugin module at %lS

Parameter 1 - OEMPTOPTS value that was returned.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D00A

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Missing Print Schema private namespace

Application Verifier break message

Missing Print Schema private namespace

Probable cause

The PrintTicket provider plug-in indicated that it was returning at least one Print Schema private namespace but did not return any. The call to the IPrintOemPrintTicketProvider::BindPrinter method in the plug-in contains two out pointer arguments through which the plug-in can return information about the Print Schema private namespaces that it supports. The ppNamespaces argument points to an array of strings representing the supported Print Schema private namespaces. The cNamespaces argument points to the number of elements in the array of strings that is being returned.

This verifier stop occurs when the plug-in returns a valid number in cNamespaces but does not return anything in the ppNamespaces array.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the %lS method in the plugin module at %lS

Parameter 1 - Number of expected namespaces.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D00B

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Incorrect reference counting detected in the plug-in

Application Verifier break message

Incorrect reference counting detected in the plug-in

Probable cause

The Windows Driver Kit (WDK) states that plug-ins must perform accurate reference counting in their implementation of the IUnknown::AddRef and IUnknown::Release methods. The lifetime of the plug-in's interface object depends on accurate reference counting. If the reference counting is inaccurate, it can result in a resource leak or lead to the premature unloading of the plug-in which will cause the driver to fail.

This verifier stop occurs when incorrect reference counting is detected in the plug-in.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the plug-in module at %lS

Parameter 1 - Expected reference count.

Parameter 2 - Actual reference count maintained by the plug-in.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D00C

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


pptl is NULL in OEMNextBand

Application Verifier break message

pptl is NULL in OEMNextBand

Probable cause

The pptl passed in by the core driver to the OEMNextBand hook in the plug-in was NULL. The core driver should always send a valid pptl to the OEMNextBand hook in the plug-in.

Report this error to Microsoft because it could be a problem in Microsoft's core printer driver module.

Information displayed by Application Verifier

Parameter 1 - Not used.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D00D

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


The plug-in returned a NULL PDEV after returning S_OK from the EnablePDEV method

Application Verifier break message

The plug-in returned a NULL PDEV after returning S_OK from the EnablePDEV method

Probable cause

The private PDEV returned by the plug-in was NULL although the return value from the EnablePDEV method was S_OK indicating success. The Windows Driver Kit (WDK) states that if the EnablePDEV method of a plug-in returns a status of S_OK, it must also allocate an instance of its private PDEV structure, initialize it, and return the address of this structure in the method's pDevOem parameter.

This verifier stop occurs when the plug-in does not return a valid private PDEV structure when from its implementation of the EnablePDEV method returns a status of S_OK.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the plug-in module at %lS

Parameter 1 - Not used.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D00E

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


The plug-in returned a private DEVMODE that is smaller than the minimum size allowed

Application Verifier break message

The plug-in returned a private DEVMODE that is smaller than the minimum size allowed

Probable cause

The private DEVMODE returned by the plug-in should be at least the size of OEM_DMEXTRAHEADER.

The DevMode method of a plug-in must return the size required to store its private DEVMODE members when it is called with the OEMDM_SIZE mode. This value is set the first time the method is called. The DevMode method in the plug-in must set the value of the cbBufSize member in the OEMDMPARAM structure to the number of bytes needed and that value must be greater than or equal to the size of OEM_DMEXTRAHEADER.

This verifier stop occurs when the size returned in the cbBufSize member in the OEMDMPARAM structure is less than the size of OEM_DMEXTRAHEADER.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the plug-in module at %lS

Parameter 1 - Mode for the current DevMode callback.

Parameter 2 - Size of the plug-in's private DEVMODE.

Parameter 3 - Size of OEM_DMEXTRAHEADER.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D00F

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


The plug-in returned a private DEVMODE with a different size than the size returned by the DevMode(OEMDM_SIZE) call

Application Verifier break message

The plug-in returned a private DEVMODE with a different size than the size returned by the DevMode(OEMDM_SIZE) call

Probable cause

The plug-in should return a private DEVMODE with a size that is the same as that returned by the DevMode call with OEMDM_SIZE mode. The DevMode method of a plug-in must return the size required to store its private DEVMODE members when the DevMode method is called with the OEMDM_SIZE mode. This value is a constant and is set the first time the method is called. It must not change when subsequent calls are made to the plug-in's DevMode method.

This verifier stop occurs when the DevMode method in the plug-in returns a value that is different from the value it returned the first time it was called.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the plug-in module at %lS

Parameter 1 - Mode for the current Devmode callback.

Parameter 2 - Size of output plug-in private DEVMODE as specified in pOEMDMOut.

Parameter 3 - Size of output plug-in private DEVMODE as specified in pOEMDMParam.

Parameter 4 - Size of plug-in private DEVMODE as specified during the OEMDM_SIZE call.

Additional information

Test Layer: PrintDriver

Stop code: 0000D010

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


The plug-in returned an invalid signature from the GetInfo(OEMGI_GETSIGNATURE) call

Application Verifier break message

The plug-in returned an invalid signature from the GetInfo(OEMGI_GETSIGNATURE) call

Probable cause

The plug-in should return a valid, non-zero signature when it is called during the GetInfo call with a mode of OEMGI_GETSIGNATURE. The GetInfo method in the plug-in must return a unique, four-byte identification signature.

This verifier stop occurs when the GetInfo(OEMGI_GETSIGNATURE) method in the plug-in returns a zero signature.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the plug-in module at %lS

Parameter 1 - Not used.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D011

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


The plug-in returned a different signature in the private DEVMODE than it returned from the GetInfo call

Application Verifier break message

The plug-in returned a different signature in the private DEVMODE than it returned from the GetInfo call

Probable cause

The plug-in should return a private DEVMODE that contains the same unique four-byte identification signature that it returned with the OEMGI_GETSIGNATURE call to the GetInfo method in the plug-in.

This verifier stop occurs when these two signatures are not identical.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the plug-in module at %lS

Parameter 1 - Mode for the current DevMode method call.

Parameter 2 - Signature as specified in the output plug-in private DEVMODE.

Parameter 3 - Signature as specified during the GetInfo call.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D012

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


The EnableDriver method in the plug-in failed.

Application Verifier break message

The EnableDriver method in the plug-in failed.

Probable cause

The EnableDriver method in the plug-in is not expected to fail, although it may fail under exceptional circumstances.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the plug-in module at %lS

Parameter 1 - HRESULT returned by EnableDriver.

Parameter 2 - Error code set by plug-in.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D013

Severity: Warning

One-time error: no

Error report: None

Log to file: yes

Create backtrace: yes


The EnableDriver method in the plug-in failed without setting the last error code

Application Verifier break message

The EnableDriver method in the plug-in failed without setting the last error code

Probable cause

The EnableDriver method in the plug-in is not expected to fail although it may fail under exceptional circumstances. If it does fail, it must set the last error code by calling SetLastError.

This verifier stop occurs when the EnableDriver method in the plug-in fails without setting the last error.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the plug-in module at %lS

Parameter 1 - HRESULT returned by EnableDriver.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D014

Severity: Warning

One-time error: no

Error report: None

Log to file: yes

Create backtrace: yes


The core driver called SetBandSize although the plug-in returned S_OK from DriverDMS

Application Verifier break message

The core driver called SetBandSize although the plug-in returned S_OK from DriverDMS

Probable cause

The core driver is not expected to call SetBandSize if the plug-in implements the DriverDMS method and its implementation of the DriverDMS method returns S_OK.

Report this error to Microsoft because it could be a problem in Microsoft's core printer driver module.

Information displayed by Application Verifier

Parameter 1 - Not used.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D015

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


The core driver made the WritePrinter initialization call with invalid parameters

Application Verifier break message

The core driver made the WritePrinter initialization call with invalid parameters

Probable cause

During the initialization call of WritePrinter, the pdevobj and pBuf arguments should be NULL and cbBuf should be zero. One of these conditions wasn't true when the core driver made the initialization call to the WritePrinter method in the plug-in.

Report this error to Microsoft because it could be a problem in Microsoft's core printer driver module.

Information displayed by Application Verifier

Parameter 1 - Not used.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D016

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


The WritePrinter method in the plug-in failed

Application Verifier break message

The WritePrinter method in the plug-in failed

Probable cause

This verifier stop occurs when the WritePrinter method in the plug-in failed. This will cause the print job to be aborted.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the plug-in module at %lS

Parameter 1 - HRESULT returned by the WritePrinter method in the plug-in.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D017

Severity: Warning

One-time error: no

Error report: None

Log to file: yes

Create backtrace: yes


Pipeline manager returns invalid value to print filter

Application Verifier break message

Pipeline manager returns invalid value to print filter

Probable cause

This verifier stop occurs when the pipeline manager returns an invalid value to the print filter. Report this error to Microsoft because it could be a problem in the print filter pipeline service.

Information displayed by Application Verifier

Format: - Method %s: %s

Parameter 1 - Filter CLSID pointer.

Parameter 2 - Value.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D024

Severity: Warning

One-time error: no

Error report: None

Log to file: yes

Create backtrace: yes


Pipeline manager calls print filter interface method with invalid argument value

Application Verifier break message

Pipeline manager calls print filter interface method with invalid argument value

Probable cause

This verifier stop occurs when the pipeline manager calls a print filter interface with an invalid argument value. Report this error to Microsoft because it could be a problem in the print filter pipeline service.

Information displayed by Application Verifier

Format: - Method %s: %s

Parameter 1 - Filter CLSID pointer.

Parameter 2 - Argument value.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D023

Severity: Warning

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Pipeline manager calls print filter interface methods out of order

Application Verifier break message

Pipeline manager calls print filter interface methods out of order

Probable cause

This verifier stop occurs when the pipeline manager incorrectly calls the methods of the print filter interface. Report this error to Microsoft because it could be a problem in the print filter pipeline service.

Information displayed by Application Verifier

Format: - Invalid call order to Print Filter : %s

Parameter 1 - Filter CLSID pointer.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D022

Severity: Warning

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Print filter call to pipeline manager interface method is not expected

Application Verifier break message

Print filter call to pipeline manager interface method is not expected

Probable cause

This verifier stop occurs when a print filter makes an unnecessary or unexpected call to a pipeline interface method. For example, if the print filter makes a second call to IPrintWriteStream::Close.

Information displayed by Application Verifier

Format: - Interface method %s : %s

Parameter 1 - Filter CLSID pointer.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D021

Severity: Warning

One-time error: no

Error report: None

Log to file: yes

Create backtrace: yes


Print filter has mismatch of AddRef/Release calls to pipeline manager interface

Application Verifier break message

Print filter has mismatch of AddRef/Release calls to pipeline manager interface

Probable cause

The Windows Driver Kit (WDK) states that print filters must perform accurate reference counting in their implementation of the IUnknown::AddRef and IUnknown::Release methods. The lifetime of the print filter objects depends on accurate reference counting. If the reference counting is inaccurate, it can result in a resource leak or lead to the premature unloading of the plug-in which will cause the driver to fail.

This verifier stop occurs when a print filter incorrectly manages the reference count of the pipeline manager interface.

Information displayed by Application Verifier

Format: - Interface %s ref count is %d, expected %s.

Parameter 1 - Filter CLSID pointer.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D020

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Print filter calls pipeline manager interface out of order

Application Verifier break message

Print filter calls pipeline manager interface out of order

Probable cause

This verifier stop occurs when a print filter calls the pipeline manager interface methods in an unexpected sequence.

Information displayed by Application Verifier

Format: - Incorrect call order for %s interface : %s

Parameter 1 - Filter CLSID pointer.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D01F

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Print filter call to IPrintPipelinePropertyBag overwrites or removes common property

Application Verifier break message

Print filter call to IPrintPipelinePropertyBag overwrites or removes common property

Probable cause

This verifier stop occurs when a print filter changes or deletes a common property from print pipeline property bag.

Information displayed by Application Verifier

Format: - %s method : Overwriting common property %s

Parameter 1 - Filter CLSID pointer.

Parameter 2 - Property value (variant).

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D01E

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Print filter calls pipeline manager interface with invalid argument value

Application Verifier break message

Print filter calls pipeline manager interface with invalid argument value

Probable cause

This verifier stop occurs when a print filter calls a pipeline method with an incorrect argument value. Use the stack trace to find the name of the print filter DLL.

Information displayed by Application Verifier

Format: - %s method : Invalid value for %s argument.

Parameter 1 - Filter CLSID pointer.

Parameter 2 - Argument value.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D01D

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


PTConform encountered an unexpected error (PrintDriver)

Application Verifier break message

PTConform encountered an unexpected error

Probable cause

This verifier stop occurs when the PrintVerifier encounters an unexpected error while attempting to verify that the PrintTicket/PrintCapabilities conforms to the PrintSchema. Report this error to Microsoft because it could be a problem in the PrintVerifier.

Information displayed by Application Verifier

Parameter 1 - Not used.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D01C

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


The plug-in returned an invalid PrintCapabilities document to the core driver

Application Verifier break message

The plug-in returned an invalid PrintCapabilities document to the core driver

Probable cause

This verifier stop occurs when a PrintCapabilities document that was returned to the core driver from the plug-in did not conform to the PrintSchema.

Troubleshooting Steps

Dump the XML print capabilities document text in the debugger by entering the du command with the value of parameter 2

Copy the text returned by the du command and paste it into a blank notepad document

Remove the debugger text in notepad to leave only the XML text from the print capabilities document

Save the XML text as a file

Evaluate the XML text using PTConform, a tool that is available in the Windows Driver Kit

Information displayed by Application Verifier

Format: - This verifier stop was caused by the %lS method in the plug-in module at %lS

Parameter 1 - Error messages returned by PTConform. Use du to dump the message if this parameter is not NULL.

Parameter 2 - PrintCapabilities XML text. Use du to dump the XML if this parameter is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D01B

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Core driver sent an invalid PrintCapabilities document to the plug-in

Application Verifier break message

Core driver sent an invalid PrintCapabilities document to the plug-in

Probable cause

This verifier stop occurs when a PrintCapabilities document that was sent from the core driver to the plug-in did not conform to the PrintSchema. Report this error to Microsoft because it could be a problem in Microsoft's core printer driver module.

Troubleshooting Steps

Dump the XML print capabilities document text in the debugger by entering the du command with the value of parameter 2

Copy the text returned by the du command and paste it into a blank notepad document

Remove the debugger text in notepad to leave only the XML text from the print capabilities document

Save the XML text as a file

Evaluate the XML text using PTConform, a tool that is available in the Windows Driver Kit

Information displayed by Application Verifier

Format: - This verifier stop was caused when the core driver called the plug-in's %lS method

Parameter 1 - Error messages returned by PTConform. Use du to dump the message if this parameter is not NULL.

Parameter 2 - PrintCapabilities XML text. Use du to dump the XML if this parameter is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D01A

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


The plug-in returned an invalid PrintTicket to the core driver

Application Verifier break message

The plug-in returned an invalid PrintTicket to the core driver

Probable cause

This verifier stop occurs when a PrintTicket document that was returned to the core driver from the plug-in did not conform to the PrintSchema.

Troubleshooting Steps

Dump the XML print ticket text in the debugger by entering the du command with the value of parameter 2

Copy the text returned by the du command and paste it into a blank notepad document

Remove the debugger text in notepad to leave only the XML text from the print ticket

Save the XML text as a file

Evaluate the XML text using PTConform, a tool that is available in the Windows Driver Kit.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the %lS method in the plug-in module at %lS

Parameter 1 - Error messages returned by PTConform. Use du to dump the message if this parameter is not NULL.

Parameter 2 - PrintTicket XML text. Use du to dump the XML if this parameter is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D019

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Core driver sent an invalid PrintTicket to the plug-in

Application Verifier break message

Core driver sent an invalid PrintTicket to the plug-in

Probable cause

This verifier stop occurs when a PrintTicket document that was sent from the core driver to the plug-in did not conform to the PrintSchema. Report this error to Microsoft because it could be a problem in Microsoft's core printer driver module.

Information displayed by Application Verifier

Format: - This verifier stop was caused when the core driver called the plug-in's %lS method

Parameter 1 - Error messages returned by PTConform. Use du to dump the message if this parameter is not NULL.

Parameter 2 - PrintTicket XML text. Use du to dump the XML if this parameter is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintDriver

Stop code: 0000D018

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


A call to a printer driver changed the security context

.

Application Verifier break message

A call to a printer driver changed the security context

Probable cause

This stop usually occurs when a print driver calls either RevertToSelf() or RevertToPrinterSelf() but did not change the security context back to impersonating the user by calling ImpersonatePrinterClient(). This is not allowed and print spooler behavior is undefined after this happens. This can also create a security vulnerability and allow a remote authenticated elevation of privilege type of attack.

Information displayed by Application Verifier

Format: - This verifier stop was caused by the '%lS' method in the plug-in module at '%lS'

Parameter 1 - Account name at driver entry. Type 'du address' to dump it if not NULL.

Parameter 2 - Account name at driver exit. Type 'du address' to dump it if not NULL.

Parameter 3 - Security token at driver entry

Parameter 4 - Security token at driver exit

Additional information

Stop code: D025


Print filter sent an invalid PrintTicket to pipeline manager

Application Verifier break message

Print filter sent an invalid PrintTicket to pipeline manager

Probable cause

This verifier stop occurs when SetPrintTicket sends an IPrintTicketPart part to a method and the content of the IPrintTicketpart does not conform to the PrintSchema.

Information displayed by Application Verifier

Format: - This verifier stop was in %lS method. Use GUID to identify Print filter.

Parameter 1 - Print Filter GUID. Use dd to dump it if this parameter is not NULL.

Parameter 2 - Error messages returned by PTConform. Use du to dump the message if this parameter is not NULL.

Parameter 3 - PrintTicket XML text. Use du to dump the XML if this parameter is not NULL.

Parameter 4 - Not used.

Additional information

Stop code: D026


Print filter received an invalid PrintTicket from pipeline manager

Application Verifier break message

Print filter received an invalid PrintTicket from pipeline manager

Probable cause

This verifier stop occurs when the GetPrintTicket method returns an IPrintTicketPart from the printer driver filter and the content of the IPrintTicketPart does not conform to the PrintSchema.

Information displayed by Application Verifier

Format: - This verifier stop was in %lS method. Use GUID to identify Print filter.

Parameter 1 - Print Filter GUID. Use dd to dump it if this parameter is not NULL.

Parameter 2 - Error messages returned by PTConform. Use du to dump the message if this parameter is not NULL.

Parameter 3 - PrintTicket XML text. Use du to dump the XML if this parameter is not NULL.

Parameter 4 - Not used.

Additional information

Stop code: D027


Unloading print driver DLL with active COM callback.

Application Verifier break message

Unloading print driver DLL with active COM callback

Probable cause

A positive reference count was detected on a COM interface when the target module was unloaded. This is probably caused by an incorrect implementation of DllCanUnloadNow or incorrect reference counting.

Information displayed by Application Verifier

Format: - This verifier stop was caused by %lS module unload while the system still holds a %lS pointer to it.

Parameter 1 - COM interface address.

Parameter 2 - Stack trace where callback was provided. Use dps to dump the stack trace if it is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: D028


Attempt to use a released COM interface

Application Verifier break message

Attempt to use a released COM interface

Probable cause

A COM interface was used after it was released.

Troubleshooting Steps

Try to identify the routine that tried to use the released COM interface:

  • Dump the current stack trace by using the 'k' command in the debugger

  • Identify the routine that tried to use the released interface.

Use the dps command with the second parameter of the stop if available to dump the stack trace of the routine that released the COM interface.

Information displayed by Application Verifier

Format: - This verifier stop was caused by %lS interface being used after release.

Parameter 1 - COM interface address.

Parameter 2 - Stack trace of the Release call when reference count went to zero. Use dps to dump the stack trace if it is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: D029

Severity: Error


A print driver called ExitThread

Application Verifier break message

A print driver called ExitThread

Probable cause

When a print driver calls ExitThread, the thread is exited before any destructors can be called or any other automatic cleanup can be performed. This can lead to undefined behavior. Therefore, print drivers should always return from their thread functions.

Troubleshooting steps

Use the k debugger command to dump the stack trace and identify the routine that called ExitThread.

Information displayed by Application Verifier

Parameter 1 - Not used.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: D02A


A print driver called TerminateThread

Application Verifier break message

A print driver called TerminateThread

Probable cause

A print driver called TerminateThread, which is used to cause a thread to exit. When this occurs, the target thread has no chance to execute any user-mode code.

Troubleshooting steps

Use the k debugger command to dump the stack trace and identify the routine that called TerminateThread.

Information displayed by Application Verifier

Parameter 1 - Not used.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: D02B

When TerminateThread is called, DLLs that are attached to a thread are not notified that the thread is terminating. The system frees the thread's initial stack. TerminateThread is a dangerous function that should be used only in the most extreme cases. TerminateThread can result in the following problems:

  • If the target thread owns a critical section, the critical section will not be released.

  • If the target thread is allocating memory from the heap, the heap lock will not be released.

  • If the target thread is executing certain kernel32 calls when it is terminated, the kernel32 state for the thread's process could be inconsistent.

  • If the target thread is manipulating the global state of a shared DLL, the state of the DLL could be destroyed, which would affect other users of the DLL.


Print filter changed the COM apartment type for the current thread

Application Verifier break message

Print filter changed the COM apartment type for the current thread

Probable cause

This verifier stop occurs when a print filter changes the COM apartment type in one of its methods (InitializeFilter, StartOperation, or ShutdownOperation).

Troubleshooting steps

Use the ln Parameter 1 command in the debugger to identify the name of the print filter DLL.

Information displayed by Application Verifier

Parameter 1 - Filter interface pointer.

Parameter 2 - Expected apartment type.

Parameter 3 - Actual apartment type.

Parameter 4 - Not used.

Additional information

Stop code: D02C


COM is not initialized for the current thread after call to print filter method

Application Verifier break message

COM is not initialized for the current thread after call to print filter method

Probable cause

This verifier stop occurs when a print filter has unbalanced CoInitialize[Ex] and CoUninitialize calls. This could be due to CoInitialize[Ex] unexpectedly returning failure, such as when the requestd apartment type does not match the thread's current type.

Troubleshooting steps

Use ln Parameter 1 to find the filter.

Information displayed by Application Verifier

Parameter 1 - Filter interface pointer.

Parameter 2 – Not used.

Parameter 3 – Not used.

Parameter 4 - Not used.

Additional information

Stop code: D02D


Print driver has mismatch of AddRef/Release calls of PT/PC XML Document

Application Verifier break message

Print driver has mismatch of AddRef/Release calls of PT/PC XML Document

Troubleshooting steps

If Parameter 1 is not NULL, use du Parameter 1 to display the name of the offending method.

If Parameter 2 is not NULL, use du Parameter 2 to display the XML document type.

Information displayed by Application Verifier

Parameter 1 - Name of offending method call.

Parameter 2 – Type of XML Document.

Parameter 3 – Current reference count.

Parameter 4 - Expected reference count.

Additional information

Stop code: D02E


PrintAPI Test Layer Stop Details
See Also

When Application Verifier is run on a solution or project in the Print, the Print Verifier provides a stop code when an error is found. The stop codes that may be encountered in the PrintAPIr test layer are listed in the following table. Refer to the specific error message to learn more about the details of the stop.

PrintAPI test layer messages

Error message | Stop code
Leaked printer handle detected | 0000A000
Leaked printer change notification handle detected | 0000A001
Leaked PRINTER_NOTIFY_INFO detected | 0000A002
Race condition detected while using a printer handle | 0000A003
Potential multi-threaded access to a printer handle detected | 0000A004
Attempt to use a closed printer handle | 0000A005
Attempt to use an unknown printer handle | 0000A006
Attempt to use a closed printer change notification handle | 0000A007
Attempt to use an invalid printer change notification handle | 0000A008
Attempt to use a freed PRINTER_NOTIFY_INFO object | 0000A009
Attempt to use an invalid PRINTER_NOTIFY_INFO object | 0000A00A
Too many open printer handles. | 0000A00B
OpenPrinter2W seems to be exported from winspool.drv of an earlier version of Microsoft Windows | 0000A00C
Too many open PrintTicket provider handles (HPTPROVIDER) | 0000A00D
Attempt to use a closed PrintTicket provider handle (HPTPROVIDER) | 0000A00E
Attempt to use an unknown PrintTicket provider handle (HPTPROVIDER) | 0000A00F
Race condition detected while using a PrintTicket provider handle | 0000A010
Potential multi-threaded access to a PrintTicket provider handle detected | 0000A011
Leaked PrintTicket provider handle detected | 0000A012
Too many open printer change notification handles | 0000A013
Too many open PRINTER_NOTIFY_INFO objects | 0000A014
Attempt to use an invalid PrintTicket | 0000A015
Attempt to use an invalid PrintCapabilities document | 0000A016
An invalid NULL argument was passed to a PrintTicket method | 0000A017
PTConform encountered an unexpected error (PrintAPI) | 0000A018
Illegal print API called from DllMain | 0000A019
Leaked spool file handle detected | 0000A01A
Attempt to use a closed spool file handle | 0000A01B
Attempt to use an unknown spool file handle | 0000A01C
Too many open spool file handles | 0000A01D
DEVMODE buffer parameter spans across non-readable memory page(s) | 0000A01E
Unloading module with active COM callback | 0000A01F
Async Notify handle returned by RegisterForPrintAsyncNotifications was not released properly | 0000A020
Attempt to use an invalid handle in UnRegisterForPrintAsyncNotifications | 0000A021
Attempt to use a closed handle in UnRegisterForPrintAsyncNotifications API function | 0000A022
Third-party function reports failure but increases reference count for input interface | 0000A023
Windows API function reports failure but increases reference count for input interface | 0000A024
IPrintAsyncNotifyChannel contract violation by the operating system | 0000A025
IPrintAsyncNotifyChannel contract violation by channel consumer | 0000A026
Race detected during closing of IPrintAsyncNotifyChannel | 0000A027
Calling a print API that makes network calls on a GUI thread | 0000A028
Calling an API that will pop up user interface in Session0 | 0000A029

See Also

Concepts

PrintDriver Test Layer Stop Details


Leaked printer handle detected

Application Verifier break message

Leaked printer handle detected

Probable cause

An open printer handle was detected when the application terminated. Most likely, the creating thread did not call ClosePrinter() to close the printer handle.

Troubleshooting steps

To troubleshoot this stop,

  • Determine the thread that opened the printer handle by using the second parameter of this verifier stop to provide the stack trace.

  • Dump the stack trace using the dps command in the debugger.

  • Find the first non-winspool and non-vfPrint module name that called vfPrint!VfHookOpenPrinter* or vfPrint!VfHookAddPrinter* - this typically is the 4th or the 6th stack frame in the list.

For example:

Copy Code
=======================================
VERIFIER STOP 0000A000 : pid 0x13E4: Leaked printer handle detected

        0BEFCF8C : Printer handle being leaked.
        02956F50 : Initialization stack trace. Use dps to dump it if not NULL.
        00001698 : Thread id of the thread that opened the handle.
        00000000 : Not used.
=======================================
0:000> dps 02956F50
02956f50  0243527a vfPrint!CItemTracker(void *)::Init+0x6a
02956f54  02434e30 vfPrint!CHandleTracker_t(void *)::Init+0x20
02956f58  02433173 vfPrint!VfHookOpenPrinter2W+0x83
02956f5c  72b16dbf WINSPOOL!OpenPrinterW+0x16   !this is the first caller of vfPrint!VfOpenPrinter*, but it doesn't count because it's from winspool.
02956f60  02433091 vfPrint!VfHookOpenPrinterW+0x71
02956f64  7436e060 PRINTUI!OpenPrinterWrap+0x9b    !this is the suspect, as this is the first non-winspool and non-vfPrint caller of vfPrint!VfHookOpenPrinterW
02956f68  7433fffb PRINTUI!TPrinter::svReopen+0x6c

Information displayed by Application Verifier

Parameter 1 - Printer handle being leaked.

Parameter 2 - Initialization stack trace. Use dps to dump the stack if this parameter is not NULL.

Parameter 3 - Thread id of the thread that opened the handle.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A000

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Leaked printer change notification handle detected

Application Verifier break message

Leaked printer change notification handle detected.

Probable cause

A printer change notification handle that was not closed was detected when the application exited. Most likely the thread that opened the handle did not call FindClosePrinterChangeNotification() to close the handle before the thread exited.

Troubleshooting steps

To troubleshoot this stop:

  • Determine the thread that opened the printer change notification handle.

    • The second parameter of this stop provides the stack address.

    • Use the dps command to dump the stack trace.

  • Find the first non-winspool and non-vfPrint module name that called vfPrint!VfHookFindFirstPrinterChangeNotification. This is typically found in the 4th stack frame.

For example:

Copy Code
=======================================
VERIFIER STOP 0000A001 : pid 0x13E4: Leaked printer change notification handle detected

        00000040 : Printer change notification handle being leaked.
        02946F50 : Initialization stack trace. Use dps to dump the stack trace if it is not NULL.
        00001040 : Thread id of the last thread using it.
        00000000 : Not used.
======================================
0:000> dps 02946F50
02946f50  0243527a vfPrint!CItemTracker(void *)::Init+0x6a
02946f54  02434e30 vfPrint!CHandleTracker_t(void *)::Init+0x20
02946f58  02434649 vfPrint!VfHookFindFirstPrinterChangeNotification+0x69
02946f5c  7433e548 PRINTUI!VDataNotify::svNotifyStart+0x23 --------- this is the routine that is suspected of creating and not freeing a printer change notification handle

Information displayed by Application Verifier

Parameter 1 - Printer change notification handle being leaked.

Parameter 2 - Initialization stack trace. Use dps to dump the stack trace if it is not NULL.

Parameter 3 - Thread id of the last thread using it.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A001

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Leaked PRINTER_NOTIFY_INFO detected

Application Verifier break message

Leaked PRINTER_NOTIFY_INFO detected.

Probable cause

An allocated PRINTER_NOTIFY_INFO object that had not been freed was detected when the program exited. Most likely, it needs to be freed by calling FreePrinterNotifyInfo() before exiting.

Troubleshooting steps

To troubleshoot this stop:

  • Determine the routine that called winspool to allocate the PRINTER_NOTIFY_INFO object on its behalf by using the second parameter of this verifier stop.

  • Dump the initialization stack trace using the dps command in the debugger.

  • Find the first non-winspool and non-vfPrint module name that called vfPrint!VfHookFindNextPrinterChangeNotification. This routine is typically found in the 3rd stack frame.

For example:

Copy Code
=======================================
VERIFIER STOP 0000A002 : pid 0x158C: Leaked PPRINTER_NOTIFY_INFO detected

        0C697E90 : The pointer to the leaked PRINTER_NOTIFY_INFO.
        0295EF60 : Initialization stack trace. Use dps to dump it if it is not NULL.
        00000000 : Not used.
        00000000 : Not used.
=======================================
0:000> dps 0295EF60
0295ef60  0243505a vfPrint!CItemTracker(_PRINTER_NOTIFY_INFO *)::Init+0x6a
0295ef64  024347c0 vfPrint!VfHookFindNextPrinterChangeNotification+0x70
0295ef68  7433e2c5 PRINTUI!VDataNotify::svRefresh+0x4c   ------- this routine is suspected of not freeing the object
0295ef6c  7433d97b PRINTUI!VData::svNew+0x53

Information displayed by Application Verifier

Parameter 1 - The pointer to the leaked PRINTER_NOTIFY_INFO object.

Parameter 2 - Initialization stack trace. Use dps to dump the stack trace if it is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A002

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Race condition detected while using a printer handle

Application Verifier break message

Race condition detected while using a printer handle

Probable cause

A printer handle is being used concurrently in multiple threads.

Printer handles are not thread safe which means that simultaneous use of a printer handle in multiple threads is not permitted without application-level synchronization to safely coordinate access to the handle. The application should either open a separate printer handle in each thread or provide custom synchronization access to the printer handle by using the Microsoft Win32 synchronization API.

The Win32 synchronization API is described further at http://go.microsoft.com/fwlink/?LinkId=68570.

Troubleshooting steps

The sample debugger output below illustrates the following troubleshooting steps:

  • Verify the stack trace of each thread that used that printer handle by using the k command. These threads are described by parameters 2 and 3 of the Verifier Stop.

  • Dump the stack trace for each suspected thread and locate the routine that accessed the printer handle

  • Review the source code of the suspected routines to identify what allowed the concurrent access.

Copy Code
=======================================
VERIFIER STOP 0000A003 : pid 0xAB4: Race condition detected while using a printer handle

        078EAF84 : Printer handle being accessed.
        0000098C : Current thread id.
        00000944 : Thread id of the concurrent thread.
        00000002 : Concurrency count.
=======================================

* List the threads:
*    thread id 98C is the current thread, Param 2 (Note “.” denotes current thread)
*    thread id 944 in the concurrent thread, Param 3

0:002> ~
   0  Id: ab4.2c0 Suspend: 1 Teb: 7ffde000 Unfrozen
   1  Id: ab4.b24 Suspend: 1 Teb: 7ffdd000 Unfrozen
.  2  Id: ab4.98c Suspend: 1 Teb: 7ffdc000 Unfrozen*Suspect thread #1
   3  Id: ab4.944 Suspend: 1 Teb: 7ffdb000 Unfrozen*Suspect thread #2
   4  Id: ab4.8d4 Suspend: 1 Teb: 7ffd9000 Unfrozen
   5  Id: ab4.bcc Suspend: 1 Teb: 7ffda000 Unfrozen
   7  Id: ab4.ca4 Suspend: 1 Teb: 7ffd7000 Unfrozen
   8  Id: ab4.e6c Suspend: 1 Teb: 7ffd6000 Unfrozen

* The debugger is on the 2nd thread as indicated by the 0:002> command prompt
* Use the k command to dump the stack of this thread or use the ~2s command to
*   change threads

0:002> k
ChildEBP RetAddr
04d0da3c 73de3855 ntdll!DbgBreakPoint
04d0dc40 73cf625e vrfcore!VerifierStopMessageEx+0x4bd
04d0dc64 73cf70f7 vfprint!CHandleTracker_t<void *>::CheckConcurentUse+0x34
04d0dc7c 73cf7caa vfprint!CResourceUsageMgr<void *,CHandleTracker_t<void *> >::PreHandleApiCallHelper+0x2a
04d0dc98 00a5ce5c vfprint!VfHookWritePrinter+0x33
04d0dcb0 00a70779 PrintFilterPipelineSvc!SplReadWrite::SequentialSpoolReaderWriter::Write+0x26 *Suspect routine
04d0dccc 00a63193 PrintFilterPipelineSvc!XpsStreamToPipelineStream::Receive+0x1f

* Switch to concurrent thread, 3 in this case, by using the ~ thread command
0:003> ~3s
eax=c0c0c0c0 ebx=0a344ef4 ecx=00000008 edx=00000000 esi=06110eb0 edi=0a344e88
eip=77c2d804 esp=042ef29c ebp=042ef2c8 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
ntdll!KiFastSystemCallRet:
77c2d804 c3              ret

* and dump the stack of the concurrent thread by using the k command
0:005> k
ChildEBP RetAddr
042ef298 77c2bbbc ntdll!KiFastSystemCallRet
042ef29c 77717df9 ntdll!ZwAlpcSendWaitReceivePort+0xc
042ef2c8 7770396d RPCRT4!LRPC_CASSOCIATION::AlpcSendWaitReceivePort+0x24
042ef304 77786b13 RPCRT4!LRPC_CCALL::SendReceive+0x177
042ef314 7779221f RPCRT4!LRPC_CCALL_AVRF::SendReceive+0x26
042ef800 7136680a RPCRT4!NdrClientCall2+0xc49
042ef81c 7135ced1 WINSPOOL!RpcEndDocPrinter+0x1a
042ef860 73cf7fd4 WINSPOOL!EndDocPrinter+0xed
042ef878 00a5a61a vfprint!VfHookEndDocPrinter+0x36
042ef890 00a5a808  PrintFilterPipelineSvc!SplPipeline::SplFilterPipelineCallObject::CleanSpoolerHandles+0x3e *Suspect routine
042ef8a4 77c0fdbd PrintFilterPipelineSvc!SplPipeline::SplFilterPipelineCallObject::CallSignalInMtaThread+0x25
042ef908 77c36b1c ntdll!RtlpTpWorkCallback+0xbf
042efa30 765a333d ntdll!TppWorkerThread+0x522
042efa3c 77c0a8d5 KERNEL32!BaseThreadInitThunk+0xe
042efa7c 00000000 ntdll!_RtlUserThreadStart+0x23

Information displayed by Application Verifier

Parameter 1 - Printer handle being accessed.

Parameter 2 - Current thread id.

Parameter 3 - Thread id of the concurrent thread.

Parameter 4 - Concurrency count.

Additional information

Test Layer: PrintAPI

Stop code: 0000A003

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Potential multi-threaded access to a printer handle detected

Application Verifier break message

Potential multi-threaded access to a printer handle detected

Probable cause

A printer handle was used in a different thread than the thread that created it.

Printer handles are not thread safe which means that simultaneous use of a printer handle in multiple threads is not permitted without application-level synchronization to safely coordinate access to the handle. The application should either open a separate printer handle in each thread or provide custom synchronization access to the printer handle by using the Microsoft Win32 synchronization API.

The Win32 synchronization API is described further at http://go.microsoft.com/fwlink/?LinkId=68570.

Information displayed by Application Verifier

Parameter 1 - Printer handle being accessed.

Parameter 2 - Thread id of the initializing thread.

Parameter 3 - Stack trace of the initialization.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A004

Severity: Warning

One-time error: no

Error report: None

Log to file: yes

Create backtrace: yes


Attempt to use a closed printer handle

Application Verifier break message

Attempt to use a closed printer handle

Probable cause

A printer handle was used after it had been closed.

Troubleshooting steps

To identify the routine that tried to use the closed printer handle, dump the current stack trace by using the ‘k' command in the debugger.

To dump the stack trace of the routine that closed the handle, use the dps command with the second parameter of the stop.

For example:

Copy Code
=======================================
VERIFIER STOP 0000A005 : pid 0x884: Attempt to use a closed printer handle
        035C6F8C : Printer handle being accessed.
        02902F50 : Stack trace of the closing. Use dps to dump the stack trace if it is not NULL.
        00000000 : Not used.
        00000000 : Not used.
=======================================
0:000> k
ChildEBP RetAddr
0006fda0 024124f2 ntdll!DbgBreakPoint
0006fdd4 024134de vfprint!CResourceUsageMgr(void *,CHandleTracker_t(void *) )::ClosedHandleCheck+0xa2
0006fe84 010026f2 vfprint!VfHookClosePrinter+0x16e
0006fe94 0100266c UnitTest! TestFunc +0x32      ------------------- touching already closed handle!! This is a bug.
0006ff5c 01003eb1 UnitTest!wmain+0x34c
0006ffa0 77e4ee88 UnitTest!__tmainCRTStartup+0x10f
0006ffac 77f44f2a KERNEL32!BaseThreadInitThunk+0x12
0006ffec 00000000 ntdll!RtlSetThreadPreferredUILanguages+0x5c1

0:000> dps 2902f50
02902f50  0241e9db vfprint!CaptureStack+0x1b
02902f54  024133d7 vfprint!VfHookClosePrinter+0x67
02902f58  010026e9 UnitTest!TestFunc+0x29  ---------------- This is the code that closed the handle.
02902f5c  0100266c UnitTest!wmain+0x34c
02902f60  01003eb1 UnitTest!__tmainCRTStartup+0x10f
02902f64  77e4ee88 KERNEL32!BaseThreadInitThunk+0xe
02902f68  77f44f2a ntdll!_RtlUserThreadStart+0x23

Information displayed by Application Verifier

Parameter 1 - Printer handle being accessed.

Parameter 2 - Stack trace of the closing. Use dps to dump the stack trace if it is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A005

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Attempt to use an unknown printer handle

Application Verifier break message

Attempt to use an unknown printer handle

Probable cause

An attempt was made to use a printer handle that was not opened by calling OpenPrinterA, OpenPrinterW, OpenPrinter2W (on Microsoft Windows Vista), AddPrinterA, or AddPrinterW.

Troubleshooting steps

To see the stack trace of the routine that attempted this action, use the ‘k' command in the debugger. The sample debugger output illustrates the following troubleshooting steps:

  • Examine the stack trace to find the function that includes the printer handle from Parameter 1 in the argument list.

  • Find the routine that includes this function and examine the source code to determine the open function used to open the handle and correct it if necessary.

Copy Code
=======================================
VERIFIER STOP 0000A006 : pid 0x1398: Attempt to use an unknown printer handle

        031B4C00 : Printer handle being accessed.
        00000000 : Not used.
        00000000 : Not used.
        00000000 : Not used.
=======================================
0:000> k
ChildEBP RetAddr
0024f80c 7332385b ntdll!DbgBreakPoint
0024fa10 71366481 vrfcore!VerifierStopMessageEx+0x4bd
0024fa48 713678b0 vfprint!CResourceUsageMgr<void *,CHandleTracker_t<void *> >::ClosedHandleCheck+0xc7
0024fa64 001432cc vfprint!VfHookGetPrinterW+0x5c
000efae4 00142edc UnitTestvfPrint!UseCompletelyInvalidPrinterHandle+0x4c * Unknown printer handle used
000efbdc 001450b6 UnitTestvfPrint!wmain+0x3dc
000efc20 76413833 UnitTestvfPrint!__wmainCRTStartup+0x102
000efc2c 775fa9bd KERNEL32!BaseThreadInitThunk+0xe
000efc6c 00000000 ntdll!_RtlUserThreadStart+0x23

Information displayed by Application Verifier

Parameter 1 - Printer handle being accessed.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A006

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Attempt to use a closed printer change notification handle

Application Verifier break message

Attempt to use a closed printer change notification handle

Probable cause

A printer change notification handle was used after it had been closed.

A printer change notification handle is the handle to an object that is returned by the FindFirstPrinterChangeNotification function and used to signal a program when the status of a printer has changed. After this handle has been closed, it can no longer be used by the program.

Troubleshooting steps

The sample debugger output below illustrates the following troubleshooting steps:

  • To see the routine that tried to use the closed printer change notification handle, dump the current stack trace by using the ‘k' command in the debugger.

  • To dump the stack trace of the routine that closed the handle, use the dps command with the second parameter of the stop.

After you identify the routine that closed the handle, review the source code to determine why the handle was used after it was closed in the routine identified in the previous step and make the corrections that are necessary to prevent this.

Copy Code
=======================================
VERIFIER STOP 0000A007 : pid 0x1484: Attempt to use a closed printer change notification handle

        00000364 : Printer change notification handle being accessed.
        02EDFF48 : Stack trace of the closing. Use dps to dump the stack trace if it is not NULL.
        00000000 : Not used.
        00000000 : Not used.
=======================================

0:000> k
ChildEBP RetAddr
0026f3b0 7332385b ntdll!DbgBreakPoint
0026f5b4 71366431 vrfcore!VerifierStopMessageEx+0x4bd
0026f5ec 7136839d vfprint!CResourceUsageMgr<void *,CHandleTracker_t<void *> >::ClosedHandleCheck+0x77
0026f690 00143327 vfprint!VfHookFindClosePrinterChangeNotification+0x111
0026f6a4 00142edc UnitTestvfPrint!UseChangeNotificationHandleAfterClose+0x37 * The routine that tried to use the closed printer change notification handle

0:000> dps 02EDFF48
02edff48  7137cc12 vfprint!CaptureStack+0x17
02edff4c  713682da vfprint!VfHookFindClosePrinterChangeNotification+0x4e
02edff50  0014331e UnitTestvfPrint!UseChangeNotificationHandleAfterClose+0x2e * The routine that closed the printer change notification handle

Information displayed by Application Verifier

Parameter 1 - Printer change notification handle being accessed.

Parameter 2 - Stack trace of the closing. Use dps to dump the stack trace if it is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A007

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Attempt to use an invalid printer change notification handle

Application Verifier break message

Attempt to use an invalid printer change notification handle

Probable cause

A handle that was not opened with the FindFirstPrinterChangeNotification Microsoft Win32 API function was passed as a printer change notification handle.

Troubleshooting steps

The sample debugger output below illustrates the following troubleshooting steps:

  • To see the stack trace of the routine that attempted this action, use the ‘k' command in the debugger.

  • Identify the routine by locating the function call in the stack trace that references the handle identified by Parameter 1.

After you identify the routine that references the handle, find this routine in the source code and determine why an invalid handle was used.

Copy Code
=======================================
VERIFIER STOP 0000A008 : pid 0x1268: Attempt to use an invalid printer change notification
 handle

        00001237 : Printer change notification handle being accessed.
        00000000 : Not used.
        00000000 : Not used.
        00000000 : Not used.
=======================================

0:000> k
ChildEBP RetAddr
0020f5f8 7332385b ntdll!DbgBreakPoint
0020f7fc 71366481 vrfcore!VerifierStopMessageEx+0x4bd
0020f834 7136839d vfprint!CResourceUsageMgr<void *,CHandleTracker_t<void *> >::ClosedHandl
eCheck+0xc7
0020f8d8 0014335f vfprint!VfHookFindClosePrinterChangeNotification+0x111
0020f8e4 00142edc UnitTestvfPrint!CloseANonExistingNotificationHandle+0xf * The routine that uses invalid printer change notification handle

Information displayed by Application Verifier

Parameter 1 - Printer change notification handle being accessed.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A008

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Attempt to use a freed PRINTER_NOTIFY_INFO object

Application Verifier break message

Attempt to use a freed PRINTER_NOTIFY_INFO object

Probable cause

A PRINTER_NOTIFY_INFO object was used after it has been freed.

Troubleshooting steps

The sample debugger output below illustrates the following troubleshooting steps:

  • To see the routine that tried to use the freed PRINTER_NOTIFY_INFO object, dump the current stack trace by using the ‘k' command in the debugger.

  • To dump the stack trace of the routine that closed the handle, use the dps command with the second parameter of the stop.

Copy Code
=======================================
VERIFIER STOP 0000A009 : pid 0x1B8: Attempt to use a freed PRINTER_NOTIFY_INFO object

        040CEFA8 : Address of the PRINTER_NOTIFY_INFO being accessed.
        02F81F58 : Stack trace of the closing. Use dps to dump the stack trace if it is not NULL.
        00000000 : Not used.
        00000000 : Not used.
=======================================

0:000> k
ChildEBP RetAddr
000cf628 7332385b ntdll!DbgBreakPoint
000cf82c 7136708e vrfcore!VerifierStopMessageEx+0x4bd
000cf860 713684a4 vfprint!CResourceUsageMgr<_PRINTER_NOTIFY_INFO *,CItemTracker<_PRINTER_N
OTIFY_INFO *> >::ClosedHandleCheck+0x49
000cf904 0014352a vfprint!VfHookFreePrinterNotifyInfo+0xf1
000cf914 00142edc UnitTestvfPrint!UsePRINTER_NOTIFY_INFOAfterClose+0x2a * The routine that tried to use the freed PRINTER_NOTIFY_INFO object

0:000> dps 02F81F58
02f81f58  7137cc12 vfprint!CaptureStack+0x17
02f81f5c  713683f9 vfprint!VfHookFreePrinterNotifyInfo+0x46
02f81f60  00143521 UnitTestvfPrint!UsePRINTER_NOTIFY_INFOAfterClose+0x21 * The routine that freed the PRINTER_NOTIFY_INFO object

Information displayed by Application Verifier

Parameter 1 - Address of the PRINTER_NOTIFY_INFO being accessed.

Parameter 2 - Stack trace of the closing. Use dps to dump the stack trace if it is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A009

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Attempt to use an invalid PRINTER_NOTIFY_INFO object

Application Verifier break message

Attempt to use an invalid PRINTER_NOTIFY_INFO object

Probable cause

The PRINTER_NOTIFY_INFO object was not opened by the FindNextPrinterChangeNotification Microsoft Win32 API function.

Troubleshooting steps

The sample debugger output below illustrates the following troubleshooting steps:

  • To see the stack trace of the routine that attempted this action, use the ‘k' command in the debugger.

  • Identify the routine by locating the function call in the stack trace that references the PRINTER_NOTIFY_INFO structure identified by Parameter 1.

After you identify the routine, find the routine in the source code and determine why an invalid structure was used.

Copy Code
=======================================
VERIFIER STOP 0000A00A : pid 0x15B4: Attempt to use an invalid PRINTER_NOTIFY_INFO object

        031D4C00 : Address of the PRINTER_NOTIFY_INFO being accessed.
        00000000 : Not used.
        00000000 : Not used.
        00000000 : Not used.
=======================================

0:000> k
ChildEBP RetAddr
0024f690 7175385b ntdll!DbgBreakPoint
0024f894 6eed70b5 vrfcore!VerifierStopMessageEx+0x4bd
0024f8c8 6eed84a4 vfprint!CResourceUsageMgr<_PRINTER_NOTIFY_INFO *,CItemTracker<_PRINTER_N
OTIFY_INFO *> >::ClosedHandleCheck+0x70
0024f96c 001434e0 vfprint!VfHookFreePrinterNotifyInfo+0xf1
0024f984 00142edc UnitTestvfPrint!UseNonExistingPRINTER_NOTIFY_INFO+0x40 * This is the suspect

Information displayed by Application Verifier

Parameter 1 - Address of the PRINTER_NOTIFY_INFO being accessed.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A00A

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Too many open printer handles.

Application Verifier break message

Too many open printer handles.

Probable cause

Too many printer handles were opened. There might be a resource leak.

The following sample debugger output shows the AppVerifier message that is displayed when 0x000003EB (1003) printer handles have been opened. In this case, AppVerifier would show this warning three times, one for each handle that is opened after 1,000 handles were open.

Copy Code
=======================================
VERIFIER STOP 0000A00B : pid 0xC8C: Too many open printer handles

        000003EB : Number of currently open printer handles.
        00000000 : Not used.
        00000000 : Not used.
        00000000 : Not used.
=======================================

Troubleshooting Steps

This stop is a warning. It might be normal to have more than 1,000 open printer handles if the print server has many printers or it might be the result of a resource leak. A resource leak could be caused by not calling ClosePrinter when necessary. If you think that the number of open printer handles is too high for the number of printers then review the source code to determine if the printer handles are being opened and closed correctly.

Information displayed by Application Verifier

Parameter 1 - Number of currently open printer handles.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A00B

Severity: Warning

One-time error: no

Error report: None

Log to file: yes

Create backtrace: yes


OpenPrinter2W seems to be exported from winspool.drv of an earlier version of Microsoft Windows

Application Verifier break message

OpenPrinter2W seems to be exported from winspool.drv of an earlier version of Microsoft Windows

Probable cause

OpenPrinter2W should only be called on Windows Vista and later versions of Microsoft Windows. Report this error to Microsoft.

Information displayed by Application Verifier

Parameter 1 - Not used.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A00C

Severity: Error

One-time error: no

Non Continuable: yes

Error report: Break

Log to file: yes

Create backtrace: yes


Too many open PrintTicket provider handles (HPTPROVIDER)

Application Verifier break message

Too many open PrintTicket provider handles (HPTPROVIDER)

Probable cause

Too many PrintTicket provider handles were opened by calling PTOpenProvider(Ex). This might be the result of not calling PTCloseProvider when the handle is no longer needed, creating a resource leak.

The following sample debugger output shows the AppVerifier message that is displayed when 0x000003EB (1003) PrintTicket handles have been opened. In this case, AppVerifier would show this warning three times, one for each handle that is opened after 1,000 handles were open.

=======================================

VERIFIER STOP 0000A00D : pid 0xFBC: Too many open PrintTicket provider handles (HPTPROVIDER)

000003EB : Number of currently opened PrintTicket provider handles.

00000000 : Not used.

00000000 : Not used.

00000000 : Not used.

=======================================

Troubleshooting Steps

This stop is a warning. It might be normal to have more than 1,000 PrintTicket provider handles if the print server has many printers or it might be the result of a resource leak. A resource leak could be caused by not calling PTCloseProvider when necessary. If you think that the number is too high for the number of printers, then review the source code to determine if the print ticket provider handles are being opened and closed correctly.

Information displayed by Application Verifier

Parameter 1 - Number of currently opened PrintTicket provider handles.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A00D

Severity: Warning

One-time error: no

Error report: None

Log to file: yes

Create backtrace: yes


Attempt to use a closed PrintTicket provider handle (HPTPROVIDER)

Application Verifier break message

Attempt to use a closed PrintTicket provider handle (HPTPROVIDER)

Probable cause

A PrintTicket provider handle was used after it had been freed.

Troubleshooting steps

The sample debugger output below illustrates the following troubleshooting steps:

  • To see the routine that tried to use the closed PrintTicket provider handler, dump the current stack trace by using the ‘k' command in the debugger.

  • To dump the stack trace of the routine that closed the handle, use the dps command with the second parameter of the stop.

Copy Code
=======================================
VERIFIER STOP 0000A00E : pid 0xB0: Attempt to use a closed PrintTicket provider handle (HPTPROVIDER)

        03216FE8 : HPTPROVIDER handle being accessed.
        02F7BF48 : Stack trace of the closing. Use dps to dump the stack trace if it is not NULL.
        00000000 : Not used.
        00000000 : Not used.
=======================================

0:000> k
ChildEBP RetAddr
001dfa58 7175385b ntdll!DbgBreakPoint
001dfc5c 6eee4237 vrfcore!VerifierStopMessageEx+0x4bd
001dfc90 6eee45f6 vfprint!CResourceUsageMgr<HPTPROVIDER__ *,CHandleTracker_t<HPTPROVIDER__ *> >::ClosedHandleCheck+0x49
001dfd34 00143dc2 vfprint!VfPTCloseProvider+0x111
001dfd44 00142edc UnitTestvfPrint!UseAfterClosePTProviderHandle+0x32 * !This routine tries to uses closed PrintTicket provider handle, a bug
001dfe3c 001450b6 UnitTestvfPrint!wmain+0x3dc
001dfe80 76413833 UnitTestvfPrint!__wmainCRTStartup+0x102
001dfe8c 775fa9bd KERNEL32!BaseThreadInitThunk+0xe
001dfecc 00000000 ntdll!_RtlUserThreadStart+0x23

0:000> dps 02F7BF48
02f7bf48  6eeecc12 vfprint!CaptureStack+0x17
02f7bf4c  6eee4533 vfprint!VfPTCloseProvider+0x4e
02f7bf50  00143db9 UnitTestvfPrint!UseAfterClosePTProviderHandle+0x29 * !The routine that closes the PrintTicket provider handle
02f7bf54  00142edc UnitTestvfPrint!wmain+0x3dc
02f7bf58  001450b6 UnitTestvfPrint!__wmainCRTStartup+0x102
02f7bf5c  76413833 KERNEL32!BaseThreadInitThunk+0xe

02f7bf60 775fa9bd ntdll!_RtlUserThreadStart+0x23

Information displayed by Application Verifier

Parameter 1 - HPTPROVIDER handle being accessed.

Parameter 2 - Stack trace of the closing. Use dps to dump the stack trace if it is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A00E

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Attempt to use an unknown PrintTicket provider handle (HPTPROVIDER)

Application Verifier break message

Attempt to use an unknown PrintTicket provider handle (HPTPROVIDER)

Probable cause

A PrintTicket provider handle was used that was not opened by calling PTOpenProvider or PTOpenProviderEx.

Troubleshooting steps:

The sample debugger output below illustrates how to examine the stack trace to find the function that includes the print ticket provider handle from Parameter 1 in the argument list.

After you identify this function, find the routine that includes this function and examine the source code to determine the open function used to open the handle and correct it if necessary.

Copy Code
=======================================
VERIFIER STOP 0000A00F : pid 0x16CC: Attempt to use an unknown PrintTicket provider handle (HPTPROVIDER)
        031F4C00 : HPTPROVIDER handle being accessed.
        00000000 : Not used.
        00000000 : Not used.
        00000000 : Not used.
=======================================

0:000> k
ChildEBP RetAddr
000df518 7286385b ntdll!DbgBreakPoint
000df71c 6eee425e vrfcore!VerifierStopMessageEx+0x4bd
000df750 6eee45f6 vfprint!CResourceUsageMgr<HPTPROVIDER__ *,CHandleTracker_t<HPTPROVIDER__ *> >::ClosedHandleCheck+0x70
000df7f4 00143f80 vfprint!VfPTCloseProvider+0x111
000df814 00142edc UnitTestvfPrint!UseCompletelyInvalidPTProviderHandle+0x40 * !Unknown or invalid PrintTicket provider handled used here
000df90c 001450b6 UnitTestvfPrint!wmain+0x3dc
000df950 76413833 UnitTestvfPrint!__wmainCRTStartup+0x102
000df95c 775fa9bd KERNEL32!BaseThreadInitThunk+0xe
000df99c 00000000 ntdll!_RtlUserThreadStart+0x23

Information displayed by Application Verifier

Parameter 1 - HPTPROVIDER handle being accessed.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A00F

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Race condition detected while using a PrintTicket provider handle

Application Verifier break message

Race condition detected while using a PrintTicket provider handle

Probable cause

A PrintTicket provider handle was being used concurrently in multiple threads. This requires application-level of synchronization of the access to the handle.

PrintTicket provider handles are not thread safe which means that simultaneous use of a PrintTicket provider handle in multiple threads is not permitted. Instead, the application should either open a separate PrintTicket provider handle in each thread or provide custom synchronization access to the PrintTicket provider handle by using the Microsoft Win32 synchronization API.

The Win32 synchronization API is described further at http://go.microsoft.com/fwlink/?LinkId=68570.

Information displayed by Application Verifier

Parameter 1 - PrintTicket provider handle being accessed.

Parameter 2 - Current thread id.

Parameter 3 - Thread id of the concurrent thread.

Parameter 4 - Concurrency count.

Additional information

Test Layer: PrintAPI

Stop code: 0000A010

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Potential multi-threaded access to a PrintTicket provider handle detected

Application Verifier break message

Potential multi-threaded access to a PrintTicket provider handle detected

Probable cause

This is a warning that a PrintTicket provider handle was used in a thread different from the thread that created it. This may require application-level synchronization to safely access the handle.

PrintTicket provider handles are not thread safe which means that simultaneous use of a PrintTicket provider handle in multiple threads is not permitted. Instead, the application should either open a separate PrintTicket provider handle in each thread or provide custom synchronization access to the PrintTicket provider handle by using the Microsoft Win32 synchronization API.

The Win32 synchronization API is described further at http://go.microsoft.com/fwlink/?LinkId=68570.

Information displayed by Application Verifier

Parameter 1 - PrintTicket provider handle being accessed.

Parameter 2 - Thread id of the initializing thread.

Parameter 3 - Stack trace of the initialization.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A011

Severity: Warning

One-time error: no

Error report: None

Log to file: yes

Create backtrace: yes


Leaked PrintTicket provider handle detected

Application Verifier break message

Leaked PrintTicket provider handle detected

Probable cause

An open PrintTicket provider handle was detected when the thread exited. The creating routine might not have called PTCloseProvider() to close it prior to exiting.

Troubleshooting steps

The sample debugger output below illustrates the following troubleshooting steps:

  • Determine the thread that opened the PrintTicket provider handle by using the second parameter of this verifier stop to provide the stack trace.

  • Dump the stack trace using the dps command in the debugger.

  • Find the first non-prntvpt and non-vfPrint module name that called vfPrint!VfPTOpenProvider or vfPrint!VfPTOpenProviderEx - this typically is the 4th or the 6th stack frame in the list.

Copy Code
=======================================
VERIFIER STOP 0000A012 : pid 0xD68: Leaked PrintTicket provider handle detected

        03320FE8 : PrintTicket provider handle being leaked.
        0312FF48 : Initialization stack trace. Use dps to dump the stack trace if it is not NULL.
        00000CC0 : Thread id of the thread that opened the handle.
        00000000 : Not used.
=======================================

0:000> dps 0312FF48
0312ff48  64ab3db1 vfprint!CItemTracker<HPTPROVIDER__ *>::Init+0x39
0312ff4c  004154fe Test!LeakPrintTicketProviderHandle+0x4e
0312ff50  004119f1 Test!wmain+0x201
0312ff54  00416936 Test!__tmainCRTStartup+0x1a6
0312ff58  0041677d Test!wmainCRTStartup+0xd
0312ff5c  76413833 KERNEL32!BaseThreadInitThunk+0xe
0312ff60  775fa9bd ntdll!_RtlUserThreadStart+0x23

Information displayed by Application Verifier

Parameter 1 - PrintTicket provider handle being leaked.

Parameter 2 - Initialization stack trace. Use dps to dump the stack trace if it is not NULL.

Parameter 3 - Thread id of the thread that opened the handle.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A012

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Too many open printer change notification handles

Application Verifier break message

Too many open printer change notification handles

Probable cause

Too many printer change notification handles were opened. There might be a resource leak. One common form of resource leaks is where a routine will open a printer change notification handle and not close it before exiting.

Troubleshooting Steps

This stop is a warning. It might be normal if the print server has many printers or it might be a resource leak. A resource leak could be caused by not calling FindClosePrinterChangeNotification when necessary. If you think that the number is too high for the number of printers then review the source code to determine if the printer change notification handles are being opened and closed correctly.

Information displayed by Application Verifier

Parameter 1 - Number of currently opened printer change notification handles.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A013

Severity: Warning

One-time error: no

Error report: None

Log to file: yes

Create backtrace: yes


Too many open PRINTER_NOTIFY_INFO objects

Application Verifier break message

Too many open PRINTER_NOTIFY_INFO objects

Probable cause

Too many PRINTER_NOTIFY_INFO objects were opened. There might be a resource leak. One common form of resource leaks is where a routine will open a PRINTER_NOTIFY_INFO object and not close it before exiting.

Troubleshooting Steps

This stop is a warning. It might be normal if the print server has many printers or it might be the result of a resource leak. A resource leak could be caused by not calling FreePrinterNotifyInfo when necessary. If you think that the number is too high for the number of printers, then review the source code to determine if thePRINTER_NOTIFY_INFO objects are being opened and closed correctly.

Information displayed by Application Verifier

Parameter 1 - Number of currently opened PRINTER_NOTIFY_INFO objects.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A014

Severity: Warning

One-time error: no

Error report: None

Log to file: yes

Create backtrace: yes


Attempt to use an invalid PrintTicket

Application Verifier break message

Attempt to use an invalid PrintTicket

Probable cause

This verifier stop occurs when the application calls a PrintTicket method with an invalid PrintTicket.

Troubleshooting steps

The sample debugger output below illustrates the following troubleshooting steps:

  • Review the AppVerifier error message

  • Dump the XML using the du command as the error message describes

  • Dump the XML of the PrintTicket document (this might require more than one du command).

  • Analyze the XML in the PrintTicket (this might require cutting the text from the debugger console and pasting the text into a text editor for clean-up and analysis of the XML code)

  • Use k to dump the stack trace and see the routine that used the invalid PrintTicket

Copy Code
=======================================
VERIFIER STOP 0000A015 : pid 0x14F0: Attempt to use an invalid PrintTicket

        07641E54 : Error messages returned by PTConform. Use du to dump the message if this parameter is not NULL.
        0767B9D4 : PrintTicket XML text. Use du to dump the XML if this parameter is not NULL.
        00000000 : Not used.
        00000000 : Not used.

This verifier stop was caused when the application called the PTGetPrintCapabilities method with an invalid PrintTicket
=======================================

* Use the du command to Dump the error message that PTConform returned
0:000> du 07641E54
07641e54  "ERROR: CUtility - Match not foun"
07641e94  "d for node 'Option', name 'Inval"
07641ed4  "idPortrait'..ERROR: CUtility::Do"
07641f14  "SelfConformanceCheck - The node "
07641f54  "'Option' named 'InvalidPortrait'"
07641f94  " is not expected here as per the"
07641fd4  " PrintSchema spec.."

* Use the du command to dump the XML from the PrintTicket document
PrintTicket xml text
0:000> du 0767B9D4
0767b9d4  "<psf:PrintTicket xmlns:psf="http"
0767ba14  "://schemas.microsoft.com/windows"
0767ba54  "/2003/08/printing/printschemafra"
0767ba94  "mework" xmlns:xsi="http://www.w3"
0767bad4  ".org/2001/XMLSchema-instance" xm"
0767bb14  "lns:xsd="http://www.w3.org/2001/"
0767bb54  "XMLSchema" version="1" xmlns:ns0"
0767bb94  "000="http://schemas.microsoft.co"
0767bbd4  "m/windows/printing/oemdriverpt/H"
0767bc14  "P_LaserJet_4_6_0_5278_0_" xmlns:"
0767bc54  "psk="http://schemas.microsoft.co"
0767bc94  "m/windows/2003/08/printing/print"

* Use the k command to dump the stack trace
0:000> k
ChildEBP RetAddr
0013f780 73a7385b ntdll!DbgBreakPoint
0013f984 73889ce3 vrfcore!VerifierStopMessageEx+0x4bd
0013f9bc 73894684 vfprint!CPrintVerifierPrintTicketHelper::ValidatePrintTicket+0x84
0013f9dc 00144074 vfprint!VfPTGetPrintCapabilities+0x78
0013fa14 00142edc UnitTestvfPrint!GetPrintCapabilitiesWithInvalidPrintTicket+0xd4!The suspected routine
0013fb0c 001450b6 UnitTestvfPrint!wmain+0x3dc
0013fb50 76413833 UnitTestvfPrint!__wmainCRTStartup+0x102
0013fb5c 775fa9bd KERNEL32!BaseThreadInitThunk+0xe
0013fb9c 00000000 ntdll!_RtlUserThreadStart+0x23

Information displayed by Application Verifier

Format: - This verifier stop was caused when the application called the %lS method with an invalid PrintTicket

Parameter 1 - Error messages returned by PTConform. Use du to dump the message if this parameter is not NULL.

Parameter 2 - PrintTicket XML text. Use du to dump the XML if this parameter is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A015

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Attempt to use an invalid PrintCapabilities document

Application Verifier break message

Attempt to use an invalid PrintCapabilities document

Probable cause

This verifier stop occurs when the application calls a PrintTicket method with an invalid PrintCapabilities document.

Information displayed by Application Verifier

Format: - This verifier stop was caused when the application called the %lS method with an invalid PrintCapabilities document

Parameter 1 - Error messages returned by PTConform. Use du to dump the message if this parameter is not NULL.

Parameter 2 - PrintCapabilities XML text. Use du to dump the XML if this parameter is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A016

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


An invalid NULL argument was passed to a PrintTicket method

Application Verifier break message

An invalid NULL argument was passed to a PrintTicket method

Probable cause

This verifier stop occurs when the application calls a PrintTicket method with an invalid NULL argument.

Information displayed by Application Verifier

Format: - This verifier stop was caused when the application called the %lS method with a NULL %lS argument

Parameter 1 - Not used.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A017

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


PTConform encountered an unexpected error (PrintAPI)

Application Verifier break message

PTConform encountered an unexpected error

Probable cause

This verifier stop occurs when the PrintVerifier encounters an unexpected error while attempting to verify that the PrintTicket/PrintCapabilities conforms to the PrintSchema. Report this error to Microsoft because it could be a problem in the PrintVerifier.

Information displayed by Application Verifier

Parameter 1 - Not used.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A018

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Illegal print API called from DllMain

Application Verifier break message

Illegal print API called from DllMain

Probable cause

A call was made to a print API that does not support being called from within DllMain. Many Win32 APIs, not just Win32 print APIs, cannot be called from DllMain. For more information, read the documentation on DllMain in the MSDN library.

Information displayed by Application Verifier

Format: - Print API called from DllMain: %s

Parameter 1 - Not used.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Test Layer: PrintAPI

Stop code: 0000A019

Severity: Error

One-time error: no

Error report: Break

Log to file: yes

Create backtrace: yes


Leaked spool file handle detected

Application Verifier break message

Leaked spool file handle detected

Probable cause

An open spool file handle was detected when the application terminated. Most likely, CloseSpoolFileHandle() was not called.

Troubleshooting steps

To troubleshoot this stop:

  • Determine which thread opened the printer handle

  • Use dps to dump the stack if Parameter 2 is not NULL.

  • Find the first non-winspool and non-vfPrint module name that called vfPrint!VfHookOpenPrinter* or vfPrint!VfHookAddPrinter*. This routine typically is the 4th or the 6th stack frame in the list.

Information displayed by Application Verifier

Parameter 1 - Handle being leaked.

Parameter 2 - Initialization stack trace. Use dps to dump the stack if this parameter is not NULL.

Parameter 3 - Thread id of the thread that opened the handle.

Parameter 4 - Not used.

Additional information

Stop code: A01A


Attempt to use a closed spool file handle

Application Verifier break message

Attempt to use a closed spool file handle

Probable cause

A spool file handle was used after it had been closed.

Troubleshooting steps

To troubleshoot this stop:

  • Dump the current stack trace by using the 'k' command in the debugger to identify the routine that tried to use the closed handle.

  • Dump the stack trace of the routine that closed the handle by using the dps command with the second parameter of the stop.

Information displayed by Application Verifier

Parameter 1 - Spool file handle being accessed.

Parameter 2 - Stack trace of the closing. Use dps to dump the stack trace if it is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: A01B


Attempt to use an unknown spool file handle

Application Verifier break message

Attempt to use an unknown spool file handle

Probable cause

An attempt was made to use a spool file handle that was not opened by calling GetSpoolFileHandle or CommitSpoolData.

Troubleshooting steps

Use the 'k' command in the debugger to see the stack trace of the routine that attempted this action as shown in the following sample debugger output.

Copy Code
=======================================
VERIFIER STOP 0000A01C : pid 0xA94: Attempt to use an unknown spool file handle

        00000000 : Handle being accessed.
        00000000 : Not used.
        00000000 : Not used.
        00000000 : Not used.
=======================================

0:000> k
ChildEBP RetAddr
0012fa44 7386385b ntdll!DbgBreakPoint
0012fc48 6fe38d5a vrfcore!VerifierStopMessageEx+0x4bd
0012fc7c 6fe39841 vfprint!CResourceUsageMgr<void *,CSpoolFileTracker>::ClosedHandleCheck+0x70
*** WARNING: Unable to verify checksum for Test.exe
0012fc98 004170e3 vfprint!VfHookCloseSpoolFileHandle+0x89
0012fd8c 004119f1 Test!UseUnknownSpoolFileHandle+0x53!The suspect routine tried to use unknown Spool handle
0012ff48 00416936 Test!wmain+0x201
0012ff98 0041677d Test!__tmainCRTStartup+0x1a6
0012ffa0 76413833 Test!wmainCRTStartup+0xd
0012ffac 775fa9bd KERNEL32!BaseThreadInitThunk+0xe
0012ffec 00000000 ntdll!_RtlUserThreadStart+0x23

Information displayed by Application Verifier

Parameter 1 - Handle being accessed.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: A01C


Too many open spool file handles

Application Verifier break message

Too many open spool file handles

Probable cause

Too many spool file handles were opened. There might be a resource leak.

Troubleshooting steps

Information displayed by Application Verifier

Parameter 1 - Number of currently opened handles.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: A01D


DEVMODE buffer parameter spans across non-readable memory page(s)

Application Verifier break message

DEVMODE buffer parameter spans across non-readable memory page(s)

Probable cause

This stop can be caused by several conditions:

  • The DEVMODE buffer was already freed.

  • The DEVMODE buffer was constructed incorrectly by assigning the dmSize and dmDriverExtra members a value that is larger than it should be.

  • A NULL devmode buffer was used where a non-NULL buffer was expected.

Information displayed by Application Verifier

Format: This verifier stop was caused by a software component that called the print subsystem with a bad DEVMODE buffer. Review the current stack trace and check: the allocation, the construction, and the lifetime of the devmode to identify the bug location.

Parameter 1 - The bad DEVMODE buffer

Parameter 2 - The total buffer size as calculated from devmode dmSize and dmDriverExtra fields. Zero if the buffer is completely in non-readable memory.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: A01E


Unloading module with active COM callback

Application Verifier break message

Unloading module with active COM callback

Probable cause

A positive reference count was detected on a COM interface when the target module was unloaded. This was probably caused by an incorrect implementation of DllCanUnloadNow or incorrect reference counting.

Information displayed by Application Verifier

Format: - This verifier stop was caused by %lS module unload while the system still holds a %lS pointer to it.

Parameter 1 - COM interface address.

Parameter 2 - Stack trace where callback was provided. Use dps to dump the stack trace if it is not NULL.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: A01A


Async Notify handle returned by RegisterForPrintAsyncNotifications was not released properly

Application Verifier break message

Async Notify handle returned by RegisterForPrintAsyncNotifications was not released properly.

Probable cause

A Handle allocated by RegisterForPrintAsyncNotifications was not released until the program exited. Most likely, the handle should be released by calling UnRegisterForPrintAsyncNotifications before exiting.

Troubleshooting steps

  • If Parameter 2 is not NULL, use the dps debugger command to dump the initialization stack trace.

  • To determine the routine that allocated the handle, find the first non-winspool and non-vfPrint module name that called vfPrint!VfHookRegisterForPrintAsyncNotifications (typically found in the 3rd stack frame).

Information displayed by Application Verifier

Parameter 1 - Handle value.

Parameter 2 - Initialization stack trace.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: A020


Attempt to use an invalid handle in UnRegisterForPrintAsyncNotifications

Application Verifier break message

Attempt to use an invalid handle in UnRegisterForPrintAsyncNotifications.

Probable cause

The handle was not opened by the RegisterForPrintAsyncNotifications function.

Troubleshooting steps

To see the stack trace of the routine that attempted this action, use the k command in the debugger.

Information displayed by Application Verifier

Parameter 1 - Handle value.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: A021


Attempt to use a closed handle in UnRegisterForPrintAsyncNotifications API function

Application Verifier break message

Attempt to use a closed handle in UnRegisterForPrintAsyncNotifications API function.

Probable cause

A routine attempted to use an async notify handle after the handle had been closed.

Troubleshooting steps

  • To see the routine that attempted to use the closed handle, dump the current stack trace by using the k debugger command.

  • If Parameter 2 is not NULL, use the dps debugger command to dump the stack trace of the routine that closed the handle.

Information displayed by Application Verifier

Parameter 1 - Handle value.

Parameter 2 - Stack trace of the closing routine.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: A022


Third-party function reports failure but increases reference count for input interface

Application Verifier break message

Third-party function reports failure but increases reference count for input interface.

Probable cause

A third-party method received an interface pointer as input. If that method returns failure code, interface reference count should remain the same. But in this case reference count was increased.

Information displayed by Application Verifier

Parameter 1 - Pointer to the called interface. If this parameter is NULL, the called method is static.

Parameter 2 - Input interface pointer.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: A023


Windows API function reports failure but increases reference count for input interface

Application Verifier break message

Windows API function reports failure but increases reference count for input interface.

Probable cause

An API method received an interface pointer as input. If the method returns a failure code, the interface reference count should remain the same. But in this case reference count was increased. Please report this error to Microsoft.

Information displayed by Application Verifier

Parameter 1 - Pointer to the called interface. If this parameter is NULL, the called method is static.

Parameter 2 - Input interface pointer.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: A024


IPrintAsyncNotifyChannel contract violation by the operating system

Application Verifier break message

IPrintAsyncNotifyChannel contract violation by the operating system.

Probable cause

The platform implementation of IPrintAsyncNotifyChannel violated part of the special contract implied or defined by IPrintAsyncNotifyChannel. IPrintAsyncNotifyChannel has special exceptions to the rules for AddRef and Release. This requires that the platform call OnEventNotify and ChannelClosed with the same interface pointer that was used to create the channel.

Information displayed by Application Verifier

Parameter 1 - Actual interface pointer.

Parameter 2 - Expected interface pointer.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: A025


IPrintAsyncNotifyChannel contract violation by channel consumer

Application Verifier break message

IPrintAsyncNotifyChannel contract violation by channel consumer.

Probable cause

On bidirectional channels, calling SendNotification, CloseChannel, or making the final Release on the interface pointer relinquishes ownership. After creating the channel and sending the first notification, you cannot call Release until your callback's OnEventNotify is invoked. If you either invoke CloseChannel or get a ChannelClosed notification, you must not perform the final Release call.

Information displayed by Application Verifier

Parameter 1 - IPrintAsyncNotifyChannel interface pointer.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: A026


Race detected during closing of IPrintAsyncNotifyChannel

Application Verifier break message

Race detected during closing of IPrintAsyncNotifyChannel.

Probable cause

This stop indicates that a notification arrived during a call to CloseChannel. If this condition occurs, it might be impossible for the consumer to correctly release the channel.

Information displayed by Application Verifier

Parameter 1 - IPrintAsyncNotifyChannel interface pointer.

Parameter 2 - Thread ID of the member function called.

Parameter 3 - Thread ID of callback event function.

Parameter 4 - Not used.

Additional information

Stop code: A027

This stop should not be encountered frequently. It can be prevented by always ensuring a listener is available before a bidirectional channel is created, or by ensuring that no listener can be started before attempting to close a channel that has already sent a notification but not received the callback.

Please report this stop to Microsoft.


Calling a print API that makes network calls on a GUI thread

Application Verifier break message

Calling a print API that makes network calls on a GUI thread.

Probable cause

A routine running on a graphical user interface (GUI) thread called a print API that makes network calls. This can lead to an unresponsive user interface.

Information displayed by Application Verifier

Parameter 1 - HWND of the top-level visible window.

Parameter 2 - Current thread ID.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: A028

Print APIs that make network calls should be called on a worker thread that has no message pumps.


Calling an API that will pop up user interface in Session0

Application Verifier break message

Calling an API that will pop up user interface in Session0.

Probable cause

A call was made in Session 0 to an API that pops up a user interface.

Information displayed by Application Verifier

Parameter 1 - Not used.

Parameter 2 - Not used.

Parameter 3 - Not used.

Parameter 4 - Not used.

Additional information

Stop code: A029


Net Verifier Stops

When Application Verifier is run on a solution or project, the Net Verifier provides a stop code when an error is found. The stop codes that may be encountered depend on the tests selected to run.

Net Verifier test layer messages

These messages are returned by the Net Verifier when it is testing the Net APIs.

Error message | Stop code
Illegal networking API called from DllMain | E100
Attempt to use a closed SOCKET | E101
Attempt to use an unknown SOCKET | E102
Leaked SOCKET handle detected | E103
A layered service provider (LSP) attempted to use a closed SOCKET | E104
A layered service provider (LSP) attempt to use an unknown SOCKET | E105
A SOCKET handle leak was detected from a layered service provider (LSP) | E106
Networking API called before a successful WSAStartup() or after a balancing successful WSACleanup() call was made | E107
A Winsock service provider API was called before a successful WSPStartup() or after a balancing successful WSPCleanup() call was made. | E108
A Winsock name service provider API was called before a successful NSPStartup() or after a balancing successful NSPCleanup() call was made. | E109
Use of an invalid Winsock extension function pointer detected | E10A
WSACleanup aborted and closed existing SOCKET handles underneath the code that owned those SOCKETs | E10B
WSPCleanup aborted and closed existing service provider SOCKET handles underneath the code that owned those SOCKETs | E10C
The immediate return value, or GetLastError, is invalid for the current Winsock call. This generally points to a fault in a Service Provider. | E10D
The return value, or lpError, is invalid for the current Winsock call. This generally points to a fault in a Base Service Provider or in the networking stack. | E10E


Illegal networking API called from DllMain
See Also

Application Verifier break message

Illegal networking API called from DllMain

Probable cause

A call was made to a networking API that does not support being called from within DllMain. Many Win32 APIs, not just Win32 networking APIs, cannot be called from DllMain. For more information, read the documentation on DllMain in the MSDN library.

Troubleshooting steps

Enter k to dump the current stack trace, which will identify the function that made the illegal call.

Review the message provided, because it will indicate at least one of the offending APIs.

Information displayed by Application Verifier

Parameter 1 - Networking function being called from DllMain

Parameter 2 - If not NULL, the name of the DLL that made the invalid call

Parameter 3 - Not Used

Parameter 4 - Not Used

Additional information

Test Layer: Net Verifier

Stop code: E100

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Break

Log to file: Yes

Create backtrace: Yes

See Also

Concepts

Net Verification Layer


Attempt to use a closed SOCKET
See Also

Application Verifier break message

Attempt to use a closed SOCKET

Probable cause

A SOCKET was used after it had been closed.

Troubleshooting steps

Enter k to dump the current stack trace, which will identify the function that tried to use the closed SOCKET.

If Parameter 2 is not NULL, enter dps Parameter 2 to dump the stack trace of the function that closed the socket.

Information displayed by Application Verifier

Parameter 1 - SOCKET being accessed

Parameter 2 - Stack trace of the function that closed the socket

Parameter 3 - Not Used

Parameter 4 - Not Used

Additional information

Test Layer: Net Verifier

Stop code: E101

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Yes

Log to file: Yes

Create backtrace: Yes

See Also

Concepts

Net Verification Layer


Attempt to use an unknown SOCKET
See Also

Application Verifier break message

Attempt to use an unknown SOCKET

Probable cause

An attempt was made to use an unknown value for a SOCKET that was not created by a call to Winsock.

Troubleshooting steps

Enter k to dump the stack trace of the function that attempted to use the unknown socket value.

Information displayed by Application Verifier

Parameter 1 - SOCKET being accessed.

Parameter 2 - Not Used

Parameter 3 - Not Used

Parameter 4 - Not Used

Additional information

Test Layer: Net Verifier

Stop code: E102

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Yes

Log to file: Yes

Create backtrace: Yes

See Also

Concepts

Net Verification Layer


Leaked SOCKET handle detected
See Also

Application Verifier break message

Leaked SOCKET handle detected

Probable cause

An open SOCKET handle was leaked.

Troubleshooting steps

If Parameter 2 is not NULL, enter dps Parameter 2 to dump the stack trace of the thread that opened the SOCKET handle.

Information displayed by Application Verifier

Parameter 1 - SOCKET handle being leaked

Parameter 2 - Initialization stack trace

Parameter 3 - Thread ID of the thread that opened the handle

Parameter 4 - Not Used

Additional information

Test Layer: Net Verifier

Stop code: E103

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Yes

Log to file: Yes

Create backtrace: Yes

See Also

Concepts

Net Verification Layer


A layered service provider (LSP) attempted to use a closed SOCKET

Application Verifier break message

A layered service provider (LSP) attempted to use a closed SOCKET

Probable cause

A SOCKET from a Winsock base provider was used after it had been closed. This generally indicates a fault in a layered service provider (LSP).

Troubleshooting steps

Enter k to view the current call stack, which will identify the function that attempted to use the closed SOCKET.

Enter dps Parameter 2 to dump the stack of the function that closed the SOCKET.

Information displayed by Application Verifier

Parameter 1 - SOCKET being accessed

Parameter 2 - Stack trace of the function that closed the SOCKET

Parameter 3 - Not Used

Parameter 4 - Not Used

Additional information

Test Layer: Net Verifier

Stop code: E104

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Yes

Log to file: Yes

Create backtrace: Yes


A layered service provider (LSP) attempt to use an unknown SOCKET

Application Verifier break message

A layered service provider (LSP) attempt to use an unknown SOCKET

Probable cause

An unknown SOCKET handle value was used by a Winsock layered service provider (LSP). This is generally indicates to a fault in a specific LSP layered between the application and Winsock.

Troubleshooting steps

Enter k to view the current call stack for the module making the call with the unknown SOCKET value.

Information displayed by Application Verifier

Parameter 1 - SOCKET being accessed

Parameter 2 - Not Used

Parameter 3 - Not Used

Parameter 4 - Not Used

Additional information

Test Layer: Net Verifier

Stop code: E105

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Yes

Log to file: Yes

Create backtrace: Yes


A SOCKET handle leak was detected from a layered service provider (LSP)

Application Verifier break message

A SOCKET handle leak was detected from a layered service provider (LSP)

Probable cause

An open SOCKET handle from a layered service provider (LSP) was leaked.

Troubleshooting steps

If Parameter 2 is not NULL, enter dps Parameter 2 to dump the stack where the leaked socket was created.

Information displayed by Application Verifier

Parameter 1 - Handle to the leaked SOCKET

Parameter 2 - Initialization stack trace

Parameter 3 - ID of the thread that opened the handle

Parameter 4 - Not Used

Additional information

Test Layer: Net Verifier

Stop code: E106

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Yes

Log to file: Yes

Create backtrace: Yes


Networking API called before a successful WSAStartup() or after a balancing successful WSACleanup() call was made

Application Verifier break message

Networking API called before a successful WSAStartup() or after a balancing successful WSACleanup() call was made

Probable cause

A call was made to a networking API before a successful WSAStatrup() or after a balancing successful WSACleanup() call. WSAStartup is required to provide a reference count by any component using Winsock to guarantee initialization for Winsock API usage. An unbalanced WSAStartup/WSACleanup call pattern by a component can lead to undefined behavior because this can cause the Winsock layer to unload libraries and release resources that are still being used.

Troubleshooting steps

If Parameter 1 is not NULL, enter dps Parameter 1 to dump the stack for the last successful WSAStartup call by the DLL in violation.

If Parameter 2 is not NULL, enter dps Parameter 2 to dump the stack for the last successful WSACleanup call by the DLL in violation.

If Parameter 3 is not NULL, enter dps Parameter 3 to dump the stack for the last successful WSAStartup call made by any DLL in the process.

If Parameter 4 is not NULL, enter dps Parameter 4 to dump the stack for the last successful WSACleanup call by any DLL in the process.

Information displayed by Application Verifier

Parameter 1 - Last successful WSAStartup call by this DLL in violation.

Parameter 2 - Last successful WSACleanup call by the DLL in violation.

Parameter 3 - Last successful WSAStartup call in the process.

Parameter 4 - Last successful WSACleanup call in the process.

Additional information

Test Layer: Net Verifier

Stop code: E107

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Yes

Log to file: Yes

Create backtrace: Yes


A Winsock service provider API was called before a successful WSPStartup() or after a balancing successful WSPCleanup() call was made.

Application Verifier break message

A Winsock service provider API was called before a successful WSPStartup() or after a balancing successful WSPCleanup() call was made

Probable cause

A call was made to a Winsock name service provider API before a successful WSPStarup() or after a balancing successful WSPCleanup() call. This is generally pointing to a fault to a specific Winsock layered service provider (LSP) layered between the application and Winsock. WSPStartup is required to provide a reference count by any LSP using Winsock to guarantee initialization for Winsock service provider API usage. An unbalanced WSPStartup/WSPCleanup call pattern by an LSP can lead to undefined behavior as this can cause the Winsock layer to unload libraries and release resources while still being used.

Troubleshooting steps

If Parameter 1 is not NULL, enter dps Parameter 1 to dump the stack for the last successful WSPStartup call by the LSP in violation.

If Parameter 2 is not NULL, enter dps Parameter 2 to dump the stack for the last successful WSPCleanup call by the LSP in violation.

If Parameter 2 is not NULL, enter dps Parameter 3 to dump the stack for the last successful WSPStartup call made by any service provider in the process.

If Parameter 4 is not NULL, enter dps Parameter 4 to dump the stack for the last successful WSPCleanup call made by any service provider in the process.

Information displayed by Application Verifier

Parameter 1 - Last successful WSPStartup call made by the LSP in violation.

Parameter 2 - Last successful WSPCleanup call made by the LSP in violation.

Parameter 3 - Last successful WSPStartup call made by any service provider in the process.

Parameter 4 - Last successful WSPCleanup call made by any service provider in the process.

Additional information

Test Layer: Net Verifier

Stop code: E108

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Yes

Log to file: Yes

Create backtrace: Yes


A Winsock name service provider API was called before a successful NSPStartup() or after a balancing successful NSPCleanup() call was made.

Application Verifier break message

A Winsock name service provider API was called before a successful NSPStartup() or after a balancing successful NSPCleanup() call was made

Probable cause

A call was made to a Winsock name service provider API before a successful NSPStartup() or after a balancing successful NSPCleanup() call. This is generally pointing to a fault to a specific Winsock name service provider (NSP) layered between the application and Winsock. NSPStartup is required to provide a reference count by any NSP using Winsock to guarantee initialization for Winsock name service provider API usage. An unbalanced NSPStartup/NSPCleanup call pattern by an NSP can lead to undefined behavior because this can cause the Winsock layer to unload libraries and release resources while still being used.

Troubleshooting steps

If Parameter 1 is not NULL, enter dps Parameter 1 to dump the stack for the last successful NSPStartup call by the NSP in violation.

If Parameter 2 is not NULL, enter dps Parameter 2 to dump the stack for the last successful NSPCleanup call by the NSP in violation.

If Parameter 3 is not NULL, enter dps Parameter 3 to dump the stack for the last successful NSPStartup call made by any name service provider in the process.

If Parameter 4 is not NULL, enter dps Parameter 4 to dump the stack for the last successful NSPCleanup call by any name service provider in the process.

Information displayed by Application Verifier

Parameter 1 - Last successful NSPStartup call by the NSP in violation.

Parameter 2 - Last successful NSPCleanup call by the NSP in violation.

Parameter 3 - Last successful NSPStartup call made by any NSP in the process.

Parameter 4 - Last successful NSPCleanup call made by any NSP in the process.

Additional information

Test Layer: Net Verifier

Stop code: E109

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Yes

Log to file: Yes

Create backtrace: Yes


Use of an invalid Winsock extension function pointer detected

Application Verifier break message

Use of an invalid Winsock extension function pointer detected

Probable cause

Microsoft Winsock Extension functions are callable only by querying Winsock for the function pointer value at runtime. The Winsock runtime has been unloaded since this function pointer was returned. The caller likely kept a copy of the function pointer after calling WSACleanup and tried to reuse it.

Troubleshooting steps

Enter k to find the caller that used a Winsock function pointer after Winsock had been unloaded.

Enter dps Parameter 1 to see the call stack when this function pointer was returned.

Enter dps Parameter 2 to see the call stack when Winsock was unloaded, invalidating this function pointer.

Information displayed by Application Verifier

Parameter 1 - Last call to get a Winsock function pointer

Parameter 2 - Last call that unloaded Winsock, invalidating the function pointers

Parameter 3 - Not Used

Parameter 4 - Not Used

Additional information

Test Layer: Net Verifier

Stop code: E10A

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Yes

Log to file: Yes

Create backtrace: Yes


WSACleanup aborted and closed existing SOCKET handles underneath the code that owned those SOCKETs

Application Verifier break message

WSACleanup aborted and closed existing SOCKET handles underneath the code that owned those SOCKETs

Probable cause

WSACleanup was called, decrementing the Winsock reference count to 0, while SOCKET handles were still open in the process. Winsock closes any open SOCKET handles when the reference count reaches zero. This is typically a bug in the component that decrements the Winsock reference count too often (by calling WSACleanup unbalanced with WSAStartup) or incorrectly tracks (leaks) SOCKET handles.

Troubleshooting steps

Enter k to find the caller that decremented the WSAStartup/WSACleanup count to 0.

Information displayed by Application Verifier

Parameter 1 - Number of sockets that were outstanding

Parameter 2 - Not Used

Parameter 3 - Not Used

Parameter 4 - Not Used

Additional information

Test Layer: Net Verifier

Stop code: E10B

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Yes

Log to file: Yes

Create backtrace: Yes


WSPCleanup aborted and closed existing service provider SOCKET handles underneath the code that owned those SOCKETs

Application Verifier break message

WSPCleanup aborted and closed existing service provider SOCKET handles underneath the code that owned those SOCKETs

Probable cause

WSPCleanup was called by a layered service provider (LSP), decrementing the Winsock reference count to 0, while open SOCKET handles existed in the process. Winsock closes any open SOCKET handles when the reference count reaches zero.This is typically a bug in the LSP that decrements the Winsock reference count too often (by calling WSPCleanup unbalanced with WSPStartup) or incorrectly tracks (leaks) SOCKET handles.

Troubleshooting steps

Enter k to find the caller that decremented the WSPStartup/WSPCleanup count to 0.

Information displayed by Application Verifier

Parameter 1 - Number of outstanding service provider sockets

Parameter 2 - Not Used

Parameter 3 - Not Used

Parameter 4 - Not Used

Additional information

Test Layer: Net Verifier

Stop code: E10C

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: None

Log to file: Yes

Create backtrace: Yes


The immediate return value, or GetLastError, is invalid for the current Winsock call. This generally points to a fault in a Service Provider.

Application Verifier break message

The immediate return value, or GetLastError, is invalid for the current Winsock call. This generally points to a fault in a Service Provider.

Probable cause

The value that is being returned, or the current value in GetLastError, does not comply with the Winsock 2 specification. This typically indicates a bug in a layered service provider (LSP) layered between the application and Winsock. In such a case, the LSP has broken the Winsock API contract and is returning an invalid value to the caller.

Troubleshooting steps

Enter ln Parameter 3 to find the function that returned the incorrect return code.

Inspect parameters 1 and 2 to see the incorrect return value.

If the call was to a Winsock send or recv function, inspect Parameter 4 to see the number of bytes requested to be sent or received. It is invalid for the returned number of bytes to be greater than the number of bytes requested.

Information displayed by Application Verifier

Parameter 1 - Return value

Parameter 2 - Value of GetLastError

Parameter 3 - Function pointer to the next service provider

Parameter 4 - For a send or recv call, the actual number of bytes requested

Additional information

Test Layer: Net Verifier

Stop code: E10D

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Yes

Log to file: Yes

Create backtrace: Yes


The return value, or lpError, is invalid for the current Winsock call. This generally points to a fault in a Base Service Provider or in the networking stack.

Application Verifier break message

The return value, or lpError, is invalid for the current Winsock call. This generally points to a fault in a Base Service Provider or in the networking stack.

Probable cause

The value that is being returned, or the current value in lpError from the API call, does not follow the Winsock 2 specification. This typically points to a bug in a loaded Winsock Base Service Provider (usually mswsock.dll) or the networking stack beneath Winsock.

Troubleshooting steps

Enter ln Parameter 3 to find the function that returned the incorrect code.

Inspect parameters 1 and 2 to see the incorrect return value.

If the call was to a Winsock send or recv function, inspect Parameter 4 to see the number of bytes requested to be sent or received. It is invalid for the returned number of bytes to be greater than the number of bytes requested.

Information displayed by Application Verifier

Parameter 1 - Return value

Parameter 2 - lpError

Parameter 3 - Function pointer to the next service provider

Parameter 4 - For a send or recv call, the nummber of bytes requested.

Additional information

Test Layer: Net Verifier

Stop code: E10E

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Yes

Log to file: Yes

Create backtrace: Yes


Webservices Stops

When Application Verifier is run on a solution or project, the WebServices Verifier provides a stop code when an error is found. The stop codes that may be encountered depend on the tests selected to run.

WebServices Verifier test layer messages

These messages are returned by the webservices Verifier when it is testing the Net API’s.

Error message | Stop code
Invalid Object Address | 6000
Single Threaded Object Violation | 6001
Object in use | 6002
Leaked SOCKET handle detected | 6003
Corrupt Call Context | 6004


Invalid Object Address
See Also

A call was made to a Web Services Windows API with an invalid object. For more information, read the documentation on the API’s in the MSDN library.

Application Verifier break message

Invalid Address of a Web Services Windows API intrinsic object

Probable cause

An invalid address of a Web Services API intrinsic object was passed to the function.

Troubleshooting steps

To debug this stop:

$ Review the message provided, as it will indicate at least one of the offending APIs.

Information displayed by Application Verifier

Parameter 1 – Address of object

Parameter 2 - Not Used

Parameter 3 - Not Used

Parameter 4 - Not Used

Additional information

Test Layer: WebServices

Stop code: 0x6000

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Break

Log to file: Yes

Create backtrace: Yes

See Also

Concepts

Webservices API Layer


Single Threaded Object Violation
See Also

Another thread is using a single threaded Web Services Windows API intrinsic object. For more information, read the documentation in the MSDN library.

Application Verifier break message

Multithreaded use of a webservices.dll intrinsic object

Probable cause

An operation in another thread is using a non-thread safe intrinsic Web Services Windows API object.

Troubleshooting steps

To debug this stop:

$ Review the message provided, as it will indicate at least one of the offending APIs.

Information displayed by Application Verifier

Parameter 1 – Address of single threaded intrinsic object

Parameter 2 - Not Used

Parameter 3 - Not Used

Parameter 4 - Not Used

Additional information

Test Layer: WebServices

Stop code: 0x6001

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Break

Log to file: Yes

Create backtrace: Yes

See Also

Concepts

Webservices API Layer


Object in use
See Also

An object is being freed whilst an asynchronous operation is still pending. For more information, read the documentation in the MSDN library.

Application Verifier break message

Freeing of an object while still in use

Probable cause

An intrinsic Web Services Windows API was freed when an asynchronous operation is still pending.

Troubleshooting steps

To debug this stop:

$ Review the message provided, as it will indicate at least one of the offending APIs.

Information displayed by Application Verifier

Parameter 1 – Address of intrinsic object

Parameter 2 - Not Used

Parameter 3 - Not Used

Parameter 4 - Not Used

Additional information

Test Layer: WebServices

Stop code: 0x6002

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Break

Log to file: Yes

Create backtrace: Yes

See Also

Concepts

Webservices API Layer


API Timeout
See Also

Web Services Windows API is taking too long to execute. For more information, read the documentation in the MSDN library.

Application Verifier break message

A Web Services Windows API is taking too long to execute.

Probable cause

A Web Services Windows API is taking too long to execute.

Troubleshooting steps

To debug this stop:

$ Review the message provided, as it will indicate at least one of the offending APIs.

Information displayed by Application Verifier

Parameter 1 – Not Used

Parameter 2 - Not Used

Parameter 3 - Not Used

Parameter 4 - Not Used

Additional information

Test Layer: WebServices

Stop code: 0x6003

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Break

Log to file: Yes

Create backtrace: Yes

See Also

Concepts

Webservices API Layer


Corrupt Call Context
See Also

A corrupt call context was passed into the callback function. For more information, read the documentation in the MSDN library.

Application Verifier break message

A corrupt WS_ASYNC_CONTEXT was passed into the callback function.

Probable cause

A corrupt WS_ASYNC_CONTEXT was passed into the callback function.

Troubleshooting steps

To debug this stop:

$ Review the message provided, as it will indicate at least one of the offending APIs.

Information displayed by Application Verifier

Parameter 1 – Not Used

Parameter 2 - Not Used

Parameter 3 - Not Used

Parameter 4 - Not Used

Additional information

Test Layer: WebServices

Stop code: 0x6004

Severity: Error

One-time error: No

Non Continuable: Yes

Error report: Break

Log to file: Yes

Create backtrace: Yes

See Also

Concepts

Webservices API Layer


Debugging Verifier Stops

When you enable some of the checks in Application Verifier and save the settings, you may see a message box with the following message:

“To achieve the best result, please test [yourapp.exe] while running it under a debugger. For more information see the “Debugging Verifier Stops” topic in the Application Verifier help file.”

This is an informational message only. You can suppress this message using the checkbox on the message box that says “Don’t show me this message again.”

We recommend you launch your application under a debugger as the information in the log file may not be sufficient for effective troubleshooting.

This section provides you with information on debugging the following errors:

  • Debugging with !avrf

  • Debugging Continuable and Non-Continuable Stops

  • Debugging Critical Section Errors

  • Debugging Exception Errors

  • Debugging Handles Errors

  • Debugging Heap Errors

  • Debugging Memory Errors

  • Debugger install and setup


Debugging with !avrf

The !avrf extension controls the settings of Application Verifier and displays a variety of output produced by Application Verifier.

Syntax

!avrf

The !avrf command without any parameters shows the Application Verifier settings and information about the current and previous Application Verifier breaks if any.

!avrf –vs { Length | -a Address }

Displays the virtual space operation log. Length specifies the number of records to display starting from the most recent. Address specifies the virtual address. Records of the virtual operations containing this virtual address will be displayed.

!avrf -hp { Length | -a Address }

Displays the heap operation log. Address specifies the heap address. Records of the heap operations containing this heap address will be displayed.

!avrf -cs { Length | -a Address }

Displays the critical section delete log. Length specifies the number of records to display starting from the most recent. Address specifies the critical section address. Records for the particular critical section are displayed when Address is specified.

!avrf -dlls [ Length ]

Displays the DLL load/unload log. Length specifies the number of records to display starting from the most recent.

!avrf -trm

Displays a log of all terminated and suspended threads.

!avrf -ex [ Length ]

Displays the exception log. Application Verifier tracks all the exceptions happening in the application.

!avrf -threads [ ThreadID ]

Displays information about threads in the target process. For child threads, the stack size and the CreateThread flags specified by the parent are displayed as well. Providing a thread ID will display information only for that particular thread.

!avrf -tp [ ThreadID ]

Displays the thread pool log. This log may contain stack traces for various operations such as changing the thread affinity mask, changing thread priority, posting thread messages, initializing COM, and uninitializing COM from within the thread pool callback. Providing a thread ID will display information only for that particular thread.

!avrf -srw [ Address | Address Length ] [ -stats ]

Displays the Slim Reader/Writer (SRW) log. Specifying Address will display records pertaining to that SRW lock address. When Length is specified along with the Address , all SRW locks within that address range are displayed. The -stats option dumps the SRW lock statistics.

!avrf -leak [ -m ModuleName ] [ -r ResourceType ] [ -a Address ] [ -t ]

Displays the outstanding resources log. These resources may or may not be leaks at any given point. Specifying ModuleName (including the extension) displays all outstanding resources in the specified module. Specifying ResourceType displays outstanding resources of that particular resource type. Specifying Address dumps records of outstanding resources with that address. ResourceType can be one of the following:

  • Heap: Displays heap allocations using Win32 Heap APIs

  • Local: Displays Local/Global allocations

  • CRT: Displays allocations using CRT APIs

  • Virtual: Displays Virtual reservations

  • BSTR: Displays BSTR allocations

  • Registry: Displays Registry key opens

  • Power: Displays power notification objects

  • Handle: Displays thread, file, and event handle allocations

!avrf –trace TraceIndex

Displays a stack trace for the specified trace index. Some structures use this 16-bit index number to identify a stack trace. This index points to a location within the stack trace database. If you are analyzing such a structure, you will find this syntax useful.

!avrf -cnt

Displays a list of global counters.

!avrf -brk [ BreakEventType ]

Specifies that this is a break-event command. When !avrf -brk is used with no additional parameters, the break event settings are displayed. BreakEventType specifies the type number of the break event. For a list of possible types, use !avrf -brk .

!avrf -flt [ EventTypeProbability ]

Specifies that this is a fault-injection command. When !avrf -flt is used with no additional parameters, the current fault injection settings are displayed. EventType specifies the type number of the event. Probability specifies the frequency with which the event will fail. This can be any integer between 0 and 1,000,000 (0xF4240).

!avrf -flt break EventType

Causes Application Verifier to break into the debugger each time this fault is injected.

!avrf -flt stacks Length

Displays Length number of stack traces for the most recent fault-injected operations.

!avrf -trg [ StartEnd | dll Module | all ]

Specifies that this is a target range command. When -trg is used with no additional parameters, the current target ranges are displayed. Start specifies the beginning address of the target range or exclusion range. End specifies the ending address of the target range or exclusion range. Module specifies the name of a module to be targeted or excluded. Module should include the full module name, including the .exe or .dll extension. Path information should not be included. Specifying all causes all target ranges or exclusion ranges to be reset.

!avrf -skp [ StartEnd | dll Module | all | Time ]

Specifies that this is an exclusion range command. Start specifies the beginning address of the target range or exclusion range. End specifies the ending address of the target range or exclusion range. Module specifies the name of a module to be targeted or excluded. Module should include the full module name, including the .exe or .dll extension. Path information should not be included. Specifying all causes all target ranges or exclusion ranges to be reset. Specifying Time causes all faults to be suppressed for Time milliseconds after execution resumes.

Output

The following is the output provided by !avrf command in the debugger.

Copy Code
0:000> !avrf
Application verifier settings (816431A7):

   - full page heap
   - COM
   - RPC
   - Handles
   - Locks
   - Memory
   - TLS
   - Exceptions
   - Threadpool
   - Leak
   - SRWLock

No verifier stop active.

Note: Sometimes bugs found by verifier manifest themselves as raised
exceptions (access violations, stack overflows, invalid handles),
and it is not always necessary to have a verifier stop.

DLL

Windows NT 4.0 | Unavailable
Windows 2000 | Unavailable
Windows XP and later | Exts.dll

Comments

When the !avrf extension is used with no parameters, it displays the current Application Verifier options.

If an Application Verifier Stop has occurred, the !avrf extension with no parameters will reveal the nature of the stop and what caused it.

If symbols for ntdll.dll and verifier.dll are missing, the !avrf extension will generate an error message.


Debugging Continuable and Non-Continuable Stops

Debugging a Continuable Stop

Here is an example of an invalid handle exception that has been raised by the Detect invalid handle usage option.

First, the following message appears:

Invalid handle - code c0000008 (first chance)

===================================================

VERIFIER STOP 00000300: pid 0x558: invalid handle exception for current stack trace

C0000008 : Exception code.

0012FBF8 : Exception record. Use .exr to display it.

0012FC0C : Context record. Use .cxr to display it.

00000000 :

===================================================

This verifier stop is continuable.

After debugging it use 'go' to continue.

===================================================

Break instruction exception - code 80000003 (first chance)

eax=00000000 ebx=6a27c280 ecx=6a226447 edx=0012fa4c esi=00942528 edi=6a27c260

eip=6a22629c esp=0012facc ebp=0012faf0 iopl=0 nv up ei pl zr na po nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246

ntdll!DbgBreakPoint:

6a22629c cc int 3

Notice that the message tells you that this Application Verifier Stop can be continued. After you understand what has transpired, you can continue running the target application.

First, you should use the !avrf extension. This gives information about the current failure:

0:000> !avrf

Global flags: 00000100

Application verifier global flag is set.

Application verifier settings (00000004):

- no heap checking enabled!

- handle checks

Page heap is not active for this process.

Current stop 00000300 : c0000008 0012fbf8 0012fc0c 00000000 .

Using an invalid handle (either closed or simply bad).

The final line of this display summarizes the problem.

You may want to look at some logs at this point. After you are done, use the g (Go) command to start the application again:

0:000> g

Debugging a Non-Continuable Stop

Here is an example of an access violation that has been raised by the page heap option.

First, the following message appears:

Access violation - code c0000005 (first chance)

===================================================

VERIFIER STOP 00000008: pid 0x504: exception raised while verifying block header

00EC1000 : Heap handle

00F10FF8 : Heap block

00000000 : Block size

00000000 :

===================================================

This verifier stop is not continuable. Process will be terminated when you use the 'go' debugger command.

===================================================

Break instruction exception - code 80000003 (first chance)

eax=00000000 ebx=00000000 ecx=6a226447 edx=0012fab7 esi=00f10ff8 edi=00000008

eip=6a22629c esp=0012fb5c ebp=0012fb80 iopl=0 nv up ei pl zr na po nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246

ntdll!DbgBreakPoint:

6a22629c cc int 3

In this case, the message tells you that this Application Verifier Stop cannot be continued. The error is too severe for the process to continue running, and there is no way for Application Verifier to salvage the process.

The !avrf extension can be used to give information about the current failure:

0:000> !avrf

Global flags: 02000100

Application verifier global flag is set.

Page heap global flag is set.

Application verifier settings (00000001):

- full page heap

Page heaps active in the process (format: pageheap, lightheap, flags):

00941000 , 00a40000 , 3 (pageheap traces )

00b41000 , 00c40000 , 3 (pageheap traces )

00cb1000 , 00db0000 , 3 (pageheap traces )

00ec1000 , 00fc0000 , 3 (pageheap traces )

Current stop 00000008 : 00ec1000 00f10ff8 00000000 00000000 .

Corrupted heap block.

The final line of this display summarizes the problem.

You may also want to look at some logs at this point. You may want to use the .restart (Restart Target Application) command at this point. Or perhaps you may prefer to end your Application Verifier session and begin fixing the bugs in your code.


Debugging Critical Section Errors

!cs debugger extension

!cs can be used in both user-mode debugger and kernel debugger to display information about critical sections in the current process. Matching symbols with type information is required, especially for ntdll.dll.

The syntax for this extension is:

cs [-s] - dump all the active critical sections in the current process.

!cs [-s] address - dump critical section at this address.

!cs [-s] -d address - dump critical section corresponding to DebugInfo at this address.

-s will dump the critical section initialization stack trace if it's available.

Examples:

Dump information about a critical section using its address

0:001> ! cs 0x7803B0F8

Critical section = 0x7803B0F8 (MSVCRT!__app_type+0x4)

DebugInfo = 0x6A262080

NOT LOCKED

LockSemaphore = 0x0

SpinCount = 0x0

Dump information about a critical section using its address, including initialization stack trace

0:001> !cs -s 0x7803B0F8

Critical section = 0x7803B0F8 (MSVCRT!__app_type+0x4)

DebugInfo = 0x6A262080

NOT LOCKED

LockSemaphore = 0x0

SpinCount = 0x0

Stack trace for DebugInfo = 0x6A262080:

0x6A2137BD: ntdll!RtlInitializeCriticalSectionAndSpinCount+0x9B

0x6A207A4C: ntdll!LdrpCallInitRoutine+0x14

0x6A205569: ntdll!LdrpRunInitializeRoutines+0x1D9

0x6A20DCE1: ntdll!LdrpInitializeProcess+0xAE5

Dump information about a critical section using its debug info address

0:001> !cs -d 0x6A262080

DebugInfo = 0x6A262080

Critical section = 0x7803B0F8 (MSVCRT!__app_type+0x4)

NOT LOCKED

LockSemaphore = 0x0

SpinCount = 0x0

Dump information about a critical section using its debug info address, including initialization stack trace

0:001> !cs -s -d 0x6A262080

DebugInfo = 0x6A262080

Critical section = 0x7803B0F8 (MSVCRT!__app_type+0x4)

NOT LOCKED

LockSemaphore = 0x0

SpinCount = 0x0

Stack trace for DebugInfo = 0x6A262080:

0x6A2137BD: ntdll!RtlInitializeCriticalSectionAndSpinCount+0x9B

0x6A207A4C: ntdll!LdrpCallInitRoutine+0x14

0x6A205569: ntdll!LdrpRunInitializeRoutines+0x1D9

0x6A20DCE1: ntdll!LdrpInitializeProcess+0xAE

Dump information about all the active critical sections in the current process

0:001> !cs

-----------------------------------------

DebugInfo = 0x6A261D60

Critical section = 0x6A262820 (ntdll!RtlCriticalSectionLock+0x0)

LOCKED

LockCount = 0x0

OwningThread = 0x460

RecursionCount = 0x1

LockSemaphore = 0x0

SpinCount = 0x0

-----------------------------------------

DebugInfo = 0x6A261D80

Critical section = 0x6A262580 (ntdll!DeferedCriticalSection+0x0)

NOT LOCKED

LockSemaphore = 0x7FC

SpinCount = 0x0

-----------------------------------------

DebugInfo = 0x6A262600

Critical section = 0x6A26074C (ntdll!LoaderLock+0x0)

NOT LOCKED

LockSemaphore = 0x0

SpinCount = 0x0

.....

Dump information about all the active critical sections in the current process, including initialization stack trace

0:001> !cs -s

...

-----------------------------------------

DebugInfo = 0x6A261EA0

Critical section = 0xA8001C (+0xA8001C)

NOT LOCKED

LockSemaphore = 0x0

SpinCount = 0x0

No stack trace saved

-----------------------------------------

DebugInfo = 0x6A261EC0

Critical section = 0x6A263560 (ntdll!RtlpDphTargetDllsLock+0x0)

NOT LOCKED

LockSemaphore = 0x0

SpinCount = 0x0

No stack trace saved

-----------------------------------------

DebugInfo = 0x6A261EE0

Critical section = 0xA90608 (+0xA90608)

NOT LOCKED

LockSemaphore = 0x7EC

SpinCount = 0x0

Stack trace for DebugInfo = 0x6A261EE0:

0x6A2137BD: ntdll!RtlInitializeCriticalSectionAndSpinCount+0x9B

0x6A20B0DC: ntdll!CsrpConnectToServer+0x1BE

0x6A20B2AA: ntdll!CsrClientConnectToServer+0x148

0x77DBE83F: KERNEL32!BaseDllInitialize+0x11F

0x6A207A4C: ntdll!LdrpCallInitRoutine+0x14

0x6A205569: ntdll!LdrpRunInitializeRoutines+0x1D9

0x6A20DCE1: ntdll!LdrpInitializeProcess+0xAE5

-----------------------------------------

DebugInfo = 0x6A261F00

Critical section = 0x77E1AEB8 (KERNEL32!BaseDllRegistryCache+0x18)

NOT LOCKED

LockSemaphore = 0x0

SpinCount = 0x0

Stack trace for DebugInfo = 0x6A261F00:

0x6A2137BD: ntdll!RtlInitializeCriticalSectionAndSpinCount+0x9B

0x6A207A4C: ntdll!LdrpCallInitRoutine+0x14

0x6A205569: ntdll!LdrpRunInitializeRoutines+0x1D9

0x6A20DCE1: ntdll!LdrpInitializeProcess+0xAE5


Debugging Exception Errors

The exception verifier debugger extension

The exception log records all exceptions that have occurred in the target process.

You can use the !avrf -ex Length extension command to display the last several exceptions; Length specifies the number of exceptions. If Length is omitted, all exceptions are displayed.

Here is an example:

0:000> !avrf -ex 4

=================================

Thread ID: 0000052c

Exception code: c0000008

Exception address: 6a226663

Exception record: 0012fb50

Context record: 0012fb64

Displayed 1 exception log entries.


Debugging Handles Errors

!htrace debugger extension

!htrace can be used in both user-mode debugger and kernel debugger to display stack trace information for one or all the handles in a process. This information is available if handle tracing is enabled for the process – automatically enabled if handle checking is enabled in the application verifier. Stack traces are saved every time the process is opening or closing a handle or when it is referencing an invalid handle.

The kernel debugger syntax for this extension is:

!htrace [ handle [process] ]

If handle is not specified or is 0, information about all the handles in the process will be displayed. If process is not specified, the current process will be used.

The user-mode debugger syntax is:

!htrace [handle]

The user-mode debugger extension always displays information about the current debugee process.

Examples:

Dump information about handle 7CC in process 815328b0

kd> !htrace 7CC 815328b0

Loaded \\...\kdexts extension DLL

Process 0x815328B0

ObjectTable 0xE15ECBB8

--------------------------------------

Handle 0x7CC - CLOSE:

0x8018FCB9: ntoskrnl!ExDestroyHandle+0x103

0x801E1D12: ntoskrnl!ObpCloseHandleTableEntry+0xE4

0x801E1DD9: ntoskrnl!ObpCloseHandle+0x85

0x801E1EDD: ntoskrnl!NtClose+0x19

0x77DBFCD6: KERNEL32!GetLocaleFileInfo+0x3D

0x77DBF942: KERNEL32!NlsProcessInitialize+0x11D

0x77E0C6DF: KERNEL32!NlsDllInitialize+0x35

0x6A20785C: ntdll!LdrpCallInitRoutine+0x14

0x6A205393: ntdll!LdrpRunInitializeRoutines+0x1D9

0x6A20DD80: ntdll!LdrpInitializeProcess+0xAF6

--------------------------------------

Handle 0x7CC - OPEN:

0x8018F44A: ntoskrnl!ExCreateHandle+0x94

0x801E3180: ntoskrnl!ObpCreateHandle+0x304

0x801E1563: ntoskrnl!ObOpenObjectByName+0x1E9

0x77DBFCD6: KERNEL32!GetLocaleFileInfo+0x3D

0x77DBF942: KERNEL32!NlsProcessInitialize+0x11D

0x77E0C6DF: KERNEL32!NlsDllInitialize+0x35

0x6A20785C: ntdll!LdrpCallInitRoutine+0x14

0x6A205393: ntdll!LdrpRunInitializeRoutines+0x1D9

0x6A20DD80: ntdll!LdrpInitializeProcess+0xAF6

--------------------------------------

Parsed 0x1CA stack traces.

Dumped 0x2 stack traces.

Dump information about all handles in process 815328b0

kd> !htrace 0 81400300

Process 0x81400300

ObjectTable 0xE10CCF60

--------------------------------------

Handle 0x7CC - CLOSE:

0x8018FCB9: ntoskrnl!ExDestroyHandle+0x103

0x801E1D12: ntoskrnl!ObpCloseHandleTableEntry+0xE4

0x801E1DD9: ntoskrnl!ObpCloseHandle+0x85

0x801E1EDD: ntoskrnl!NtClose+0x19

0x010012C1: badhandle!mainCRTStartup+0xE3

0x77DE0B2F: KERNEL32!BaseProcessStart+0x3D

--------------------------------------

Handle 0x7CC - OPEN:

0x8018F44A: ntoskrnl!ExCreateHandle+0x94

0x801E3390: ntoskrnl!ObpCreateUnnamedHandle+0x10C

0x801E7317: ntoskrnl!ObInsertObject+0xC3

0x77DE23B2: KERNEL32!CreateSemaphoreA+0x66

0x010011C5: badhandle!main+0x45

0x010012C1: badhandle!mainCRTStartup+0xE3

0x77DE0B2F: KERNEL32!BaseProcessStart+0x3D

--------------------------------------

Handle 0x7DC - BAD REFERENCE:

0x8018F709: ntoskrnl!ExMapHandleToPointerEx+0xEA

0x801E10F2: ntoskrnl!ObReferenceObjectByHandle+0x12C

0x801902BE: ntoskrnl!NtSetEvent+0x6C

0x80154965: ntoskrnl!_KiSystemService+0xC4

0x010012C1: badhandle!mainCRTStartup+0xE3

0x77DE0B2F: KERNEL32!BaseProcessStart+0x3D

--------------------------------------

Handle 0x7DC - CLOSE:

0x8018FCB9: ntoskrnl!ExDestroyHandle+0x103

0x801E1D12: ntoskrnl!ObpCloseHandleTableEntry+0xE4

0x801E1DD9: ntoskrnl!ObpCloseHandle+0x85

0x801E1EDD: ntoskrnl!NtClose+0x19

0x010012C1: badhandle!mainCRTStartup+0xE3

0x77DE0B2F: KERNEL32!BaseProcessStart+0x3D

--------------------------------------

Handle 0x7DC - OPEN:

0x8018F44A: ntoskrnl!ExCreateHandle+0x94

0x801E3390: ntoskrnl!ObpCreateUnnamedHandle+0x10C

0x801E7317: ntoskrnl!ObInsertObject+0xC3

0x77DE265C: KERNEL32!CreateEventA+0x66

0x010011A0: badhandle!main+0x20

0x010012C1: badhandle!mainCRTStartup+0xE3

0x77DE0B2F: KERNEL32!BaseProcessStart+0x3D

--------------------------------------

Parsed 0x6 stack traces.

Dumped 0x5 stack traces.

Dump information about handle 7DC in the current process

kd> !htrace 7DC

Process 0x81400300

ObjectTable 0xE10CCF60

--------------------------------------

Handle 0x7DC - BAD REFERENCE:

0x8018F709: ntoskrnl!ExMapHandleToPointerEx+0xEA

0x801E10F2: ntoskrnl!ObReferenceObjectByHandle+0x12C

0x801902BE: ntoskrnl!NtSetEvent+0x6C

0x80154965: ntoskrnl!_KiSystemService+0xC4

0x010012C1: badhandle!mainCRTStartup+0xE3

0x77DE0B2F: KERNEL32!BaseProcessStart+0x3D

--------------------------------------

Handle 0x7DC - CLOSE:

0x8018FCB9: ntoskrnl!ExDestroyHandle+0x103

0x801E1D12: ntoskrnl!ObpCloseHandleTableEntry+0xE4

0x801E1DD9: ntoskrnl!ObpCloseHandle+0x85

0x801E1EDD: ntoskrnl!NtClose+0x19

0x010012C1: badhandle!mainCRTStartup+0xE3

0x77DE0B2F: KERNEL32!BaseProcessStart+0x3D

--------------------------------------

Handle 0x7DC - OPEN:

0x8018F44A: ntoskrnl!ExCreateHandle+0x94

0x801E3390: ntoskrnl!ObpCreateUnnamedHandle+0x10C

0x801E7317: ntoskrnl!ObInsertObject+0xC3

0x77DE265C: KERNEL32!CreateEventA+0x66

0x010011A0: badhandle!main+0x20

0x010012C1: badhandle!mainCRTStartup+0xE3

0x77DE0B2F: KERNEL32!BaseProcessStart+0x3D

--------------------------------------

Parsed 0x6 stack traces.

Dumped 0x3 stack traces.


Debugging Heap Errors

The heap verifier debugger extension

The heap verifier debugger extension is part of the !heap extension (NT heap debugger extension). Simple help can be obtained with !heap -? or more extensive with !heap -p -? . The current extension does not detect on its own if page heap is enabled for a process and act accordingly. For now the user of the extension needs to know that page heap is enabled and use commands prefixed by !heap -p .

!heap -p

Dumps addresses of all full page heaps created in the process.

!heap -p -h ADDRESS-OF-HEAP

Full dump of full page heap at ADDRESS-OF-HEAP.

!heap -p -a ADDRESS

Tries to figure out if there is a heap block at ADDRESS. This value does not need to be the address of the start of the block. The command is useful if there is no clue whatsoever about the nature of a memory area.

Heap operation log

The heap operation log tracks all heap routines. These include HeapAlloc, HeapReAlloc, and HeapFree.

You can use the !avrf -hp Length extension command to display the last several records; Length specifies the number of records.

You can use !avrf -hp -a Address to display all heap space operations that affected the specified Address. For an allocation operation, it is sufficient that Address be contained in the allocated heap block. For a free operation, the exact address of the beginning of the block must be given.

For each entry in the log, the following information is displayed:

The heap function called.

The thread ID of the thread that called the routine.

The address involved in the call — this is the address that was returned by an allocation routine or that was passed to a free routine.

The size of the region involved in the call.

The stack trace of the call.

The most recent entries are displayed first.

In this example, the two most recent entries are displayed:

0:001> !avrf -hp 2

alloc (tid: 0xFF4):

address: 00ea2fd0

size: 00001030

00403062: Prymes!_heap_alloc_dbg+0x1A2

00402e69: Prymes!_nh_malloc_dbg+0x19

00402e1e: Prymes!_malloc_dbg+0x1E

00404ff3: Prymes!_stbuf+0xC3

00401c23: Prymes!printf+0x43

00401109: Prymes!main+0xC9

00402039: Prymes!mainCRTStartup+0xE9

77e7a278: kernel32!BaseProcessStart+0x23

alloc (tid: 0xFF4):

address: 00ea07d0

size: 00000830

00403062: Prymes!_heap_alloc_dbg+0x1A2

00402e69: Prymes!_nh_malloc_dbg+0x19

00402e1e: Prymes!_malloc_dbg+0x1E

00403225: Prymes!_calloc_dbg+0x25

00401ad5: Prymes!__initstdio+0x45

00401f38: Prymes!_initterm+0x18

00401da1: Prymes!_cinit+0x21

00402014: Prymes!mainCRTStartup+0xC4

77e7a278: kernel32!BaseProcessStart+0x23

Typical debug scenarios

There are several failure scenarios that might be encountered. Some of them require quite a bit of detective work to get the whole picture.

Access violation in non-accessible page

This happens when full page heap is enabled if the tested application accesses beyond the end of buffer. It can also happen if it touches a freed block. In order to understand what is the nature of the address on which the exception occurred, you need to use:

!heap –p –a ADDRESS-OF-AV

Corrupted block message

At several moments during the lifetime of an allocation (allocation, user free, real free) the page heap manager checks if the block has all fill patterns intact and the block header has consistent data. If this is not the case you will get a verifier stop.

If the block is a full page heap block (for example, if you know for sure full page heap is enabled for all allocations) then you can use “!heap –p –a ADDRESS” to find out what are the characteristics of the block.

If the block is a light page heap block then you need to find out the start address for the block header. You can find the start address by dumping 30-40 bytes below the reported address and look for the magic start/end patterns for a block header (ABCDAAAA, ABCDBBBB, ABCDAAA9, ABCDBBBA).

The header will give all the information you need to understand the failure. Particularly, the magic patterns will tell if the block is allocated or free if it is a light page heap or a full page heap block. The information here has to be matched carefully with the offending call.

For example if a call to HeapFree is made with the address of a block plus four bytes, then you will get the corrupted message. The block header will look fine but you will have to notice that the first byte after the end of the header (first byte after 0xDCBAXXXX magic value) has a different address then the one in the call.

Special fill pointers

The page heap manager fills the user allocation with values that will look as kernel pointers. This happens when the block gets freed (fill value is F0) and when the block gets allocated but no request is made for the block to be zeroed (fill value is E0 for light page heap and C0 for full page heap). The non-zeroed allocations are typical for malloc/new users. If there is a failure (access violation) where a read/write is attempted at addresses like F0F0F0F0, E0E0E0E0, C0C0C0C0 then most probably you hit one of these cases.

A read/write at F0F0F0F0 means a block has been used after it got freed. Unfortunately you will need some detective work to find out which block caused this. You need to get the stack trace of the failure and then inspect the code for the functions on the stack. One of them might make a wrong assumption about an allocation being alive.

A read/write at E0E0E0E0/C0C0C0C0 means the application did not initialize properly the allocation. This also requires code inspection of the functions in the current stack trace. Here it is an example for this kind of failure. In a test process an access violation while doing a HeapFree on address E0E0E0E0 was noticed. It turned out that the test allocated a structure, did not initialize it correctly and then called the destructor of the object. Since a certain field was not null (it had E0E0E0E0 in it) it called delete on it.


Debugging Memory Errors

The memory verifier debugger extension

The virtual space operation log tracks all routines that modify the virtual space of a process in any way. These include VirtualAlloc, VirtualFree, MapViewOfFile, and UnmapViewOfFile.

You can use the !avrf -vs Length extension command to display the last several records; Length specifies the number of records.

You can use !avrf -vs -a Address to display all virtual space operations that affected the specified Address. For an allocation, it is sufficient that Address be contained in the allocated block. For a free, the exact address of the beginning of the region must be given.

For each entry in the log, the following information is displayed:

The function called

The thread ID of the thread that called the routine

The address involved in the call — this is the address that was returned by an allocation routine or that was passed to a free routine

The size of the region involved in the call

The type of memory operation (the AllocationType parameter)

The type of protection requested

The stack trace of the call

Examples

The most recent entries are displayed first.

In the following example, the two most recent entries are displayed:

0:001> !avrf -vs 2

VirtualFree (tid: 0xB4): addr:04bb0000 sz:00400000 op:8000 prot:0

00aa1ac2: verifier!VsLogCall+0x42

00aa19c1: verifier!AVrfpNtFreeVirtualMemory+0x30

68925d17: kernel32!VirtualFreeEx+0x35

6892611c: kernel32!VirtualFree+0x13

75ef6525: mshtml+0x116525

75ef68af: mshtml+0x1168AF

6a20787c: ntdll!LdrpCallInitRoutine+0x14

6a211c6f: ntdll!LdrUnloadDll+0x39A

689275c1: kernel32!FreeLibrary+0x3B

77b22d69: ole32!CoQueryReleaseObject+0x1E6

77b02bd2: ole32!SetErrorInfo+0x1ED

VirtualFree (tid: 0xB4): addr:04bb0000 sz:00001000 op:4000 prot:0

00aa1ac2: verifier!VsLogCall+0x42

00aa19c1: verifier!AVrfpNtFreeVirtualMemory+0x30

68925d17: kernel32!VirtualFreeEx+0x35

6892611c: kernel32!VirtualFree+0x13

75ef65ae: mshtml+0x1165AE

75ef68af: mshtml+0x1168AF

6a20787c: ntdll!LdrpCallInitRoutine+0x14

6a211c6f: ntdll!LdrUnloadDll+0x39A

689275c1: kernel32!FreeLibrary+0x3B

77b22d69: ole32!CoQueryReleaseObject+0x1E6

77b02bd2: ole32!SetErrorInfo+0x1ED

It can be seen from the output that thread 0xB4 first decommitted a page and then released the entire virtual region.

Here is a display of all operations affecting the address 0x4BB1000:

0:001> !avrf -vs -a 4bb1000

Searching in vspace log for address 04bb1000 ...

VirtualFree (tid: 0xB4): addr:04bb0000 sz:00400000 op:8000 prot:0

00aa1ac2: verifier!VsLogCall+0x42

00aa19c1: verifier!AVrfpNtFreeVirtualMemory+0x30

68925d17: kernel32!VirtualFreeEx+0x35

6892611c: kernel32!VirtualFree+0x13

75ef6525: mshtml+0x116525

75ef68af: mshtml+0x1168AF

6a20787c: ntdll!LdrpCallInitRoutine+0x14

6a211c6f: ntdll!LdrUnloadDll+0x39A

689275c1: kernel32!FreeLibrary+0x3B

77b22d69: ole32!CoQueryReleaseObject+0x1E6

77b02bd2: ole32!SetErrorInfo+0x1ED

VirtualFree (tid: 0xB4): addr:04bb1000 sz:00001000 op:4000 prot:0

00aa1ac2: verifier!VsLogCall+0x42

00aa19c1: verifier!AVrfpNtFreeVirtualMemory+0x30

68925d17: kernel32!VirtualFreeEx+0x35

6892611c: kernel32!VirtualFree+0x13

75ef65ae: mshtml+0x1165AE

75ef68af: mshtml+0x1168AF

6a20787c: ntdll!LdrpCallInitRoutine+0x14

6a211c6f: ntdll!LdrUnloadDll+0x39A

689275c1: kernel32!FreeLibrary+0x3B

77b22d69: ole32!CoQueryReleaseObject+0x1E6

77b02bd2: ole32!SetErrorInfo+0x1ED

VirtualAlloc (tid: 0xB4): addr:04bb0000 sz:00010000 op:1000 prot:4

00aa1ac2: verifier!VsLogCall+0x42

00aa1988: verifier!AVrfpNtAllocateVirtualMemory+0x37

68925ca3: kernel32!VirtualAllocEx+0x61

68926105: kernel32!VirtualAlloc+0x16

75ef63f3: mshtml+0x1163F3

VirtualAlloc (tid: 0xB4): addr:04bb0000 sz:00400000 op:2000 prot:4

00aa1ac2: verifier!VsLogCall+0x42

00aa1988: verifier!AVrfpNtAllocateVirtualMemory+0x37

68925ca3: kernel32!VirtualAllocEx+0x61

68926105: kernel32!VirtualAlloc+0x16

75ef63d9: mshtml+0x1163D9

To read this, remember that the entries are dumped starting with the most recent one. Thus, this log shows that thread 0xB4 allocated a large region in which it committed a page. Later it decommitted the page, and then released the entire virtual region.


Debugger install and setup

Microsoft Debugging Tools for Windows is available in three different versions: a 32-bit package and two 64-bit packages. These packages can be installed from the Web.

Some Application Verifier actions can result in an exception being raised. The debugger must be set to catch these exceptions on the second chance, because Application Verifier itself will be handling the first chance exceptions.

The exceptions raised are of three types:

  • An access violation exception (0xC0000005) is generated if the heap option detects a heap buffer overrun. In some cases, the Check system path usage option can cause an access violation as well.

  • An invalid handle exception (0xC0000008) is generated when the Detect invalid handle usage option detects an invalid handle operation.

  • A stack overflow exception (0xC00000FD) is generated when the Check for adequate stack option detects that the initial stack was too short.

The easiest way to prepare for these events is to start the debugger on a command line as follows:

windbg -xd av -xd ch -xd sov ApplicationCommandLine

or

cdb -xd av -xd ch -xd sov ApplicationCommandLine

If you have already started the debugger, you can use the sxd (Set Exceptions) command to catch all access violations, invalid handles, and stack overflows as second-chance exceptions:

0:000> sxd av

0:000> sxd ch

0:000> sxd sov

Note It is theoretically possible to control Application Verifier through a kernel debugger. However, this is not recommended — it requires frequent use of the .process and .pagein commands, yet it gives you no more power than using a user-mode debugger.

Installing from the Web

To download the latest version of the tools, go to the Debugging Tolls for Windows website (http://go.microsoft.com/fwlink/?linkid=8708) and follow the instructions. The tool package is updated frequently, so updating your tools from the website assures that you have the most powerful debugging tools possible.

Configuring Hardware for User-Mode Debugging

User-mode debugging is generally done on a single machine: the debugger is run on the same computer as the application that failed.

In this case, no specific hardware setup is required. Throughout this document, the terms host computer and target computer are interchangeable in this case.

Configuring Software for User-Mode Debugging

Basic User-Mode Configuration

Before you can begin user-mode debugging, you must install the necessary symbol files and set certain environment variables.

Installing the Symbol Files

You must install the symbol files for the user-mode process that is being debugged. If this is an application you have written, it should be built with full symbol files. If it is a commercial application, the symbol files may be on the product disk; if not, contact the manufacturer.

If possible, you should also install the symbol files for the version of Microsoft Windows on which the user-mode process is running.

If you are performing remote debugging, the symbol file location depends on the method you are using:

If you are performing remote debugging through the debugger, the symbol files should be on the computer with the debugging server.

If you are performing remote debugging through remote.exe, the symbol files should be on the computer with the debugger.

If you are performing remote debugging through a process server or a KD connection server, the symbol files should be on computer with the smart client.

If you are controlling the user-mode debugger from the kernel debugger, the symbol files need to be on both computers.

Configuring Environment Variables

The debugger uses a variety of environment variables to indicate a number of important settings.

For more information on debuggers, please visit http://go.microsoft.com/fwlink/?linkid=8708.

Configuring Application Verifier with the Debugger using the Command line

To configure Application Verifier you can use the CDB or NTSD command line.

Use the following command line:

cdb OtherOptions -vf:Flags Target

Where Target is the name of the target application, and Flags specifies the desired Application Verifier options that are to be applied to this target.

Flags should be a sum of the bits representing the desired options. The individual bit values are as follows:

Flag value | Meaning
00000001 | HEAP CHECKS
00000004 | HANDLE CHECKS
00000008 | LOW RESOURCE SIM CHECKS
00000020 | TLS CHECKS
00000040 | DIRTY STACKS
00000200 | DANGEROUS APIS
00001000 | EXCEPTION CHECKS
00002000 | MEMORY CHECKS
00020000 | MISCELLANEOUS CHECKS
00040000 | LOCK CHECKS


Frequently Asked Questions about the Application Verifier

This section addresses popular questions that we've received around:

  • General Questions

  • Debugger Questions

  • Testing Scenario Questions

  • Test Specific Questions

  • Support


General Questions

Following is a list of questions received around the general usage of Application Verifier. Click on the question to see the response:

What is Application Verifier?

How do I uninstall Application Verifier?

How do I start Application Verifier?

Where are the logs stored?

Which platforms are supported?

What should I do if I have problems while using the Application Verifier?

Does Application Verifier verify managed code?

Why doesn't Application Verifier work with shsmp.dll?

What is Application Verifier?

Application Verifier is a runtime verification tool used to find bugs in Microsoft Windows-applications. Since it is a runtime tool the application code needs to be exercised in order to be verified. Good test coverage is therefore essential.

The typical usage scenario of Application Verifier is to enable it for the applications of interest (see questions below for how to do that) and then run all the tests you have written for your application. You will get a notification for any bug found in the form of a debugger break or a verifier log entry.

How do I uninstall Application Verifier?

To uninstall the Application Verifier, access the control panel by clicking Start, select Add or Remove Programs, then Remove a program, click Application Verifier, and then click Remove.

How do I start Application Verifier?

After installing Application Verifier you can either start it by accessing it in your list of programs OR by typing Appverif.exe on a command line. To do this, go to a command prompt or the Run box of the Startup menu. Type appverif.exe and then press Enter. This will start Application Verifier.

The Appverifer.exe binary is installed in the system directory and is used to make the tool settings.

Where are the logs stored?

The logs are stored in %USERPROFILE%\AppVerifierLogs

Which platforms are supported?

Application Verifier can be used on the following Windows platforms:

  • Windows XP

  • Windows Server 2003

  • Windows Vista

Application Verifier supports x86, X64 and IA64 platforms.

Please note that Windows 2000 and WinPE are not supported.

What should I do if I have problems while using the Application Verifier?

First, make sure you are running the latest release.

Second, check to see if the issue is already known by the team (see the help files).

Third, send a request to microsoft.public.win32.programmer.tools newsgroup and the team will respond as best as they can.

Does Application Verifier verify managed code?

AppVerifier cares about the interfaces between the operating system and the application. As a result, unless your managed code is performing interop against native APIs that have to do with Heaps, Handles, Critical Section, etc. your test cases are not going to give you any interaction with the interfaces that are verified.

We recommend leveraging the Managed Debugging Assistants for verifying your managed code. Please read more about them on MSDN.

Why doesn't Application Verifier work with shsmp.dll

It is a known issue that Application Verifier will not validate any file with the name 'shsmp.dll'. This is because there is a problem while running smartheap that causes a crash. Our workaround is to block this DLL. We are working on a long term solution so that this can be verified. Please check back in future releases.


Debugger Questions

Following are the list of questions received regarding the debugger. Click on the question to see the response:

Why did I receive an error telling me I need a debugger?

How do I run my application under a debugger?

How do I get help with a debugger?

How do I test stack expansion without any other instrumentation?

Stack check is on for my service, I can start/stop the service, but get an overflow

When using !avrf extension I get 'Application verifier is not enabled for this process...'

Why did I receive an error telling me I need a debugger?

The Basics verification layer within Application Verifier require that you run your application under a debugger. If you do not have a debugger associated to the application prior to selecting the test, you will receive a dialog reminding you that you will need to run your application under a debugger in order to obtain the logged information.

How do I run my application under a debugger?

See the Debugger install and setup topic. If this doesn't address your question, visit http://go.microsoft.com/fwlink/?linkid=8708.

How do I get help with a debugger?

Visit http://go.microsoft.com/fwlink/?linkid=8708.

How do I test stack expansion without any other instrumentation?

In general, stack expansion should be really tested in isolation from other verification layers, including heap. The reason is the following: each verification layers "thunks" an API or an exported point with some routine.

For example, a call to CreateFileA, will be a call to appvocre!NS_SecurityChecks::CreateFileA, that might call appvcore!NS_FillePaths::CreateFileA that might call kernel32!CreateFileA, that might call verifier!AVrfpNtCreateFile, that will call ntdll!NtCreateFile. You can see that the instrumentation has added 3 more "stacked" function calls, each one of them may and will consume more stack.

In the case below, the LH-verifier.dll is "thunking" every DllMain, and the "instrumented" heap code path will add more stack usage. Since the injected thread from the debugger does not use the IMAGE_NT_HEADERS defaults, the initially committed stack will not be enough to complete the APC state of a thread (a thread in the APC state executed the initialization code).

If you want to use Stack-Ckecs, probably the only other verification layer you should use if FirstChanceAccessViolation.

Stack check is on for my service; I can start/stop the service, but get an overflow

I turned the stack check on for my service. I am able to start and stop the service. But if I start a remote and connect a client to the remote and hit ctrl-brk to stop in the client debugger I get an overflow stop with the stack. Why?

Microsoft Windows XP does not have a fix for DbgUiIssueRemoteBreakin to create the injected thread with a big enough stack for the page-heap code.

Instead, you can do one of the following:

  • Use a more modern operating system.

  • Test the stack expansion without any other instrumentation (recommended, since superimposition of effects is non linear).

  • Debug from KD, where there is no need to inject a thread to break in the debugger.

  • Use suspensive non-invasive debugging.

When using !avrf extension I get 'Application verifier is not enabled for this process...'

The complete error received:

Application verifier is not enabled for this process. Use appverif.exe tool to enable it.

You probably have just the shim verification layers enabled and/or the heap in "pure" mode enabled. These are some of the possible causes.

Without any detail of what exactly was enabled before and what was enabled after the change (and what the change was), it is not possible to say anything meaningful.


Testing Scenario Questions

Following is a list of questions received around different testing scenarios. Click on the question to see the response:

How can I enable Application Verifier on my service but not others?

How do I run Application Verifier on a 64-bit application that is launched from a 32-bit application running under WOW64?

How do I debug my service that runs in a non-interactive window station?

Does AppVerifier do leak detection?

Which tests are recommended for security concerns?

How can I enable Application Verifier on my service but not others?

Make a copy of svchost.exe in the System32 directory and call the copy “Mysvchost.exe”.

Using regedit, open HKLM\System\CurrentControlSet\Services\MyService.

Edit the value “ImagePath”, which will be something like “%SystemRoot%\system32\svchost.exe -k myservice” and change svchost.exe to “Mysvchost.exe”.

Add “Mysvchost.exe” to the AppVerifier list and check the tests desired.

Reboot.

How do I run Application Verifier on a 64-bit application that is launched from a 32-bit application running under WOW64?

Simple version: The golden rule for enabling verifier settings on a given application is to match the bit-ness of the tool and the target process. That is: use the 32-bit appverif.exe for a 32-bit application (both running under WoW64) and use the 64-bit AppVerif.exe for the native 64-bit native target.

Long Version: Application Verifier settings are the proper union of "core" settings and "shim" settings.

Core settings

Core settings are stored under Image File Execution Options.

The "Debugger" value is read from the launching application. So, if you want to have 32-bit devenv.exe launching 64-bit my.exe and have it running under debugger, you must use the 32-bit registry key under WoW6432Node. The other values, for a 32-bit process, are read from both places, both the native IFEO and the WoW6432Node.

The reasoning is the following: a 32-bit process running under WoW is a 64-bit process running the Wow64 emulation loop. So, each 32-bit process is first a 64-bit process, and then a 32-bit process. The 64-bit IFEO will enable verifier on the Wow64cpu.dll code, while the 32-bit IFEO will enable verifier on the 32-bit code.

From the end-user point of view, verifier.dll is loaded twice (once in the 64-bit world, once in the 32-bit world). Since most of the people do not care about verifying wow64cpu.dll, the most accepted behavior for 32-bit processes is to only verify the 32-bit part. That is why the golden rule of "always match the bit-ness" applies.

How do I debug my service that runs in a non-interactive window station

To debug a service that runs in a non-interactive window station, do the following (only applies if you’re using ntsd/windbg):

Add a key to the registry under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options. The name of this key should be the name of the process (service.exe).

Create a REG_SZ value called Debugger and set this value to the path where your debugger resides. It must contain the full path, not just the name of the debugger. The command should include the –server option and a specific port or port range that the debugger should listen on. An example is c:\debuggers\ntsd.exe –server tcp:port=5500:5600 –g –G.

Connect to the debugger server by running the debugger with a –remote option. An example is: windbg.exe –remote tcp:=localhost,port=55xx where ‘xx’ is some number from 00 to 99 if you used a range on the server.

Does AppVerifier do leak detection?

Under Windows 7 and greater, there is a Leaks check option that will detect when a process leaks memory. Under earlier operating systems, AppVerifier does not test application for leak detection but looks for other memory issues.

Which tests are recommended for security concerns?

  • Heaps

  • Handles

  • Locks

  • Stacks (only for services and important processes that can take machine down)

Keep in mind that ObsoleteAPICalls will just spit out a warning for every call it sees to an API that is listed as obsolete or deprecated in MSDN. You should decide on a case by case basis if it is important for your application to switch to the new APIs. Some of the APIs are dangerous, and some have merely been superseded by a newer API with more options. Take a look at the "Dangerous APIs" section of Writing Secure Code, 2nd addition for more.

For applications that need to be highly reliable, like services and server programs, you should also enable the Stacks check. This checks to see if the stack commit size is adequate, by disabling stack growth. If the application quits immediately with a stack overflow, that means the application needs to be recompiled with a larger stack commit size. If you're a tester, and encounter a problem with an application while using the Stacks check, file a bug, assign it to your developer, and keep on testing.


Test Specific Questions

Following is a list of questions around testing. Click on the question to see the response:

Are critical section leaks important?

Can we deal programmatically with stack overflows?

The LoaderLock test is giving an error about calling DestroyWindow. Why can’t I call DestroyWindow in DllMain?

Is it expensive to increase initial stack commits to avoid overflows?

What about reserved stack size?

Are there recommendations on how to pick the right size for LINKER_STACKCOMMITSIZE=?

What are the memory requirements for the heap test?

Why am I receiving an ALL_ACCESS stop?

Why don’t I get any logs from the heap and lock tests?

Why is Fault Injection not working?

Why does Leak Verifier not report certain leaks?

Are critical section leaks important?

Whenever you leak a critical section you leak the following: an event handle, a small amount of kernel pool and a small heap allocation. These will get cleaned up if the process exits.

If your process is supposed to stay alive a long time, then these leaks can bite you. Since the fixes are very easy in 99% of the cases (developer just forgot to call RtlDeleteCriticalSection) you should address them.

Can we deal programmatically with stack overflows?

Establishing an exception handler in the initial thread function is not guaranteed to catch the potential stack overflows that might be raised. This is because the code that dispatches exceptions needs also a little bit of stack to execute on top of the current activation record. Since we just failed the stack extension it is very likely that we will step over the end of the committed stack and raise a second exception while trying to dispatch the first one. A double fault exception will terminate the process unconditionally.

The LoaderLock test is giving an error about calling DestroyWindow. Why can’t I call DestroyWindow in DllMain?

You do not control which thread is going to detach. If it is not the same thread that created the window, you cannot destroy the window. So you leak the window and the next time the window receives a message, you crash because the Wndproc has been unloaded.

You need to destroy the window before you get the process-detach. The danger is not that user32 will be unloaded. The danger is that you are being unloaded. So the next message that the window receives will crash the process because user32 will deliver the message to your Wndproc which does not exist any more.

Microsoft Windows operating system has thread affinity. Process-detach does not. The loader lock is not really the big problem; the problem is Dllmain. Process-detach is the last time your DLL gets to run code. You must get rid of everything before you return. But since Windows has thread affinity, you cannot clean up the window if you are on the wrong thread.

The loader lock enters into the picture if somebody has a global hook installed (e.g., spy++ is running). In this case, you enter a potential deadlock scenario. Again, the solution is to destroy the window before you get process-detach.

Is it expensive to increase initial stack commits to avoid overflows?

When you commit stack you are just reserving page file space. There is no performance impact. No physical memory is actually used. The only additional cost happens if you actually touch the stack space that you committed. But this will happen anyway even if you do not commit the stack upfront.

Let us see what would be the cost to make all services running in svchost.exe bulletproof. On a test machine, I get 9 svchost.exe processes having a total of 139 threads. If we set the default stack for each thread at 32K we will need roughly 32K x 200 ~ 6.4 Mb of page file space to commit all stacks upfront.

This is a pretty small price to pay for reliability.

What about reserved stack size?

There are interesting items, such as exception dispatching on IA64/AMD64 that requires "unexpected" extra stack. There might be some processing happening on RPC worker threads whose stack requirements are past reasonable attempts to measure them.

First of all, you should get an idea of all the thread pools living in the process. The NT-Thread-Pool, with the alertable-wait-threads is sometimes special, because, for example, if you use a database component from SQL, it will use alertable sleeps over a thread that is a target of user-APC. This can cause problems with nested calls.

Once you know all the thread pools, get an idea of how to control their stack requirements. For Example, RPC reads a registry key for the stack commit. The WDM pump threads get that from the image. For Other Thread Pools, the mileage may vary.

When you all threads are clear you can take some action. Not having a huge reserved space helps address space fragmentation only if threads comes and goes very often. If you have a stable thread pool that is in your control, then you might have an advantage in reducing the reserved space as well. It will really help in saving address space for the heaps and address space for users.

Are there recommendations on how to pick the right size for LINKER_STACKCOMMITSIZE=?

The value should be divisible by the page size (4k/8k depending on the CPU). Here are some guidelines to determine the size you need would do:

  1. Convert any recursive functions with potential unbound depth (or at least user inducible high depth) to iterative.

  2. Reduce alloca usage. Use heap or safealloca.

  3. Run Prefast with reduced stack size checking (say 8k). Fix those functions flagged as using too much stack.

  4. Set the stack commit to 16k.

  5. Run under a debugger bunch of tests with Application Verifier's "Stacks" check on.

  6. When you see stack overflow determine the worst offenders and fix them. (See step 5.)

  7. When you cannot reduce the stack usage any more bump by 8k. If you are > 64k there is something wrong, decrease back to 64k and see step 6. Otherwise go to step 5.

What are the memory requirements for the heap test?

For full heap tests, you'll need 256MB of RAM and at least a 1GB page file. For normal heap tests, you'll need at least 128MB of RAM. There are no specific processor or disk requirements.

Why am I receiving an ALL_ACCESS stop?

Any application that uses _ALL_ACCESS renders the object it is accessing unauditable because the audit log will not reflect what you have actually done with the object—only what you asked to do with the object.

This condition creates a camouflage for a more devious attack. An administrator scanning for an attack activity in progress will see nothing wrong with the person requesting ALL_ACCESS on key X, because a particular application always does that. The administrator will think "the person is probably just running Word". The administrator cannot tell that a hacker has penetrated my account and is now probing the system to determine what access I have, which he can exploit for his nefarious ends. The possibilities are endless.

The ACL issue with ALL_ACCESS is that you must always be granted it. If we wanted to someday deny you DELETE access to a certain key, we would not be able to. Even though you were not actually deleting the key, we would be breaking your application because you would request delete access.

Why don’t I get any logs from the heap and lock tests?

Those tests are verification layers built in the operative system (and not in the package) and report errors in a debugger. If you run an application with those tests enabled and have no crashes, then they are not reporting any problems.

If you do run into crashes, it will be necessary to run under a debugger, or pass the application to a developer to test more closely.

Why is fault injection not working?

The fault injection probability was changed to parts per million in AppVerifier builds released after February 2007 based on customer feedback. So, a probability of 0n20000 is 2%, 0n500000 is 50% and so on.

!avrf –flt debugger extension can be used to change the probability on the fly in the debugger. However, the Low Resource Simulation check for the process should be turned on for this to work.

!avrf debugger extension is part exts.dll that ships with the debugger package. The changes in !avrf that support the probability change are in the latest debugger package. If you are experiencing problems with fault injection, please update your debuggers and the AppVerifier package.

Why does Leak Verifier not report certain resource leaks?

Leak Verifier does not report any resource leaks while a DLL or EXE module is loaded. When a module is unloaded, Leak Verifier issues a stop if any of the resources that were allocated by the module have not been released.

To inspect resources allocated by a loaded DLL or EXE, use the !avrf -leak debugger extension.


Support

Only the latest release of Application Verifier is supported. As a result, if you feel that you have run into a bug with the tool, please download the latest release from the download center to see if the problem still occurs.

If you have found a problem with Application Verifier and you think it may be a bug, please notify the following newsgroup: microsoft.public.win32.programmer.tools.

If you are having problems identifying an error that was logged, please review the help file for the specific stop code. If you are still unable to figure out the problem, contact the newsgroup.


Copyright

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2006 Microsoft Corporation. All rights reserved.

Microsoft Excel, Microsoft Internet Explorer, Microsoft, MS-DOS, Windows, Windows Server, Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.