Edit

Determining If a Driver Leaks Framework Objects

  • Article

This topic describes how you can find driver memory leaks caused by unreleased references. It applies to User-Mode Driver Framework (UMDF) version 1 and 2 drivers.

UMDF 1

In UMDF version 1, a call stack can cause a memory leak if each call to AddRef does not have a matching Release call.

To test if your UMDF version 1 driver leaks framework objects, use the following steps:

  1. Use the WDF Verifier control application to set the verifier options that you want. During regular testing, start by setting TrackObjects and not TrackRefCounts.

    When the driver is unloaded, the framework's code verifier enters the debugger if a framework object was not deleted, and it prompts you to use the !wudfdumpobjects debugger extension. This debugger extension displays a list of undeleted objects.

  2. If the code verifier indicates that the driver is leaking framework objects, then use the control application to set the TrackRefCounts option.

    If this option is set, the verifier keeps track of references to framework objects while the driver runs. You can use the !wudfrefhist debugger extension to display each call stack (set of function calls) that increments or decrements an object's reference count. By examining the AddRef and Release calls in these call stacks, you should be able to find a stack that does not decrement the object's reference count and thus causes the leak.

For information about additional verifier options, see Using UMDF Verifier.

For information about when to delete framework objects, see Managing the Lifetime of Objects.

UMDF 2

In UMDF version 2, unreleased references are rare, but can occur due to call mismatches when using WdfObjectReference and WdfObjectDereference.

To test if your UMDF version 2 driver leaks framework objects, use the following procedure:

  1. Follow the steps outlined in Best Practices to configure your computer for UMDF debugging.

  2. To use tag tracking, enable both the UMDF Verifier and handle tracking in the registry. Both of these settings are stored in the driver's Parameters\Wdf subkey of the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WUDF\Services\<driver name> key.

    To enable the UMDF Verifier, set a nonzero value for VerifierOn.

    To enable handle tracking, set the value of TrackHandles to the name of one or more object types, or specify an asterisk (*) to track all object types.

    You can also modify UMDF Verifier settings by using the WdfVerifier.exe application.

  3. Reboot, establish a debugger connection, and then use the following debugger commands:

If UMDF Verifier is on, memory leaks are detected at driver unload, just as in KMDF.

For additional information about using reference counts in KMDF and UMDF version 2 drivers, see Framework Object Life Cycle.