I need to check if an executable programm compiled for 64 bit version or for 32 bit version on a Windows system.
-
possible duplicate of [How to know a process is 32-bit or 64-bit programmatically](http://stackoverflow.com/questions/1953377/how-to-know-a-process-is-32-bit-or-64-bit-programmatically) – Yuval Itzchakov Aug 11 '14 at 06:54
-
1What do you mean by "installed as 32-bit or 64-bit" for a service? You mean whether the executable that runs the service is 32 or 64 bit? – Mike Zboray Aug 11 '14 at 06:57
-
@TheodorosChatzigiannakis `AnyCPU` simply means it will compile down to 64 or 32 bit depending on the OS you're running on. There is no `AnyCPU` assembly code. – Yuval Itzchakov Aug 11 '14 at 07:03
-
@YuvalItzchakov Obviously. But the OP is asking whether the service is *installed* as 32-bit or 64-bit, not whether it's *running* as 32-bit or 64-bit. – Theodoros Chatzigiannakis Aug 11 '14 at 07:04
-
@TheodorosChatzigiannakis Right, i missed the *installed* part. – Yuval Itzchakov Aug 11 '14 at 07:05
-
I have to check if an executable a 64bit exe or a 32bit exe.(not only at runtime) – user3523585 Aug 11 '14 at 07:17
1 Answers
I think this question is hard to answer, because a .NET executable in Windows contains code in two forms:
The first part is a native stub that brings in the system's available runtime (for older Windows systems, when the OS loader didn't natively recognize CLR assemblies). It can be either 32-bit or 64-bit, like other Windows applications. You can find out its target architecture by analyzing its PE header.
As you can tell, this is rather straightforward to determine. However, I suspect it may also be largely irrelevant for your use case (and for most use cases), because this first part does't contain the "useful" part of your program and is there primarily for legacy reasons.
The second part is the IL (bytecode) that will get JIT-compiled and then executed. This is the useful part, but this is largely platform agnostic when not running. It's the runtime JIT-generated code that becomes 32-bit or 64-bit.
Now, if the assembly is explicitly built using the x86 or x64 configuration, it will be marked as such and you can find out programmatically without running it whether it's going to be 32-bit or 64-bit.
However, if it's marked as AnyCPU (like most assemblies are, these days) you can't know beforehand what to expect from the JIT-compiled code. You can only really find out at runtime (by asking the environment or by comparing the size of
IntPtr
for example). Or you can make an educated guess - if your current program is running under 32-bit Windows (but determining this from unmanaged code may be unreliable), you definitely don't have to expect that a .NET assembly would generate 64-bit CPU instructions. However, if you're running under 64-bit Windows (again, the most likely scenario), it won't be that easy, especially considering that the semantics of the AnyCPU configuration changed with .NET 4.5 and you'll have to account for those changes as well.
Now, here's the catch that you might already have realized: The first part and the second part may not match. And they often don't, because the most common scenario is building with the AnyCPU configuration (which will typically yield a 32-bit PE executable) and deploying on 64-bit systems, where the IL will be JIT-compiled to 64-bit instructions.
In the end, you'll have to decide specifically which of the two you want to know (and whether it's worth the trouble). You may also want to explore other options, like taking advantage of the fact that AnyCPU assemblies can load as either 32-bit or 64-bit and in many cases you can use them without checking.

- 1
- 1

- 28,773
- 8
- 68
- 104