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?
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.
Related
My app builds fine. Attempting to start it in debug mode, however, causes this error. This appeared after I solved an error relating to missing "debug symbols" similar to the one here (enabling the remote symbol servers in the options and then building caused this error to appear instead - this behavior persisted even after turning off the remote symbol servers in the options again).
I am using WinUI3 project on Visual Studio 2022 on Windows 11.
This post seems to suggest the issue was using WPF - but I am not using WPF. I also see a potentially similar issue here, but there appear to be no answers.
I am not sure where to even begin fixing this - it seems to be a Visual Studio issue or a project/solution config issue rather than a code issue. Any ideas?
I fixed it. I was looking at the output in the Visual Studio Console (after stopping the app once the error mentioned in the question happened), and I saw this:
Exception thrown at 0x00007FFD41D4466C (KernelBase.dll) in EmailClient.exe: WinRT originate error - 0x80004005 : 'WinUI: Error creating second Desktop Window on the current process. No more than one Desktop Window is allowed per process.'. onecore\com\combase\winrt\error\restrictederror.cpp(1017)\combase.dll!00007FFD43EAA21E: (caller: 00007FFD43D9A2F3) ReturnHr(2) tid(5e98) 8007007E The specified module could not be found.
I then searched through my project, and found out I was calling new MainWindow() one place in my project outside of the App.xaml.cs when initializing a property. I removed that (initializing the property to null instead), and now the app works fine. Not sure how the two are related... but this may be an unexpected behavior caused by attempting to create multiple windows on the same process. Here is someone else who had the same issue.
If your intention is to create multiple windows (mine was not) and you want to know how, then see this thread (a few months out-of-date... not sure if the mentioned features are still in preview or not as of time of posting).
I want to use libsamplerate library in my windows phone project.So I add its lib file to the linker input.As I run the project it doesn't even reach the native code entry point that I set a breakpoint there and encounter the error:
First-chance exception at 0x7723277C (KERNELBASE.DLL) in TaskHost.exe: 0xE0434352 (parameters: 0x8007007E, 0x00000000, 0x00000000, 0x00000000, 0x70BF0000).
As I comment the method which belong to libsamplerate library the error doesn't appear anymore. I searched the web for days with no successful result.
I had tried to use other 3d party library in windows phone runtime component and always encounter the same error.
What circumstances should the library have to be used in windows phone runtime component?
Can we use typical libraries in it or not?
I encountered a similar problem today with my "Direct3D with XAML" Windows Phone app. Although the address of the exception was different it turned out that one of the 3rd party libs wasn't on the phone. When I added the extra reference all worked fine for me.
Using the WebView control in the Windows 8 SDK Samples results in an unhandled 'Unspecified error'.
In my own project it gives me an unhandled exception of 'Unable to get property '1' of undefined or null reference'.
I can't catch it.
It doesn't happen if I deploy it to a Surface or on another machine so I think it's probably my machine.
I need to know what I can do to fix this issue on my machine.
Any help appreciated.
When you debug a XAML app with a WebView whose content has a JavaScript exception, that exception is elevated up through the WebView to Visual Studio where you (presumably) can debug it. When you run this (CTRL+F5) without debugging, these types of errors are swallowed. So your experience is not your machine, but the fact that the debugger is attached.
You can find a similar question and its answer here: https://stackoverflow.com/a/12249831/265706 But beware that the answer to that question suggests disabling the debugging mechanism. Make sure that is what you really want to do.
I'm currently trying to push off some time consuming tasks to an actionscript worker. This worker will in turn needs to call out to an AIR Native Extension as part of it's processing.
I've tried various combination in Flash Builder 4.7 i.e. embedded worker and external worker (with explicit packaging of the ANE in the external worker project) but alas I've been unable to get this to setup to work. I keep getting an error from the worker saying that the native extesion class could not be found (Error #1014).
Does anyone know if it is at all possible to do this or it's a limitation of Actionscript workers?
I'm guessing this might be a bit late now, but I've just been having this problem myself, and it was caused by the ANE not being packaged with the app when it's sent to the device / simulator.
Classes within the NE weren't being found at runtime, but were accessible in Flash Builder.
It turned out that by default the .ANE file wasn't copied to the device.
To fix this, change the following project property:
ActionScript Build Packaging -> Apple iOS -> Native Extensions -> Check 'Package' for the ANE
No idea why it wasn't included by default. When you uncheck 'Package' you get a warning telling you that it may cause runtime issues!
Hope this is of use for somebody.
I'm embedding mono in C++ application, and I'm linking it via dll library, which is then loaded into application via LoadLibrary.
When the application starts and the dll runtime linking happens, the mono runtime seems to fail to initialize itself with "Too many root sets" message. I'm unsure when and how the runtime itself is initialized (I thought it happens on mono_jit_init, but the error pops up before any call to any of the mono functions. It occurs exactly at LoadLibrary should I try load it manually instead of relying on mono.lib import library).
I succesfuly embedded it in standalone application, so I assume it is something specific to the way my dll is loaded by the application, but I don't know what exactly.
Any clues?
This may be a limitation of the way the Boehm GC works in windows: it hooks to the operating system at LoadLibrary time to get notifications of the created threads and loaded libraries (this is why you get the issue at LoadLibrary() time and not on mono_jit_init()).
Or it may be that you have really many threads and libraries loaded by the time the GC is initialized. If you link the app to mono directly, does the problem go away? If yes, that should be your current workaround.
In the future (or if building mono from git) you may be able to use the SGen GC which shouldn't suffer from this problem.