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

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 '&lt;Module&gt;' 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 &lt;CrtImplementationDetails&gt;.LanguageSupport.InitializePerAppDomain(LanguageSupport* )
   at &lt;CrtImplementationDetails&gt;.LanguageSupport._Initialize(LanguageSupport* )
   at &lt;CrtImplementationDetails&gt;.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.

Solution

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.