TypeInitializationException: The type initializer for '<Module>' threw an exception

Question

I've googled and debugged extensively and I can't figure out what causes this exception. Anecdotally re-installing the .NET framework sometimes fixes this, but it seems a little sketchy as a fix:

TypeInitializationException: The type initializer for '<Module>' threw an exception.
    The C++ module failed to load during appdomain initialization.

      The system cannot find the file specified

StackTrace:
   at CModuleInitialize.LoadWpfGfx(CModuleInitialize* )
   at CModuleInitialize.{ctor}(CModuleInitialize* )
   at ?A0x828d0bb1.??__E?A0x828d0bb1@cmiStartupRunner@@YMXXZ()
   at _initterm_m((fnptr)* pfbegin, (fnptr)* pfend)
   at <CrtImplementationDetails>.LanguageSupport.InitializePerAppDomain(LanguageSupport* )
   at <CrtImplementationDetails>.LanguageSupport._Initialize(LanguageSupport* )
   at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* )

Any clues?

Context

This is a WinForms app, written in C# with a handful of new components written in WPF. The crash reports we're getting don't include any more context than what I'm showing (stack trace, etc.) and we're not doing any C++, managed or otherwise.

I haven't been able to reproduce this crash, but remote diagnosis of a few customers suggest that re-installing the .NET framework may fix this problem for that customer.

Customers who report this crash do so several times and it appears they can't use the app until the .NET framework is re-installed, or they revert to an older version of the app that only used .NET 2.0

Links

Some links indicate a possible connection between beta versions of the .NET Framework, or visual studio and this crash, but that doesn't seem likely in this case.

Another possible connection may be with the Visual C++ 2005 redistributable.

Answer 1

You are looking at the bowels of PresentationCore, code written in C++/CLI. The name <Module> is the class name for all global C++/CLI functions. It bombs early, right after the assembly got loaded, the module initializer failed. The exact job done by LoadWpfGfx() isn't documented anywhere that I know but can be easily guessed. It is loading an unmanaged DLL that implements the graphics interface, probably the DirectX interface layer.

This is machine-specific problem. The function checks the registry for the proper DLL to load, then uses LoadLibrary() to load it. Clearly the DLL is missing. Your customer needs to get their machine stable again, then reinstall .NET. If they still have trouble then they can use SysInternals' ProcMon tool to see what registry keys and what DLL are being searched.

Answer 2

This was giving me headache for months. My code was built using Oxygene Pascal compiler, fully integrated with VS 2012. TypeInitializationException happen when the ..cctor fails to do its job somehow.

What did I do to find out why my a C# class lib code runs and my Oxygene class lib code constantly fails when accessed on a WCF web site web service under IIS 7.5 on a remote host, but BOTH worked perfect on a local scale, worked perfectly when doing VS 2012 Unit Testing.

OK, it' is a class library 1. I wrote a class library in CS ToolboxCS.cs 2. I wrote the same class library in Oxygene ToolboxPAS.pas 3. One ToolboxCS runs remotely and ToolboxPAS fails remotely 4. lets see the two codes 4a)

using System;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
namespace ToolboxCS
{
    [CompilerGenerated]
    [StructLayout(LayoutKind.Auto, CharSet = CharSet.Auto)]
    public static class __Global
    {
        public static string Stop_Time = "1949.Mar.19";
    }
}

4b) the Oxygene sample

namespace ToolboxPAS;
interface
uses
  System;
VAR
  Stop_Time: String := "1949.Mar.19";
implementation
end.

Then I took ILSpy.exe to look at code generated and found that the code disassemble to CS is the same. But looking with ILSPy.exe at the assembly information of the two examples, I could see many differences, some of them had no effect but the one shown below was the killer for my Oxygene ToolboxPAS.pas class lib when it should run on a IIS 7.5 -> w3wp.exe -> xyxyxyxyxy.dll -> ToolboxPAS.dll

{$IFDEF DEBUG}
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default or 
DebuggableAttribute.DebuggingModes.DisableOptimizations or 
DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints or 
DebuggableAttribute.DebuggingModes.EnableEditAndContinue)]
{$ENDIF}

In other words, if you do a debug build, your cs code will not show an assembly with this attributes in the assembly info file. But you will see this attributes generated and used looking with ILSpy.exe to the generated DLL.

And after I have added this attributes to my ToolboxPAS.pas Assembly Info file (as shown above) for the debug build it did no more raise InitializationException on a call to access only a simple variable in it.

Since I changed that in all assembly info files for my large DLL class libraries (12 DLL's) they run all like a sniff when deployed to a remote web server IIS 7.5 as WCF wen site web service.