views:

46

answers:

1

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!

A: 

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.

atzz
Thanks for your response. I've tried that earlier, and for every LoadLibrary - FreeLibrary pair, there are two new file handles shown in ProcessExplorer. I've saved the process data at different points and diff them to be sure.
edwinbs