Why doesn't the corflags utility warn when marking x64 assemblies as x86?

2
votes

If I set the platform flags of MyApp.exe to be x64 I still can run the corflags utilty like this:
corflags /32bit+ MyApp.exe
corflags will happily set the 32bit flag to 1. Of course when I'll try to run the application I'll get an error: 0xC000007B = STATUS_INVALID_IMAGE_FORMAT

My question is: Is there a way that an assembly which is built to x64 can run as x86 or it is just that corflags utility doesn't 'care'?

2
.netx8664-bitcorflags
I noticed that the user mdb edited this post and removed the x64 tag. Can anyone tell me why? (I would expect to find this kind of questions with x64 tag) – Ohad Horesh
This is definitely a x64 question. This should be tagged x64. – Jérôme Laban
Thanks Jerome. I don't want to start editing wars ala wikipedia. I wish there was a way to talk directly to the mdb – Ohad Horesh

2 Answers

2
votes

Compiling your binary by setting the "Platform Type" to x64 also changes the image PE header to make it 64 bits only. You can see this by using the Dependency Walker, for instance.

Having a 64Bits PE header does seem to take precedence over the 32 bits only corflags. The win32 bootstrapper for .NET seems to see that the PE header is not compatible with the current system (64 bits on a 32 bits system). That prevents the native image from loading, and incidentally also the .NET assembly part of the image.

I don't know any tool capable of updating the PE header this way, though. This does not seem to be just a matter of changing a flag to set the image to 32 bits. (See this blog post)

0
votes

Because if you don't load a native DLL, there's no reason that you couldn't remark it as 32-bit. If it's pure MSIL, the decision doesn't mean as much.