1

In a WinRT app when switching the debugger type to mixed (from managed), the application fails to start.. pausing the debugger shows execution is at: 

static void Main(string[] args)
 {
     global::Windows.UI.Xaml.Application.Start((p) => new App());
 }

The output window continually shows EETypeLoadExceptions as different memory locations:

First-chance exception at 0x757E4B32 in ApplicationName.exe: Microsoft C++ exception: EETypeLoadException at memory location 0x0BF7D134.

It looks like the CLR exception is:

CLR:(C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll) Rejecting native image because native image dependency C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll had a different identity than expected

I need to use the Native debugger for SOS Debugging Extension (SOS.dll)

When creating a new blank app and then adding the same dependencies as my app, I don't experience the problem, so its something specific to my app.

Any ideas on what the issue is or how to troubleshoot further? Anyone with experience using SOS Debugging Extension (SOS.dll) with WinRT apps?

user1694394
  • 101
  • 3
  • It is important to see the managed exception to debug this, the native exception isn't helpful. Debug + Exceptions, tick the Thrown checkbox for CLR exceptions. – Hans Passant Aug 07 '13 at 10:43
  • Looks like its coming from Ninject: `A first chance exception of type 'System.IO.FileNotFoundException' occurred in mscorlib.dll Additional information: Could not load file or assembly 'Ninject.Extensions.*.dll' or one of its dependencies. The system cannot find the file specified.` – user1694394 Aug 07 '13 at 13:43
  • Another useful way to diagnose module load issues is to use sysinternals process monitor to watch your application starting up. You can look for the DLL in question and see all the locations that the application probes when trying to load it, then figure out why the necessary DLL is not in one of those locations. – Andy Rich Aug 07 '13 at 17:40

1 Answers1

1

I had a managed application calling native COM objects that in turn call back some managed COM instances. At some point when a native COM was calling back a managed COM object EETypeLoadException was thrown.

It turned out that I had several assemblies in different projects with the same name (Common.dll). As all assemblies were unsigned .NET runtime could not load two different assemblies with the same name and reported the problem through EETypeLoadException.

I wish the diagnostics was more detailed but at least it's now resolved in my case.

mp31415
  • 6,531
  • 1
  • 44
  • 34