.Net executable with C++/CLI layer gets System.BadImageFormatException - c++-cli

This problem seems to be pretty common to anyone dealing with c++/cli, but I'm missing something with the typical resolution path. I have a .Net assembly, PHD.exe, that has a reference to a c++/CLI dll. This DLL dynamically links a number of win32 native dlls.
Exception text:
Main Window Exception: The type initializer for 'X.BLCInterfaceBehavior' threw an exception. System.BadImageFormatException: Could not load file or assembly 'CppCLI.dll' or one of its dependencies. is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)
Following other recommendations on SO, I check the target type for my executable. Right click > Properties > Build Tab > Platform = x86. Platform Target: x86.
Likewise, I check the project properties for the c++/cli dll ( I hope this is the correct place to look): Properties > Configuration Properties > Linker > Target Machine = MachineX86
I ran DependencyWalker on the CppCLI.dll, and get the following errors:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
I'm not sure how to identify which DLL is missing an expected export function, or if this is just one of this depends.exe quirks on an x64 system. Same thing applies to the modules with diff cpu types - I think I have seen "ignore that" message here on SO.
I ran the app against winDBG, and see that some windows DLLs are loading from SysWOW64 - this seems like its wrong. Some examples:
ModLoad: 75880000 75910000 C:\Windows\syswow64\GDI32.dll
ModLoad: 753f0000 753fa000 C:\Windows\syswow64\LPK.dll
ModLoad: 76c60000 76cfd000 C:\Windows\syswow64\USP10.dll
ModLoad: 76d00000 76da0000 C:\Windows\syswow64\ADVAPI32.dll
ModLoad: 75fe0000 76c2a000 C:\Windows\syswow64\SHELL32.dll
Shouldn't these be loaded from System32?
Finally WinDBG shows the exception, but I don't see anything useful:
ModLoad: 6dfc0000 6e060000 GambitManagedWrapper.dll
ModLoad: 01270000 01310000 GambitManagedWrapper.dll
ModLoad: 72eb0000 72ebe000 C:\Windows\SysWOW64\RpcRtRemote.dll
ModLoad: 6dfc0000 6e060000 C:\Gambit\GambitManagedWrapper.dll
(fbc.ebc): C++ EH exception - code e06d7363 (first chance)
(fbc.ebc): C++ EH exception - code e06d7363 (first chance)
(fbc.ebc): C++ EH exception - code e06d7363 (first chance)
(fbc.ebc): C++ EH exception - code e06d7363 (first chance)
(fbc.ebc): C++ EH exception - code e06d7363 (first chance)
(fbc.ebc): CLR exception - code e0434352 (first chance)
(fbc.ebc): C++ EH exception - code e06d7363 (first chance)
(fbc.ebc): CLR exception - code e0434352 (first chance)
(fbc.ebc): CLR exception - code e0434352 (first chance)
Additionally, I ran this command in winDBG, which further confuses things for me:
effmach #
Effective machine: x86 compatible (x86)
Not really sure where to go from here, and would appreciate any and all suggestions.

Related

wine tells me to install .NET and mono gives error "File does not contain a valid CIL image."

i want to run hunterpie.exe . I've test wine (i've installed wine-mono) which tells me :
A fatal error occurred. The required library hostfxr.dll could not be found.
If this is a self-contained application, that library should exist in [Z:\home\osafaimal\.local\share\Steam\steamapps\common\MonsterHunterRise\HunterPie\].
If this is a framework-dependent application, install the runtime in the global location [C:\Program Files\dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x64\InstallLocation].
The .NET runtime can be found at:
- https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=win7-x64&apphost_version=5.0.1
002c:err:eventlog:ReportEventW L"Description: A .NET application failed.\nApplication: HunterPie.exe\nPath: Z:\\home\\osafaimal\\.local\\share\\Steam\\steamapps\\common\\MonsterHunterRise\\HunterPie\\HunterPie.exe\nMessage: A fatal error occurred. The required library hostfxr.dll could not be found.\nIf this is a self-co"...
i've test to install .NET on my computer (Ubuntu 21.10 x86_64), Same error.
i've test to run with mono and it gives:
Cannot open assembly 'HunterPie.exe': File does not contain a valid CIL image.
Can someone explains what I should to do?

Unity Di container not working with 64 bit build

I am using Unity for in WCF service to load component.
I am referring below mention article.
https://msdn.microsoft.com/en-us/library/vstudio/hh323725(v=vs.100).aspx
Service is working fine when i build service in visual studio with build option option any CPU.
As one third party component required 64 bit specific build. So i selected 64 bit build option.
I have downloaded Unity code and build for 64 bit but it is also not working.
I am getting below mention exception.
Could not load file or assembly 'Common.Unity' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.BadImageFormatException: Could not load file or assembly 'Common.Unity' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Assembly Load Trace: The following information can be helpful to determine why the assembly 'Common.Unity' could not be loaded.
As this is not issue of Unity.
It is issue of IISExprees of VS2012 which is support on 32 bit.
Can't get IIS Express 8 beta to run website as 64-bit process
https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3254745-allow-for-iis-express-64-bit-to-run-from-visual-st

MissingMethodException with xsp4 and asp.net 4.5

I am trying to test a web site with xsp4, all assemblies are compiled for target framework 4.5. I get the following stack trace.
Exception during TraceManager initialization:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: An exception was thrown by the type initializer for System.Web.Configuration.TraceSection ---> System.MissingMethodException: Method not found: 'System.Configuration.ConfigurationProperty..ctor'.
--- End of inner exception stack trace ---
at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (System.Reflection.MonoCMethod,object,object[],System.Exception&)
A search here on stackoverflow (and other places) found that a possible reason is that xsp4 runs within the 4.0 directory of mono. Mine is already located in 4.5 and is used by the xsp script, so I am stuck with this one. Any ideas?
Found it. The error resulted from having a FSharp.Core.Dll within the bin folder. It is a mixed F# / C# project and a local copy is not needed, if the Dll resides within the GAC. Removing it made the error disappear.

Library not registered

I got this error :
Warning 1 Cannot get the file path for type library
"a5ededf4-2bbc-45f3-822b-e60c278a1a79" version 12.0. Library not
registered. (Exception from HRESULT: 0x8002801D
(TYPE_E_LIBNOTREGISTERED)) OCRMongo
In vb.net
I follow instruction from
http://www.techrepublic.com/forum/questions/101-345154/how-do-i-install-microsoft-modi-110
and I still get that warning. What's the problem?

LNK2001: What have I forgotton to set?

Following on from my previous question regarding debugging of native code, I decided to create a simple test from a console app as I wasn't getting anywhere with debugging the service directly.
So I created a vc6 console app, added the dll project to the workspace and ran it.
Instead of executing as expected it spat out the following linker errors:
main.obj : error LNK2001: unresolved external symbol "int __stdcall hmDocumentLAdd(char *,char *,long,char *,char *,long,long,long,long *)" (?hmDocumentLAdd##YGHPAD0J00JJJPAJ#Z)
main.obj : error LNK2001: unresolved external symbol "int __stdcall hmGetDocBasePath(char *,long)" (?hmGetDocBasePath##YGHPADJ#Z)
Debug/HazManTest.exe : fatal error LNK1120: 2 unresolved externals
This seems to be a simple case of forgetting something in the linker options: However everything seems to be normal, and the lib file, dll and source is available. If I change the lib file to load to nonsense it kicks up the fatal error LNK1104: cannot open file "asdf.lib", so that isn't a problem.
I have previously linked to dll and they have just worked, so what I have forgotton to do?
Update: As per this thread I looked to see if I could find out any additional information. This is what dumpbin from VS2005 gives me.
> dumpbin /linkermember Hazardman.lib | findstr "DocumentLAdd"
F6DC __imp__hmDocumentLAdd#36
F6DC _hmDocumentLAdd#36
5B __imp__hmDocumentLAdd#36
5B _hmDocumentLAdd#36
Then running it through undname results in:
> undname ?_hmDocumentLAdd#36
Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.
Undecoration of :- "?_hmDocumentLAdd#36"
is :- "?_hmDocumentLAdd#36"
Which is wrong. If I put in the mangled name from the IDE it gives the lot better result of:
> undname ?hmDocumentLAdd##YGHPAD0J00JJJPAJ#Z
Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.
Undecoration of :- "?hmDocumentLAdd##YGHPAD0J00JJJPAJ#Z"
is :- "int __stdcall hmDocumentLAdd(char *,char *,long,char *,char *,long,long,l
ong,long *)"
Now I have this information, what can I do with it? It seems from this Raymond Chen article I can manually fix it but tweaking an option, but my I can't discern from my results what option is needed (is there an 'ignore all parameters' checkbox?!).
So it seems that it is looking for non-existant functions or the parameters of the function have been left off (or dumpbin doesn't like VC6 libs), but it stil doesn't get me nearer my goal of fixing my problem.
Are you using the correct calling convention?
Your library appears to use stdcall. Maybe your test code is using cdecl (appears to be the default).
According to this page, the linker name decorations differ between the caling conventions so this can explain the symptoms you are seeing.