the type initializer for <Module> threw an excpetion ...???


  • Hi All

    I have .Net solution with bunch of c++ and c# projects with .In Debug mode the application  is working fine.When I build the solution in release mode and try to run the application I am getting the strange error "The the type initializer  for <Module> threw an excpetion  The C++ Module failed to load during   native initialization".The problem with it is not throwing any error in debug mode,It was happening only in release mode,Can any aware of this problem?
    Wednesday, November 23, 2005 4:04 PM


  • Sounds like your release build isn't copying all the files it needs to run.  Verify that all the binaries that are needed are in the appropriate directory.  The output directory for debug is different than for release.

    Hope this helps,
    Michael Taylor - 11/23/05
    Wednesday, November 23, 2005 7:06 PM

All replies

  • Sounds like your release build isn't copying all the files it needs to run.  Verify that all the binaries that are needed are in the appropriate directory.  The output directory for debug is different than for release.

    Hope this helps,
    Michael Taylor - 11/23/05
    Wednesday, November 23, 2005 7:06 PM
  • I'm having the same problem; I don't have any files present in the Debug directory that aren't present in the Release directory.

    Any other ideas?

    I see this post is a year old; when searching on Google for this error message, oddly enough, this is the only thread/page I found mentioning the error.

    Appreciate any help you can provide.


    Tuesday, November 14, 2006 9:50 PM
  • I add myself to the list of folks having this strange problem.  I have a C# application that calls unmanaged code via a managed C++ wrapper class, and my Release version is throwing this exception.  It happens upon calling the constructor of the C# class that, in its constructor, initializes the C++ wrapper class.

    I'll add that I did see this error in my Debug build, as well -- though it seems to have gone away now, after a bunch of rebuilding. 

    Help, please.


    Monday, March 05, 2007 9:36 PM
  • I had a similar problem and I also found this forum to be the only place that this problem was even mentioned. I found out the there seems to be a problem with VS.NET 2005 SP1. I did the following:


    (1) I have a simple MFC dialog application that was created with an earlier version of Visual Studio. So it doesn't even have unicode support. This application was already converted to VS.NET 2005 and worked fine.


    (2) I decided to migrate this application to the .NET platform by activating the /clr compiler switch. This also worked fine.


    (3) Later I created a .NET user control by using the wizards. This control accesses a COM component. The language used was C++/CLI. For educational purposes I created the very same control using a C# project.

    Both user controls worked perfectly when integrated into the MFC dialog application. I have placed a button into the dialog application. The user control is placed on a separate dialog that is opened when I press this button.


    (4) I copied the release files + MFC80 release redistributables + CRT80 release redistributables to another machine and guess what happened? As soon as I pressed the button I received a .NET dialog that said "The type initializer for <MODULE> threw an exception". This message is a bug in itself as we cannot find out what's wrong at this point.

    However this problem only occurred when I used the user control created with C++/ CLI. If I used the C# user control it worked fine.


    It is obvious that the problem is caused by the way C++/ CLI is creating the user control. I inserted the following code into my MFC application to find out the root cause of the problem:




    CMyDialog cDlg;




    catch(System::Exception^ e)


    //here we go!

    AfxMessageBox(".NET exception: "+(CString)e->Message+"\nSource: "+(CString)e->Source);

    AfxMessageBox("Inner exception: "+(CString)e->InnerException->Message);



    After executing the application on the other PC the inner exception reported that msvcm80d.dll could not be found!!! Wow, what a confusing way to just find out that a library is missing? I started the release application on my development machine and looked carefully into the output window and I also saw my application loading the CRT80 debug libraries.

    This problem must be caused by some project settings for my C++/CLI based user control. I found out, that by turning off the Generate Debug Info property under Configuration Properties>Linker>Debugging the problem is gone!


    My Message to Microsoft is the following:


    (1) The should be a clear error message if a library is missing. That even was the case with plain old DLLs. The message given in .NET 2.0 is useless.


    (2) Default settings when creating a .NET user control in C++/CLI should be changed so that the release version doesn't cause debug libraries to be called by the hosting application! 

    Thursday, August 30, 2007 8:22 AM
  • Hi - I've been having this problem as well. I've been using C# for ages without a problem but recently I've been forced to move over to C++ and can't get anything to run because of this (I've had to use Borland BuilderX - not my favourite).

    I tried the solution you suggested but all that happened was a box popped up telling me I had debug info turned off (!)

    I am completely at a loss - can you think of any other solutions to this or should I put it down as yet another of Visual C++s charming eccentricities and stick with Borland???
    Friday, August 31, 2007 11:27 AM
  • Hi there

    Just to give another source for this issue;

    As i get this failure without having any c++/unmanaged projects in our software, i wanted to post something for other people because they may have this failure too, without having c++ projects used.

    I read somewhere in the internet (sorry i havent got a link) that someone had this issue with multiple assemblie's of the same type loitering around on the build-machine. This caused this failure as i remeber, resulting in the same <module> type initialization message box / failure code.

    So i tried to clean out my machine and get rid of all the assemblies, produced by our projects.
    To achieve this, i did a complete delete of all "bin/obj/doc" folders and all of its content on the machine we do our builds.

    The failure occured every time on the same project, after cleaning out, this failure occured "later" on other projects.

    I would welcome it, if somebody could have a hint what really causes the problem, since im not lucky with deleting all the stuff without knowing what exactly causes the problem. Especially when it does not completely solve the problems.

    Thanks for your Help

    Friday, May 02, 2008 1:53 PM
  • hi

    mostly you are setting control value in variable outside events in the body of the class

    for example:-

    Code Snippet

    Class Form1

    Dim s as string =  textbox1.text ' you cannot set the value of textbox or any control in the class body move it inside event rotten '

    Private Sub blablabla()

    'setting values must be here

    MessageBox.Show( s )

    End Sub

    End Class

    thanks and good luck
    Wednesday, May 28, 2008 1:19 PM
  • I was getting the same error in a mixed C# C++/CLI project i.e.

    "The type initializer for '<Module>' threw an exception."

    However I was only getting the error in Debug. Release was fine. The DLL generated was called Test.dll for debug and TestR.dll for release. The problem was that there was already a Test.dll from another project in my path. The solution was to generate a DLL called Test2.dll rather than Test.dll for debug. The problem then went away.

    This (multiple DLLs) appears to be a common theme in the previous posts as well

    Friday, November 21, 2008 2:15 PM
  • Hi,

    It may be that you are missing some dependent file, means the file on which any of your dll or other is dependent, tou might have forgot to include all.
    Please double check.

    Tuesday, July 28, 2009 12:44 PM
  • Hi,

    I am facing this issue in release version in machines where Visual studio is not installed. it works on machine where Visual Studio is installed. My C++ CLI dll is present in GAC. A small test application with C++ CLI is working on that machine when the dlls are present in application folder(Not in GAC).

    The inner exception says

    Inner Exception  : <CrtImplementationDetails>.ModuleLoadException: The C++ module failed to load.
     ---> System.IO.FileLoadException: Could not load file or assembly 'msvcm90, Version=9.0.30729.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))

     Anybody faced this issue before?

    Thanks In Advance,


    Monday, September 06, 2010 4:44 AM
  • Hi, one of our user is getting exception similar to above.

    An error occured while initializing Exception='System.TypeInitializationException: The type initializer for '<Module>' threw an exception. --->

    <CrtImplementationDetails>.ModuleLoadExceptionHandlerException: A nested exception occurred after the primary exception that caused the C++ module to fail to load.


    --- Start of primary exception ---

    System.Runtime.Serialization.SerializationException: Serialization error.


    Is there any workaround for this?

    Thursday, March 10, 2011 11:23 AM
  • Hi, just thought this might help someone. I had a module that worked well and then one day I got the type initializer ...exception. I fixed the problem as outlined below:

    Based on the pointers here I looked at my binaries and found that a dll indirectly referenced in my project had got deleted. (My project references a dll which in turn references another dll and this dll had got deleted). I suspect a clean build deleted the indirectly referenced dll.

    So you should be looking for bits that are not directly referenced in your project but come in via other dependencies.




    Thursday, June 09, 2011 11:13 AM
  • I got this TypeInitializationException was unhandled too.  Only on the release builds.

    Found it was caused by Changing my Platform target to Any CPU.

    I am using VS2010 Windows 7 Ultimate 64 bit.  I always set my debug to x86 so I can edit while debugging, but leave the release as Any CPU, which is normally OK. but not when you are calling 32bit  dll's on a 64 bit system.

    Thursday, June 23, 2011 8:24 PM