2

I've been looking into why the debug build of our open scene graph plugins can't be loaded correctly (error code 14001, ERROR_SXS_CANT_GEN_ACTCTX). After much googling I've found out that the problem is that e.g. the freetype debug dll has a manifest that depends on both VC90 and VC80 debug crts.

Since I built the DLL from scratch using visual studio 2008 (generated w/ cmake) I can't think of any reason why the depenency to VC80 debug crt is there. And since VS 2005 is not installed I don't have any debug CRTs for that, and it's illegal to redist, so I need to figure this out.

Using the dependency walker on the dll the only crt dlls I find are

  • msvcr90d.dll
  • msvcp90d.dll
  • msvcrt.dll

No reference to any vc80 crts here. So where does that come from?

This is the manifest for the dll.

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level='asInvoker' uiAccess='false' />
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.VC90.DebugCRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
  </dependency>
</assembly>

Additional info:

Linker command line:

/OUT:"osgdb_freetyped.dll" 
/VERSION:0.0 
/INCREMENTAL 
/NOLOGO 
/DLL 
/MANIFEST 
/MANIFESTFILE:"osgdb_freetype.dir\Debug\osgdb_freetyped.dll.intermediate.manifest" 
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" 
/DEBUG 
/PDB:"osgdb_freetyped.pdb" 
/DYNAMICBASE 
/NXCOMPAT 
/IMPLIB:"osgdb_freetyped.lib" 
/ERRORREPORT:PROMPT 
/STACK:10000000 
/machine:I386 
/debug
kernel32.lib user32.lib gdi32.lib winspool.lib
shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib 
advapi32.lib  OpenThreadsd.lib osgd.lib osgDBd.lib osgUtild.lib 
osgTextd.lib freetype235_D.lib glu32.lib opengl32.lib 
osgDBd.lib osgd.lib OpenThreadsd.lib glu32.lib opengl32.lib

Manifest command line: 

    /nologo 
    /out:".\osgdb_freetype.dir\Debug\osgdb_freetyped.dll.embed.manifest" 
    /notify_update
Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
mandrake
  • 1,213
  • 1
  • 14
  • 28

1 Answers1

4

When compiling the DLL, are you linking to any static library dependencies? Those can bring in CRT references in the manifest; I've had problems before when linking in boost libraries that were compiled with a different version of VC.

EDIT: The manifest dependencies are basically emitted by some #pragmas that are included at compile time. Even though the code links, those #pragmas will add stuff to your manifest. The Microsoft documentation for native side-by-side assemblies (and how the manifest affects the loader) is here.

Aaron Klotz
  • 11,287
  • 1
  • 28
  • 22
  • Hmm, yes. Some of the linked libs are static (e.g. freetype235_D.lib). But since it's not linked until I build the DLL I must resolve all dependencies. But that doesn't include the CRT? But anyway, shouldn't the CRT show up in dependency walker if that where the case? – mandrake Nov 10 '10 at 07:52
  • After some more digging I found that, indeed the freetype235_D.lib was built using VS8. Kind of strange that it doesn't show up in depends though...? – mandrake Nov 10 '10 at 07:56
  • The dependency walker and manifests/activation contexts/SxS are completely separate beasts, I'm afraid. The code itself will link to your VC9 CRT, but it will still emit the extra dependency in your manifest. That's enough to throw everything off. – Aaron Klotz Nov 10 '10 at 07:57