Application Verifier leak


  • I have a C++ Windows Mobile 5 (ARMV4I) Visual Studio 2008 project. I'm using Application Verifier to check for memory leaks.

    In one DLL loaded by the project, Application verifier sees a memory leak:
    TrackedItem count: 1
       0x2d87406c: shim_verifier.dll!(null) + 406ch
    Unable to open '\windows\' (GLE: 2)
       0x03116410: ole32.dll!(null) + 2410h
       0x030fa810: oleaut32.dll!(null) + 15810h
       0x030ec024: oleaut32.dll!(null) + 7024h
       0x030ef3cc: oleaut32.dll!(null) + a3cch
       0x030ef5c8: oleaut32.dll!(null) + a5c8h
       0x78264858: MyLibrary.dll!(null) + 4858h
       0x782646fc: MyLibrary.dll!(null) + 46fch
       0x78261bac: MyLibrary.dll!(null) + 1bach
       0x2c0112c8: !(null) + 112c8h
       0x2c011988: !(null) + 11988h
       0x03f67270: coredll.dll!(null) + 1d270h
    Leaked items:
       0x878e69cc   (oleaut32.dll)

    This address corresponds to a line in the DLL that instances a CComBSTR():
    HRESULT SomeFunction( LPCTSTR some_string )
        HRESULT hr = GetTheErrorCode();
        CComBSTR bstr( some_string ); // leak here
            The lines that would have used the bstr are commented
            out. It is never actually used in the function anymore.
        return hr;
    The easy solution is to remove the line that creates the CComBSTR. Unfortunately, it's not my code to change. I just want to know why Application Verifier is flagging this as a leak. I thought CComBSTR automatically called ::SysFreeString() in its destructor.

    Tuesday, January 26, 2010 6:38 PM


All replies

  • It is possible to explicitly free it. Try freeing and run AppVerifier.
    Hope this helps.
    // Declare a CComBSTR object
    CComBSTR bstrMyString( "Hello World" );
    // Free the string explicitly
    // The string will be freed a second time
    // when the CComBSTR object goes out of scope,
    // which is invalid.
    Taken from
    • Proposed as answer by guruzen Tuesday, February 16, 2010 8:53 AM
    Tuesday, February 16, 2010 8:53 AM
  • This is probably a false positive caused by COM's caching BSTR's see Raymond's post here

    You should set the OANOCACHE environment variable when checking for leaks.

    • Marked as answer by PaulH79 Monday, February 13, 2012 2:51 PM
    Sunday, February 12, 2012 11:16 AM