.NET Framework - is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)

Asked By Boris on 31-Aug-07 11:05 AM
I have a mixed DLL (a managed DLL in C++ calling functions in other
unmanaged DLLs) which I can build successfully in Visual Studio 2005 but
can't reference as I get then immediately the error:

is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)

Trying to find out what that actually means I read something that VS2005
will build a 32-bit or 64-bit DLL depending on what platform is used. As
I'm running a 32-bit Windows XP on a x64 CPU from AMD (with a target
platform "Win32" in VS2005) does it mean the DLL created is 64-bit? Or do
I have to look somewhere else to figure out what goes wrong here? By the
way, I had no problem to reference and load the DLL built in Visual Studio
2003. Building the code in VS2005 though causes a problem.

Boris




Ben Voigt [C++ MVP] replied on 31-Aug-07 03:58 PM
If you're running 32-bit Windows, it is necessary that all your modules be
32-bit (or AnyCPU for MSIL), and I doubt the compiler would give you
anything else, regardless of your CPU.

Only when moving from 32-bit to 64-bit OS, you can run into some problems
because AnyCPU modules change automatically because they see the 64-bit .NET
installed, and then your 32-bit native DLLs break.
Boris replied on 02-Sep-07 07:33 AM
On Fri, 31 Aug 2007 22:58:18 +0300, Ben Voigt [C++ MVP]


Thanks for your explanations! They don't seem to help me though to solve
my problem unfortunately. :) When I use a program like SnippetCompiler
(see http://www.sliver.com/dotnet/SnippetCompiler/) and try to reference
my successfully built .NET 2.0 DLL I see the error message. As it's a
rather generic error message - is there any FAQ or overview of what kind
of problems C++/CLI developers might run into and how to avoid them? I
think I'm basically looking for something like the Mixed DLL solution:
Most developers probably would have never found out what's wrong if
Microsoft didn't document it and provide help. If there is anything
available for the problem I ran into I'd appreciate any hints.

Boris
Ben Voigt [C++ MVP] replied on 04-Sep-07 12:19 PM
If you aren't running XP 64-bit, then you don't have .NET 64-bit and no
issues there.

Are you opening a mixed exe?  For pure MSIL assemblies, you can reference a
dll or exe.  For mixed assemblies, you can only reference a dll, the exe has
relocations disabled and some other optimizations that mean it MUST be the
main program.
Boris replied on 04-Sep-07 04:06 PM
On Tue, 04 Sep 2007 19:19:48 +0300, Ben Voigt [C++ MVP]


Yes, only a 32-bit XP here.


Yes, it's only a DLL. As I said the code was originally used to build a
DLL in VS2003 which worked fine. Meanwhile I tried to build the same code
(with Managed C++) in VS2005 and in another project with code converted to
C++/CLI - both doesn't work (or to be more precise: building works but not
referencing). As the error message doesn't contain any details I wonder if
there is anything else I can do except removing code, rebuilding the DLL
and checking if it can be referenced then. That would help at least to
find out which part of the code causes the problem?

Boris
Ben Voigt [C++ MVP] replied on 04-Sep-07 05:53 PM
Any chance you are trying to use a reference to a .NET 2.0 assembly from a
.NET 1.x application?  Check System::Environment::Version in your main
application.
Boris replied on 05-Sep-07 05:09 PM
On Wed, 05 Sep 2007 00:53:25 +0300, Ben Voigt [C++ MVP]


I run into the same problem with VS2005 when I create a new C# project
(eg. a Windows application), click on "Add Reference..." in the solution
explorer, select the .NET DLL in the file system, click on OK, add one
line of code to the project to instantiate a class from the .NET DLL,
build the project and run the executable. At first I see an error message
from the VS Just-In-Time Debugger: "An unhandled exception
(System.BadImageFormatException) occurred in Test.exe." I choose then a
debugger and see: "BadImageFormatException was unhandled - is not a valid
Win32 application. (Exception from HRESULT: 0x800700C1)"

The only new information is the reference to
System.BadImageFormatException - whatever that means. I'll check the
documentation but definitely appreciate any help, too!

Boris
Ben Voigt [C++ MVP] replied on 05-Sep-07 09:46 PM
Can you post the complete stack trace of the exception?  Turn on
first-chance exception debugging (Debug > Exceptions -> set that exception
type to "thrown") as well, you may get better traces.

The purpose of this is to look up the code in .NET Reflector and see under
what conditions the error is created... but Exception from HRESULT strongly
suggests nothing will be gained there.

Have you changed manifest options at all?  Perhaps selected static use of
runtime libraries (not compatible with .NET)?

Can .NET Reflector load the C++/CLI DLL?
Boris replied on 06-Sep-07 02:20 AM
On Thu, 06 Sep 2007 04:46:44 +0300, Ben Voigt [C++ MVP]


Unfortunately you are right: Throwing System.BadImageFormatException and
the Win32 exception 0x800700C1 didn't reveal any details.


All options in the C/C++ property page are set to default. In the linker
property page I had to add an additional dependency to an unmanaged
library from a third-party vendor (something I had to do for the VS2003
solution though, too). The Manifest Tool property page remained untouched.
Comparing the options with the VS2003 solution I see that I had added
additional dependencies to msvcrt(d).lib and mscoree.lib. If I'm not
mistaken they were required to fix the Mixed DLL problem in VS2003/.NET
1.1 and are not needed anymore for VS2005 solutions?


Yes, that works. I can also use the class browser in VS2005.

Thanks for your help so far,
Boris
Boris replied on 07-Sep-07 09:29 AM
I've been throwing everything away except one class which has only an
empty constructor. When I build the .NET DLL now there is basically no
code inside - but the problem remains.

Going once again through the project configuration I would guess that the
dependency on an unmanaged library causes the problem. Although the .NET
DLL currently does not call any functions in the unmanaged DLLs it depends
on I still have to add a dependency to the project configuration although
this library is only used by the unmanaged DLLs the .NET DLL depends on.
If I don't add the dependency I get "unresolved token" and "unresolved
extern symbol" errors. If I do the errors disappear and only a warning
get a DLL then but it seems to be faulty.

Although I don't know if I'm on the right track I wonder if there is
anything to take care of when a managed DLL depends on an unmanaged
library?

Boris
Boris replied on 09-Sep-07 10:50 AM
I found out what causes the problem (which doesn't mean though that I have
an idea how to solve it) and can now provide a reproducable test case. You
must have installed Boost 1.34.1 (see http://www.boost.org/) and add this
code to a C++/CLI project:


using namespace System;

namespace MyNamespace
{
public ref class MyClass
{
public:
MyClass() { }
};
}

Including the header boost/thread/mutex.hpp makes it impossible to load
the DLL (yes, including is enough - no need to use any code from that
header). I probably have to submit a bug report to Boost (or Microsoft?).

Boris
Ben Voigt [C++ MVP] replied on 10-Sep-07 09:52 AM
Try


around the #includes for boost headers