Application Verifier Stop: An HKEY was leaked

Question

While using Application Verifier and windbg to debug one of my VSTO addins, I found out that on Word close I get the following stop:

VERIFIER STOP 00000902: pid 0x3F1C: An HKEY was leaked. 

00000632 : Value of the leaked HKEY.
0422EA9C : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
1D3F6FE8 : Address of the owner dll name. Run du <address> to read the dll name.
74040000 : 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.

What is the best way to find out the cause of this stop?

Following the advice I did dps 0422EA9C

and the following was returned:

0422ea9c  0423f164
0422eaa0  0000e001
0422eaa4  001c0000
0422eaa8  740f3da0 vfbasics!AVrfpRegOpenKeyW+0xb0
0422eaac  74041e54 oledlg!CStringCache::Init+0x47
0422eab0  74041b51 oledlg!DllMain+0x2e
0422eab4  74041869 oledlg!_CRT_INIT+0x26d
0422eab8  7415c66d verifier!AVrfpStandardDllEntryPointRoutine+0x99
0422eabc  741c95fa vrfcore!VfCoreStandardDllEntryPointRoutine+0x12a
0422eac0  740e7904 vfbasics!AVrfpStandardDllEntryPointRoutine+0xa4
0422eac4  77698d04 ntdll!LdrpCallInitRoutine+0x14
0422eac8  7769c23d ntdll!LdrpRunInitializeRoutines+0x26f
0422eacc  7769aeb5 ntdll!LdrpLoadDll+0x453
0422ead0  7769afcc ntdll!LdrLoadDll+0xaa
0422ead4  740e7d2d vfbasics!AVrfpLdrLoadDll+0x5d
0422ead8  75072ca8 KERNELBASE!LoadLibraryExW+0x1f7
0422eadc  74e548f4 kernel32!LoadLibraryW+0x11
0422eae0  741a6871 vstoee!DllGetClassObject+0x4320
0422eae4  741a68a1 vstoee!DllGetClassObject+0x4350
0422eae8  6b5bfca5 mso!Ordinal4378+0x8dc
0422eaec  6ac85248 mso!MsoFLongSave+0xaa353
0422eaf0  6a686ddd mso!Ordinal9769+0x60b
0422eaf4  6a68667a mso!Ordinal1832+0x13b
0422eaf8  6be22bbb wwlib!DllGetClassObject+0x5dbef
0422eafc  6bdc7c2f wwlib!DllGetClassObject+0x2c63
0422eb00  6bdc4a4b wwlib!FMain+0x253
0422eb04  013815c4 winword+0x15c4
0422eb08  01381558 winword+0x1558
0422eb0c  74e5337a kernel32!BaseThreadInitThunk+0xe
0422eb10  776992b2 ntdll!__RtlUserThreadStart+0x70
0422eb14  77699285 ntdll!_RtlUserThreadStart+0x1b
0422eb18  00000000

Then du 1D3F6FE8

returned

1d3f6fe8  "oledlg.dll"

Interestingly, If I run Application Verifier / WinDbg on Word without my addin loaded I still get a stop:

APPLICATION_VERIFIER_LEAK_ALLOCATION (900)
A heap allocation was leaked.
This stop is generated if the owner dll of the allocation was dynamically unloaded while owning resources. 
Arguments:
Arg1: 0b7e2fb8, Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation. 
Arg2: 041495f4, Address to the allocation stack trace. Run dps <address> to view the allocation stack. 
Arg3: 0c446fe4, Address of the owner dll name. Run du <address> to read the dll name. 
Arg4: 70b50000, 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. 
GetPageUrlData failed, server returned HTTP status 404
URL requested: http://watson.microsoft.com/StageOne/winword_exe/15_0_4737_1003/559b7227/vrfcore_dll/10_0_15063_137/f4688fdb/80000003/00003809.htm?Retriage=1

Is this the same thing but reported differently?

did you try the suggestion in the above? `dps 0422EA9C` etc... — EdChum, May 11 '17 at 10:12
yes i did... not completely sure what to do with the output... — Leo, May 11 '17 at 10:14
Please include what you tried, the output from all the suggested commands etc. We're not here to guess what you did — EdChum, May 11 '17 at 10:18
You're supposed to run `du 1D3F6FE8 ` to get the dll name what you did was perform disassembly on the allocation stack — EdChum, May 11 '17 at 10:38
ah ok. thanks. that returns `1d3f6fe8 "oledlg.dll"`, i've updated the question — Leo, May 11 '17 at 10:40
Well it looks like the registry handle isn't being cleaned up, try `!handle 00000632 f` to display the `HKEY` info — EdChum, May 11 '17 at 10:45
Could be the handle is corrupted or your app state doesn't allow you to inspect that handle. Anyway, you have a call stack so you should be able to follow that and see what's wrong — EdChum, May 11 '17 at 10:48
well... the app is shutting down, so that could be the cause... If I run `!heap -p -a 0422EA9C` nothing is returned and `!dumpstack` does not have anything immediately obvious. — Leo, May 11 '17 at 10:54
I'd double check that all handles are being released and that the correct handle release method is being used — EdChum, May 11 '17 at 10:55
what do you mean? where? in our code? if the dll causing the issue is oledlg.dll, does that mean that the stop is not caused by our app? — Leo, May 11 '17 at 10:57
Either your code or whatever is loading `oledlg.dll` is not unloading that dll correctly, it could also be a bug in that dll in which case there isn't much you can do other than notify the vendor — EdChum, May 11 '17 at 10:59
Thanks for your help. That is a Microsoft dll... I think Word actually loads/uses it directly. Not sure... — Leo, May 11 '17 at 11:02
this is bug in *oledlg.dll* - it not close one registry key, when unloaded — RbMm, May 11 '17 at 13:12
@LeonardoSeccia - after more research can say that this is my error and Verifier error :) situation is next - i do simply test `FreeLibrary(LoadLibrary(L"oledlg"));` and note that in *oledlg!DllMain* 2 key handles created, but after unload - only one of it closed, second still opened. so handle `\REGISTRY\USER\_Classes` not closed. . but after more look i view that this is not error - *oledlg* call `RegOpenKeyW(HKEY_CLASSES_ROOT, L"CLSID", &g_hKey)` during initialization. in this call windows internal open additional key (name i paste). — RbMm, May 11 '17 at 14:16
*oledlg* correct close own key `\REGISTRY\USER\S-1-*_Classes\CLSID` but parent still open. however if again load/free *oledlg* (or open/close `HKEY_CLASSES_ROOT, L"CLSID"` - `_Classes` key not opened again, but used first opened — RbMm, May 11 '17 at 14:16
simply way for test - `HKEY hKey;if (!RegOpenKeyW(HKEY_CLASSES_ROOT, L"CLSID", &hKey))RegCloseKey(hKey);` during this will be opened (if it already not opened) and not closed key - `\REGISTRY\USER\S-1-5-*_Classes` - interesting are verifier will be detect this as leak ? — RbMm, May 11 '17 at 14:21
I have had 2 down-votes on this question... Why? I am keen to find out why so that i can improve the question. Thank you. — Leo, May 12 '17 at 09:53

score 1 · Accepted Answer · answered May 18 '17 at 11:30

I looked deeper into this as the very helpful comments above pointed me to think this is not an issue with my addin code but rather with the VSTO host application ie. Word.

So I created a simple VSTO addin with a one button ribbon that just opens a taskpane with a label which says “Hello!” (nothing else – no WPF) and I can confirm that even in this scenario I still get the HKEY Leak on shutdown…

For completeness, when no addins are loaded I get a different stop:

=======================================
VERIFIER STOP 0000000000000300: pid 0x4008: Invalid handle exception for current stack trace. 

    00000000C0000008 : Exception code.
    000000000F9DE670 : Exception record. Use .exr to display it.
    000000000F9DE180 : Context record. Use .cxr to display it.
    0000000000000000 : Not used.


=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.

=======================================

ModLoad: 711a0000 711c5000   C:\windows\SysWOW64\POWRPROF.DLL


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

    0BDCCFB8 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
    041D9C54 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
    0C36AFE4 : Address of the owner dll name. Run du <address> to read the dll name.
    749C0000 : 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.


=======================================

!avrf suggests a APPLICATION_VERIFIER_LEAK_ALLOCATION (900) so I don't think this is a problem with anything but Application Verifier.

Application Verifier Stop: An HKEY was leaked

1 Answers1