Home/ Questions/Q 4562624
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T18:14:31+00:00

I have a dynamically loaded & unloaded DLL which requires COMCTL32.dll >= v6.0 and

  • 0

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!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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

    • 0