App Verifier Stop 00000900 using File Open Dialog

Question

My C++/MFC program uses the CFileDialog class to retrieve a filename to open. If I comment out the DoModal() call, no Verifier Stops occur. If the dialog is opened (even if it is then simply Canceled), the stops are generated -- three in a row.

So I tried the Common File Dialog Sample: https://github.com/Microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appplatform/commonfiledialog. Same thing: three AV 900 stops. Comment the call to IFileDialog::Show(), and the stops disappear.

NOTE: According to the source provided with MFC, the class CFileDialog wraps IFileDialog; CFileDialg::DoModal() wraps IFileDialog::Show().

I have duplicated this issue on two computers. On a third, it runs without problems! I made a point of synchronizing my build tools with those on the successful machine -- still get the stops. I compiled on the "good" computer and ran on the "bad" -- same result.

Here are the three Stops from a run of the Common File Dialog Sample:

VERIFIER STOP 00000900: pid 0x3CB4: A heap allocation was leaked. 

 0EBA0FC0 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
 046E0664 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
 145C6FD8 : Address of the owner dll name. Run du <address> to read the dll name.
 55AE0000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.

 VERIFIER STOP 00000900: pid 0x3CB4: A heap allocation was leaked.

 16289FD8 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
 04570E44 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
 145C6FD8 : Address of the owner dll name. Run du <address> to read the dll name.
 55AE0000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.

 VERIFIER STOP 00000900: pid 0x3CB4: A heap allocation was leaked.

 19FC6FC0 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
 046E0664 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
 145C6FD8 : Address of the owner dll name. Run du <address> to read the dll name.
 55AE0000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.

Here is a dump of the DLL name (the same in all three stops):

0:000> du 145C6FD8
145c6fd8  "explorerframe.dll"

As you can see, some of the addresses change from one stop to the next.

Here is the !heap output for the leaked allocation address (parameter 1) of the first Stop:

0:000> !heap -p -a 0EBA0FC0
    address 0eba0fc0 found in
    _DPH_HEAP_ROOT @ 5511000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                 eb1198c:          eba0fc0               3c -          eba0000             2000
          explorerframe!NscCloudStateIconTask::`vftable'
    63cda8b0 verifier!AVrfDebugPageHeapAllocate+0x00000240
    7720ef3e ntdll!RtlDebugAllocateHeap+0x00000039
    77176f80 ntdll!RtlpAllocateHeap+0x000000f0
    77176cdc ntdll!RtlpAllocateHeapInternal+0x0000104c
    77175c7e ntdll!RtlAllocateHeap+0x0000003e
    6444aa2f vrfcore!VfCoreRtlAllocateHeap+0x0000001f
    643c256c vfbasics!AVrfpRtlAllocateHeap+0x000000dc
    55bd8d74 explorerframe!NscCloudStateIconManager::AddNscCloudStateIconTask+0x00000070
    55b708b2 explorerframe!<lambda_25e1ad0bf4019def6afc5d5e883f2fc6>::operator()+0x000584e2
    55bd1dc0 explorerframe!CNscTree::SetCloudStateIcon+0x0000004d
    55bd85df explorerframe!CNscTree::_UpdateItemDisplayInfo+0x000000fc
    55bd8242 explorerframe!CNscTree::_TreeInvalidateItemInfo+0x000000b5
    55b730ad explorerframe!CNscTree::_EnumBackgroundDone+0x00053d2d
    55b482e4 explorerframe!CNscTree::OnQIUpdateEnumDone+0x00000074
    55b48246 explorerframe!CNscEnumQueueItem::Dispatch+0x00000096
    55b17571 explorerframe!CNscTree::_SubClassTreeWndProc+0x000005c1
    55b16f89 explorerframe!CNscTree::s_SubClassTreeWndProc+0x00000039
    7089ae02 COMCTL32!CallNextSubclassProc+0x000000c2
    7089acb1 COMCTL32!MasterSubclassProc+0x000000a1
    7501ef5b USER32!_InternalCallWinProc+0x0000002b
    75015eca USER32!UserCallWinProcCheckWow+0x0000033a
    75013c3a USER32!DispatchMessageWorker+0x0000022a
    75017e38 USER32!IsDialogMessageW+0x00000108
    7500288e USER32!DialogBox2+0x0000013d
    75002744 USER32!InternalDialogBox+0x000000d9
    75002662 USER32!DialogBoxIndirectParamAorW+0x00000032
    7500261b USER32!DialogBoxIndirectParamW+0x0000001b
    75883efe <Unloaded_comdlg32.dll>+0x00043efe
    75852338 <Unloaded_comdlg32.dll>+0x00012338
    009f289a CommonFileDialogSDKSample!BasicFileOpen+0x000001aa [D:\Projects - Temp\Common File Dialog Sample\CommonFileDialogApp.cpp @ 366]
    009f1aae CommonFileDialogSDKSample!wWinMain+0x0000013e [D:\Projects - Temp\Common File Dialog Sample\CommonFileDialogApp.cpp @ 923]
    009f5cad CommonFileDialogSDKSample!invoke_main+0x0000002d [D:\a01\_work\4\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 123]

I'm using:

VS2019
Toolset v142
Windows SDK Version 10.0.19041.0

Thanks in advance for any feedback. Will gladly provide any other requested info.

Cheers, Dave

Answer 1

Thanks SongZhu. Yes, the problem occurs any time the file open dialog is displayed -- even if it is immediately Canceled.

I've attached my project files (remove the extensions and replace hyphens with dots):

86363-commonfiledialogsdksample-sln.txt
86373-commonfiledialogsdksample-vcxproj.txt
86391-commonfiledialogsdksample-vcxproj-user.txt

Here is some WinDbg output:

• 86297-1-windbg-startup.txt -- WinDbg command output as the sample starts up
• 86288-2-windbg-basicfileopen.txt -- WinDbg command output after the Basic File Open button is pressed (the file open dialog is now displayed); Notice the exception and error
• 86289-3-windbg-oncancel.txt -- command output after clicking Cancel
• 86298-4-appverif-stop1.txt
• 86290-5-appverif-stop2.txt
• 86299-6-appverif-stop3.txt
• 86300-7-appverif-stop4.txt
• 86361-8-appverif-stop5.txt
• 86362-9-windbg-shutdown.txt -- WinDbg command output as the sample terminates normally

NOTE: This run produced five Verifier Stops: four 900 and one 350.

Files 4-7 contain the WinDbg output from the App Verifier 900 stops: the stop itself, output of !heap -p -a <parameter 1> (address of the leaked allocation), output of dps <parameter 2> (address to the allocation stack trace), output of du <parameter 3> (address of the owner dll name)

File 8 contains WinDbg output from the Verifier Stop 350: the stop itself, output of du <parameter 3> (DLL name address) and output of u <parameter 2> (address of the code that allocated this TSL index) after running .reload dlnashext.dll=<parameter 4>

Finally, here is some more specific info on my system:

OS:
Windows 10 Pro
Version 20H2
OS build 19042.867
Windows Feature Experience Pack 120.2212.551.0

Visual Studio:
Visual Studio 2019
Version 16.9.3
Visual C++ 2019
VS toolset v142
SDK Version 10.0.19041.0

Hopefully this helps. Maybe the SysInternals guys have some ideas. If you need anything else, please let me know.

Thanks!

Cheers,
Dave

Answer 2

I tried to build the project from your project file, but the code still works for me:

I think the problem is caused by your system, maybe you are missing some of the required library files. I suggest you go to the Windows related forums to ask questions.