On HRESULT 0x8007000B

Question

_{Monday, December 29, 2014 5:57 AM | 1 vote}

Here, in the Microsoft manner, is what happened and how to fix it:

An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
   at DLL_Load_Error_Research.LoadError.CallThroughDoesNothing(Int32 functionCode)
   at DLL_Load_Error_Research.LoadError.Run() in c:\CSOFTWARE\DLL Load Error Research\DLL Load Error Research\LoadError.cs:line 48

First, notice that we are handed an HRESULT.  This is detritous from the days of Component Object Model,
in which software was likened to electronics made up of interchangeable and replaceable parts.
The concept was a failure but a lot of COM code persists because there is so much of it.
An HRESULT is simply a standardized error code format.  Better to send out numbers than explanations.

Second, the problem here is NOT that the "program" is in "an incorrect format."
The format is quite correct.  It is just not to the loader's liking. 
The "program" is the 64-bit DLL spawned by Visual Studio during the same build that creates its brother 32-bit DLL.
When you feed your C# code the 32-bit DLL, all is generally well.
For some unknown reason, a call from C# through the "interop" mechanism to a 64-bit DLL is treated the same as a call to garbage.
It is inconceivable that anybody would deliberately present a misleading or inaccurate message in this case.  But there it is.

Here are the relevant bits of code.

From C++:

extern "C" _declspec(dllexport) BOOL _stdcall  CallThroughDoesNothing(int functionCode)  // exists to test the mechanism by which C# calls into unmanaged code and fails miserably with incomprehensible error message
{
 return false;
}

From C#:

        [System.Runtime.InteropServices.DllImport(@"C:\TRT32\GHP.dll")]
        public static extern bool CallThroughDoesNothing([System.Runtime.InteropServices.InAttribute()] [System.Runtime.InteropServices.MarshalAsAttribute(System.Runtime.InteropServices.UnmanagedType.I4)] int functionCode);

                    CallThroughDoesNothing(EWX_REBOOT | (bForceIfHung ? EWX_FORCEIFHUNG : 0) | (bForceRegardless ? EWX_FORCE : 0));

The icing on this cake is that you can have all your ducks in a row and still get this extremely annoying error message.
For example, suppose you have neglected to install the Visual C++ Redistributable Runtime Library.
Error messages used to be called "diagnostic messages."  No more.  They are called error messages because they tell you something, we know not what, went wrong.
It is up to you, the bottom-of-the-food-chain programmer, to sort it out.

Do you think at this late stage somebody will step up and do the right thing?  That would be:  IMPROVE THE QUALITY OF THE MESSAGE.  Tell me how to fix the problem.  This app isn't a web site.  So the answer is obvious. 

MARK D ROCKMAN

All replies (1)

_{Monday, December 29, 2014 7:00 AM ✅Answered}

32-bit process only loads 32-bit libraries, 64-bit process only loads 64-bit libraries. They don't mix. Period.

If 64-bit process need to use 32-bit libraries, they need to spawn new process and use IPC to animate it. Or in the case of .NET code, compile it as "target for x86 platform" so everything now runs as 32-bit.

Btw, I think the treatment of this error code is quite readily searchable.