none
TypeInitilizationException when trying to load C++/CLI DLL RRS feed

  • Question

  • Our client application is almost completely written in C++ and mfc. But recently we have integrated some managed implementations in C#. Therefore we use a Managed C++/CLI DLL with option /clr as a bridge for communicating between unmanaged C++ and C#.

    Someday we have experienced that our application does not work on network drives because of missing security permissions. So we signed our C# and Managed C++ DLLs with strong name key files. We registered the public keys at the client PCs by a batch file with caspol.

    This worked on most PCs. But at one of our test PCs (that has not visual studio installed) the Managed C++/CLI DLL can't be loaded from the unmanaged C++ application although we have installed the public keys. It throws the following exception (I translated the text from german into english):

    TypeInitializationException occured in unknown module
    Additional information: The Typinitalizer for <Module> has caused an exception

    I hoped to get more detailed information for this exception by remote debugging on that PC but there was no additional information available except of the stack trace:

         KERNEL32.DLL!_RaiseException@16()  + 0x56 Bytes   
         mscorwks.dll!RaiseTheExceptionInternalOnly()  + 0x10c Bytes   
         mscorwks.dll!RaiseTheException()  + 0x50 Bytes   
         mscorwks.dll!RaiseTheException()  + 0xc9 Bytes   
         mscorwks.dll!RealCOMPlusThrow()  + 0x38 Bytes   
         mscorwks.dll!RealCOMPlusThrow()  + 0xb Bytes   
         mscorwks.dll!MethodTable::DoRunClassInitThrowing()  + 0x2089b6 Bytes   
         mscorwks.dll!DomainFile::Activate()  + 0x13b35a Bytes   
         mscorwks.dll!DomainFile::DoIncrementalLoad()  + 0x5236 Bytes   
         mscorwks.dll!AppDomain::TryIncrementalLoad()  + 0x80 Bytes   
         mscorwks.dll!AppDomain::LoadDomainFile()  + 0xf9 Bytes   
         mscorwks.dll!AppDomain::LoadDomainAssembly()  + 0x61ae Bytes   
         mscorwks.dll!AppDomain::LoadExplicitAssembly()  + 0x43 Bytes   
         mscorwks.dll!ExecuteDLLForAttach()  + 0x13d Bytes   
         mscorwks.dll!ExecuteDLL()  + 0x1a8 Bytes   
         mscorwks.dll!CorDllMainForThunk()  + 0x8d Bytes   
         mscoree.dll!CorDllMainWorkerForThunk()  + 0x4b Bytes   
         mscoree.dll!_VTableBootstrapThunkInitHelper@4()  + 0x19 Bytes   
         mscoree.dll!_VTableBootstrapThunkInitHelperStub@0()  + 0xc Bytes   
    >    ******.exe!C_****App::InitInstance()  Zeile 1930 + 0x2b Bytes    C++

    So I have no exact information about what happened.

    The application works fine when it is started on local drive or when I give full rights for local intranet via caspol (%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\caspol -q -m -cg LocalIntranet_Zone FullTrust). This shows that it should be a permission problem.

    Now, I thought the key that is used by the Managed CLI/C++ DLL has not been installed correctly on the test PC. But when I use this key in another Managed C++/CLI DLL in a test project and then start this program on a network drive on the test PC all works fine.

    I don't know much about the global assembly cache but would it possible that the gac memorizes the permission of an assembly and therefore one DLL has the permissions and another DLL hasn't it although they use the same key file?
    If this woudl be possible how can I 'reset' the gac?

    Normally when a public key is not registered I get a detailed exception such as

    ...System.IO.FileLoadException occured in MyManagedCPPCLI.dll...
    The minimum permissions could not be given...

    So what could the TypeInitialization exception mean in detail?

    Thanks for any ideas!



    Thursday, June 12, 2008 2:12 PM

All replies

  • A TypeInitializationException occurs when the constructor or class member initializer failed.  The real reason for the failure is given in the InnerException property.  Could be anything, not necessarily a security issue.
    Hans Passant.
    Thursday, June 12, 2008 5:48 PM
    Moderator
  • First I forgot to say that the .NET Framework 2.0 is used for the application.

    As I wrote my problem is that the inner exception is not provided. I only get the following information when the exception is raised:

    TypeInitializationException occured in unknown module
    Additional information: The Typinitalizer for <Module> has caused an exception

    I have debugged with full debug information and I have activated in the Visual Studio that all Common Language Runtime Exceptions (menu: debug->exceptions) are thrown. Mixed Debugging is turned on for the Exe project of course.

    Is there any way to get the inner exception?

    I assume that the real exception is a security issue since it works on local drives and on network drives if I give full trust to the local intranet zone but surely there is no guarantee for that assumption.

    The exception is thrown when even when I call an empty class with an empty constructor in the cpp file. I have set a breakpoint into the empty constructor. It is not reached until the exception occured. But of course the error could occur by the implementation of a static constructor or a static member initialization of another class. These static initializations should be performed when the Managed DLL is loaded, right?

    So the next step will be removing all classes from the DLL and keep only the dummy class with the empty constructor that I call in the Unmanaged Exe and see what happens...




    Thursday, June 12, 2008 10:12 PM
  • Based on the following thread I think I know what might be wrong

    http://forums.msdn.microsoft.com/en-US/vcgeneral/thread/99c3b178-67b9-4764-b441-d3596b854fa6/


    When I analyze the application exe with the dependency walker on my developer PC I see that the following DLLs

    msvcm80.dll
    msvcp80.dll
    msvcr80.dll
    mfc80.dll

    are loaded from the following folders:

    c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.1433_x-ww_5cf844d2\MSVCM80.DLL
    c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.1433_x-ww_5cf844d2\MSVCP80.DLL
    c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.1433_x-ww_5cf844d2\MSVCR80.DLL
    c:\windows\winsxs\x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_3bf8fa05\MFC80.DLL

    (The file Microsoft.VC80.CRT.manifest and Microsoft.VC80.MFC.manifest in the binary folder describe that these DLLs should be loaded.)

    On the Test PC (a windows 2000 machine) the DLLs are loaded from the local application path (so far we deployed the DLLs additionally within the binary folder).

    Since these DLLs have policies that are defined in the "C:\Windows\winsxs\policies" it crashes when I start the application from a network drive.

    When I delete the DLLs in the binary folder the correct DLLs in the winsxs folder are loaded and all works fine. But why the DLLs in the binary folder are tried loading first instead of that in the WinSxS folder? How can I force that the WinSxS-DLLs are loaded first on any machine?


    • Edited by Aki999 Friday, June 13, 2008 1:25 PM reviewed
    Friday, June 13, 2008 12:06 PM
  • This looks like a question about loading order and native manifests. That is not part of CLR, so I would recommend you asking on Visual C++ General forum (there have been some threads about CRT DLLs failures) or find some WinSxS/Native fusion discussions.

    -Karel

    Thursday, June 19, 2008 6:24 PM
    Moderator