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

  • Thread starter Thread starter Boris
  • Start date Start date
B

Boris

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
 
Boris said:
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
Click to expand...

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.
 
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.
Click to expand...

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
 
Boris said:
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.
Click to expand...

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.
 
[...]If you aren't running XP 64-bit, then you don't have .NET 64-bit
and no
issues there.
Click to expand...

Yes, only a 32-bit XP here.
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.
Click to expand...

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
 
Boris said:
[...]If you aren't running XP 64-bit, then you don't have .NET 64-bit
and no
issues there.
Click to expand...

Yes, only a 32-bit XP here.
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.
Click to expand...

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?
Click to expand...

Any chance you're 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.
 
[...]Any chance you're 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.
Click to expand...

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
 
Boris said:
[...]Any chance you're 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.
Click to expand...

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!
Click to expand...

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?
 
[...]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.
Click to expand...

Unfortunately you are right: Throwing System.BadImageFormatException and
the Win32 exception 0x800700C1 didn't reveal any details.
Have you changed manifest options at all? Perhaps selected static use of
runtime libraries (not compatible with .NET)?
Click to expand...

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?
Can .NET Reflector load the C++/CLI DLL?
Click to expand...

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

Thanks for your help so far,
Boris
 
[...]
Click to expand...

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
"unresolved typeref token ...; image may not run" remains. That said I do
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
 
[...]
Click to expand...

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:

#pragma once
#include <boost/thread/mutex.hpp>

#using <mscorlib.dll>
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
 
Boris said:
[...]
Click to expand...

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:

#pragma once
#include <boost/thread/mutex.hpp>

#using <mscorlib.dll>
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?).
Click to expand...

Try

#pragma managed(push, off)
#pragma managed(pop)

around the #includes for boost headers
 
Back
Top