File handle leak on dynamically loaded DLL caused by activation context

I have a dynamically loaded & unloaded DLL which requires COMCTL32.dll >= v6.0 and MSVCR >= v9.0. To ensure that the correct versions are loaded, I enable manifest file generation in Visual Studio project setting, and add this entry to another manifest file:

<dependency>

<dependentAssembly>

<assemblyIdentity

type="win32"

name="Microsoft.Windows.Common-Controls"

version="6.0.0.0"

processorArchitecture="*"

publicKeyToken="6595b64144ccf1df"

language="*"

/>

</dependentAssembly>

</dependency>

In a test program I call LoadLibrary() followed by FreeLibrary() of that DLL, and ProcessExplorer indicates that the following File handles were leaked:

• C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e
• C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83

From disassembly开发者_运维知识库 call stack trace I learnt that on LoadLibrary(), an activation context was automatically created and it opens handles to each of these folders. But it appears that the activation context is not deleted on FreeLibrary().

If I remove the manifest files and set project settings to disable manifest generation, these leaks are gone. However, that way I will be unable to ensure that the correct MSVCR and COMCTL are used, since this DLL is loaded by processes I have no control over.

Is there a way to remove this leak without removing the manifest files?

Thanks!

The ProcessExplorer HANDLE leak reports are a symptom of an activation context leak. Most likely this leak is in your code indirectly in that you've not correctly called MFC.

To help yourself validate that this is your bug and not MFC's, you can create a simple MFC DLL from the AppWizard without any of your code and confirm that when it is LoadLibrary/FreeLibrary several times, there is no accumulative leak.

The missing OS call is either a ReleaseActCtx, or a missing DeactivateActCtx that caused the release to fail. In practice, MFC is calling these functions for you so you'll be looking for a missing MFC call of some kind.

The best debugging technique would probably be to trace or breakpoint the core activation context create/activate/deactivate/release functions (http://msdn.microsoft.com/en-us/library/aa374166(VS.85).aspx) and see what happens. You may see a bunch of calls so some kind of tracing may be necessary. Ideally you might capture the callstack at each call and review them. Your debugger may be able to help you do this. Recent versions of VS can run macros when they hit breakpoints.

As an aside, you are correct that you need the manifest files and should not remove them.

Martyn

The ProcessExplorer HANDLE leak reports are a symptom of an activation context leak. Most likely this leak is in your code indirectly in that you've not correctly called MFC.

It is not related to specific code usage. The issue has been confirmed by Microsoft: http://support.microsoft.com/kb/2624911

There is indeed a context activation leak in the SHELL32.DLL when calling UnregisterClass, affecting Windows Vista and up. The only work-around to the issue is to not repeatedly load and unload SHELL32.DLL. Microsoft is looking at a fix for this issue in newer versions of Windows.

These handles may be not leaked -- just cached. If you change your test program to load and unload your DLL repeatedly several times, do you see a new pair of handles leaked every time DLL unloads? If not, it's not an issue.

Does your DLL use MFC by any chance? I had an issue with an DLL which uses MFC and calls AfxWinInit() which might be related. This DLL (erroneously) called AfxWinInit() repeatedly and it turned out it leaked an activation context for each of these calls. Surprisingly this only happened when the calling application used a manifest.