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.

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