489

Is there an easy way to check if a binary is 32 or 64 bit on Windows? I need to check before I move the program to a 32bit machine and experience a spectacular failure.

fixer1234
  • 27,064
  • 61
  • 75
  • 116
Septagram
  • 5,348
  • 6
  • 20
  • 21
  • [This question is similar](http://reverseengineering.stackexchange.com/q/6040/8247), however it requires some work to check it. – ST3 Aug 08 '14 at 11:42
  • 4
    @Guillaume: Executable images are not processes. Task Manager only shows processes. – IInspectable Apr 12 '17 at 16:03
  • [How do I determine whether an application I am installing is 32bit or 64bit?](https://stackoverflow.com/q/1858358/995714) – phuclv Oct 20 '18 at 05:25
  • It's weird that right click on the file > Properties doesn't give this information – golimar Oct 28 '21 at 09:52

28 Answers28

581

After examining header values from Richard's answer, I came up with a solution which is fast, easy, and only requires a text editor. Even Windows' default notepad.exe would work.

  1. Open the executable in a text editor. You might have to drag-and-drop or use the editor's Open... dialog, because Windows doesn't show Open with... option in the context menu for executables.

  2. Check the first printable characters after the first occurrence of PE. This part is most likely to be surrounded by at least some whitespace (could be a lot of it), so it can be easily done visually.

Here is what you're going to find:

32-bit:

PE  L

64-bit:

PE  d†

A word of warning: using default Notepad on big files can be very slow, so better not use it for files larger than a megabyte or a few. In my case, it took about 30 seconds to display a 12 MiB file. Notepad++, however, was able to display a 120 MiB executable almost instantly.

This is solution might be useful in case you need to inspect a file on a machine you can't install any additional software on.

Additional info:

If you have a HEX-Editor available, the offset of PE Signature is located at offset 0x3C. The signature is PE\0\0 (letters "P" and "E" followed by two null bytes), followed by a two-byte Machine Type in Little Endian.

The relevant values are 0x8664 for a 64-bit executable and 0x014c for a 32-bit one (64 86 and 4c 01 respectively when adjusted for endianness, but any decent hex editor will automatically handle endianness when you search for a hex value). There are a lot more possible values, but you probably won't ever encounter any of these, or be able to run such executables on your Windows PC.

Full list of machine types, along with the rest of .exe specifications, can be found in Microsoft PE and COFF Specification Machine Types section.

Alexander Revo
  • 6,268
  • 2
  • 15
  • 16
  • 37
    Hey, this is rather hacky. And for the better, since this actually appears to be the fastest and easiest solution for the vast majority of cases :) – Septagram Mar 13 '15 at 21:51
  • 8
    Rare instance when notepad beat notepad++. Notepad shows this right, in notepad you have mess around with encoding to get it to show but it worked! – zar Dec 08 '15 at 20:01
  • @zadane that's interesting. In my experience, Notepad++ would always use ANSI encoding when opening executables.Though it definitely does make it somewhat more difficult to find the needed fragment by showing zero bytes as `NUL` instead of whitespace. – Alexander Revo Dec 09 '15 at 01:03
  • Here is Java code that does the check: http://stackoverflow.com/a/35418180/875305 – 11101101b Feb 15 '16 at 20:12
  • I found PE ]_ÙV in a 32 bit WPF application. – rleelr Mar 11 '16 at 11:50
  • @AnotherDayAnotherRob that's interesting. Technically, machine type is the two bytes after `PE\0\0`, so, assuming space in your comment is the two `\0` bytes the value would be `0x5F5D` (`5D 5F` if you open in HEX-editor due to endianness). There is nothing resembling that value in [Microsoft PE and COFF Specification](https://msdn.microsoft.com/en-us/windows/hardware/gg463119.aspx) (section 2.3.1. Machine Types). Are you sure you were looking in the right place? – Alexander Revo Mar 13 '16 at 09:07
  • @AlexanderRevo my bad, I had another look at the file and it's PE L ]_ÙV (whitespace is non printable chars) I didn't spot the L first time. Have an upvote. – rleelr Mar 14 '16 at 11:28
  • I have my own program compiled (with Delphi) as 32/64 bit and the header is identical !!! So, it this method is not working always! – Gabriel Jul 04 '16 at 10:48
  • @SolarWind there's no such thing as 32/64 bit executable on Windows. You're probably compiling it as 32-bit, which would work on both 32 and 64 bit systems. 64-bit Windows can run 32-bit programs just fine. – Alexander Revo Jul 04 '16 at 10:50
  • @AlexanderRevo: There is a compile option *AnyCPU* in Visual Studio. If this was the same as compiling for 32bit, why would they add this third option? – CodeManX Aug 01 '16 at 11:22
  • 3
    @CoDEmanX this option means the IDE or JIT makes the choice for you. See [this question](http://stackoverflow.com/q/516730/3811791) or this [blog post](http://blogs.microsoft.co.il/sasha/2012/04/04/what-anycpu-really-means-as-of-net-45-and-visual-studio-11/) for more details. – Alexander Revo Aug 01 '16 at 11:30
  • This is a fairly brittle solution. If you understand PE images, you should immediately see, that the first clear-text `PE` you find in a file may not actually be the PE header. Besides, without a documented contract, nothing of this is reliable, not today and certainly not for the future. Sorry, -1. – IInspectable Jan 20 '17 at 18:41
  • 3
    @IInspectable if you had actually bothered to read the whole post before downvoting it, you would have seen the link to `Microsoft PE and COFF Specification`, which is as much a documented contract as it can get, as well as instructions on how to find the exact address of PE header in any `.exe` file. If you have a more reliable source than Microsoft's official specification on Microsoft's own executable format, I would love to know what that is. – Alexander Revo Jan 21 '17 at 10:07
  • 1
    @AlexanderRevo: *"Check the first printable characters after the first occurrence of PE"* - That's blatantly wrong, no? The PE header can be **anywhere** in the file. And while the PE file format is documented, the `PIMAGE_DOS_HEADER` is not. Also, right on the first page of that so-called *"specification"* you'll find: *"This document is provided to aid in the development of tools and applications for Windows but **is not guaranteed to be a complete specification** in all respects. Microsoft reserves the right to alter this document without notice"*. The down-vote is well deserved, sorry. – IInspectable Jan 21 '17 at 19:51
  • 1
    Doesn't work for me on an exe created with C++ native code, visual studio 2013. Using this technique one can conclude it's 32bit, but in fact it's 64-bit, and can be verified by dumpbin and sigcheck – zumalifeguard Oct 12 '17 at 17:40
  • @zumalifeguard can I have a look at that exe? – Alexander Revo Oct 12 '17 at 17:45
  • Sure Alexander. Give me your e-mail address and I'll send it to you. if you can, you can DM me your e-mail address on Twitter. – zumalifeguard Oct 12 '17 at 20:55
  • @zumalifeguard I can't seem to contact you on Twitter, and I'm not really a fan of idea to giving my email to people on the Internet (no offence). Could you maybe upload it on some kind of file sharing service, like Google Drive, or something? Thanks. – Alexander Revo Oct 16 '17 at 18:13
  • @zumalifeguard Thanks for sending me the .exe. I checked it using my technique and it shows `PE d†`, which is 64-bit, which is exactly what my post says it is. I'm not sure why you thought that my posts suggests it's a 32-bit one. – Alexander Revo Oct 20 '17 at 11:19
  • 2
    First file I check, there's no "PE", only "MZ" so I guess this solution is not foolproof – NaturalBornCamper Nov 08 '17 at 17:21
  • 1
    @NaturalBornCamper try running an actual search with your editor. – Alexander Revo Nov 08 '17 at 17:38
  • Yeah I tried with Notepad++ ;) Found another way that works 100% anyways, so it's all good thanks! – NaturalBornCamper Nov 08 '17 at 19:37
  • @NaturalBornCamper I'd like to study that .exe so that I could make my answer more accurate, if you don't mind and have the time to upload it somewhere, of course. I do have to say, though, that I have yet to see a single .exe that my answer didn't work for (so far it was only people misinterpreting the results) so excuse me if I am a bit skeptical. Anyway, my goal is provide accurate information, so I'd appreciate it if you could help me get my hands on that .exe :) – Alexander Revo Nov 09 '17 at 13:58
  • 14
    For files that start with "MZ", you need to look a bit further. I found PE..L at offset 0x110, just after "RichMQ_........". – jnnnnn May 24 '18 at 04:20
  • Opened with XVI32 hex editor without any problems. Thanks – Hrvoje T Dec 28 '18 at 23:45
  • 2
    Thanks for the technique! It works for me, but note that this statement in your answer "the offset of PE Signature is located at offset 0x3C" is not always correct. Doxygen 32-bit EXE for example has PE header @ 0x108. In case anyone's interested this command will help apply this technique on linux: hexdump -C | grep 'PE' | head -n 5 (gives first 5 matches of 'PE' in the file) – codesniffer Nov 17 '19 at 00:52
  • @codesniffer you are correct, however it says in the answer that "the **offset** of PE signature is located at offset 0x3C", not the signature itself. – Alexander Revo Nov 17 '19 at 09:46
  • @codesniffer: Nice. If you're unlucky, `PE` might be at the end of a line, though, right? I used `strings -n1 | head`. – Eric Duminil Jun 26 '20 at 09:39
  • @AlexanderRevo: I don't understand your comment. I meant that `PE` might be at the end of line in `hexdump`. For what it's worth, the command above with `strings` worked fine, and output `MZP @ ! L ! This program must be run under Win32 $7 PE L `. – Eric Duminil Jun 26 '20 at 19:34
  • @EricDuminil ah, nvm, I misunderstood yours :P – Alexander Revo Jun 26 '20 at 19:35
  • 1
    @AlexanderRevo - Thanks for the clarrification that 0x3C specifies the offset to the PE Signature. @EricDuminil - Yes that's certainly possible. Could augment the command to additionally include the next line after each line with 'PE' from hexdump: `hexdump -C | grep -A 1 'PE' | head -n 15` (gives first 5 matches of 'PE' in the file, each followed by next 16 bytes) – codesniffer Jun 27 '20 at 21:44
  • Here's an enhanced version of the linux script to get the machine type using the specific offset from 0x3C: `QUERYFILE="MyWindowsExe.exe" ; hexdump -C -s $(hexdump -s 0x3C -n 4 -v -e '1/1 "%02x"' "$QUERYFILE" | sed -e 's/\(..\)\(..\)\(..\)\(..\)/0x\4\3\2\1/') -n 6 "$QUERYFILE"` and here's a sample output for a 64-bit file (doxygen.exe): `00000118 50 45 00 00 64 86 |PE..d.|` – codesniffer Jun 27 '20 at 22:26
  • And here's an even more enhanced version which parses the 32-bit & 64-bit type values and outputs "64-bit" or "32-bit" (or if neither is found then it outputs "ERROR: Failed to identify Windows PE machine type."): `QUERYFILE="MyWindowsExe.exe" ; PESIG=$(hexdump -C -s $(hexdump -s 0x3C -n 4 -v -e '1/1 "%02x"' "$QUERYFILE" | sed -e 's/\(..\)\(..\)\(..\)\(..\)/0x\4\3\2\1/') -n 6 "$QUERYFILE") ; echo "$PESIG" | grep ' 64 86' 2>/dev/null && echo "64-bit" || ( echo "$PESIG" | grep ' 4c 01' 2>/dev/null && echo "32-bit" || echo "ERROR: Failed to identify Windows PE machine type." )` – codesniffer Jun 27 '20 at 22:33
  • This method does not always work coorectly, C:\Windows\System32\Notepad.exe shows PE L but is actually 64 bit on Windows. – Shayan Nov 24 '20 at 06:21
  • 1
    @Shayan I have the correct 64-bit header in notepad.exe on my Windows 10 20H2. Make sure you're looking at the very first occurrence of PE in the file, if in doubt you can check with a hex-editor (see "Additional info"). – Alexander Revo Nov 24 '20 at 16:54
  • @AlexanderRevo Hello again! So, I'm on Windows 10 ver1803, idk why the very first PE for me is L. Please have a look at this screenshot: https://i.imgur.com/uar1KVs.png I loaded it in Notepad++. But as you mentioned, Hex Editor, shows PE��d†� which means 64 bit, so idk why Notepad++ doesn't work well here. Thanks a lot – Shayan Nov 24 '20 at 21:16
  • When I `type` & `fc /b` notepad.exe on Win 10, I get `MZÉ` & `4D 5A 90` headers: C:\WINDOWS\SYSTEM32\NOTEPAD.EXE – Zimba Mar 21 '21 at 03:29
  • I like this answer because notepad.exe is so super simple; I was able to find PE d etc... so I now know that I had a 64 bit binary. I compiled this via msys2 actually. I was surprised to see the .exe can be relocated. Perhaps it could even be used to compile a huge .exe containing ALL THE THINGS! :D – shevy May 03 '21 at 23:18
  • What about for ARM executables? – Aaron Franke Dec 08 '21 at 01:52
166

The SDK tool dumpbin.exe with the /headers option includes this information, compare these two (I've added bold for the key information)

PS [64] E:\ #4> dumpbin /headers C:\Windows\system32\cmd.exe
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file C:\Windows\system32\cmd.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
            8664 machine (x64)
               6 number of sections
        4CE798E5 time date stamp Sat Nov 20 09:46:13 2010
               0 file pointer to symbol table
               0 number of symbols
              F0 size of optional header
              22 characteristics
                   Executable
                   Application can handle large (>2GB) addresses
[...]

and

PS [64] E:\ #5> dumpbin /headers C:\Windows\syswow64\cmd.exe
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file C:\Windows\syswow64\cmd.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
             14C machine (x86)
               4 number of sections
        4CE78E2B time date stamp Sat Nov 20 09:00:27 2010
               0 file pointer to symbol table
               0 number of symbols
              E0 size of optional header
             102 characteristics
                   Executable
                   32 bit word machine
[...]
Richard
  • 8,952
  • 3
  • 26
  • 27
78

If you don't have or want the whole Windows SDK or Visual Studio, you can use sigcheck.exe from SysInternals:

sigcheck.exe C:\Windows\Notepad.exe

Output:

Sigcheck v2.1 - File version and signature viewer
Copyright (C) 2004-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

c:\windows\notepad.exe:
    Verified:       Signed
    Signing date:   8:59 AM 8/22/2013
    Publisher:      Microsoft Windows
    Description:    Notepad
    Product:        Microsoft« Windows« Operating System
    Prod version:   6.3.9600.16384
    File version:   6.3.9600.16384 (winblue_rtm.130821-1623)
    MachineType:    64-bit
chupasaurus
  • 103
  • 2
briantist
  • 1,063
  • 8
  • 10
  • 4
    Seems to be not always accurate: Try to use it with LinqPad.exe (AnyCPU-64bit version) and Sigcheck will tell you it's "32 bit" ... – Matt Oct 18 '17 at 13:55
  • @Matt interesting. LinqPad sounds like a .net app; I wonder if sigcheck only works correctly on native executables (for this purpose). – briantist Oct 18 '17 at 14:34
  • 3
    Yes, it is a .NET app. In .NET, if it isn't precompiled, you can either target "x86" or "AnyCPU". "x86" will always run as 32 bit, but AnyCPU will run as 64bit on a 64 bit system, but as 32 bit on a 32 bit system. SigCheck should consider this and show at least ".NET 32 bit or 64 bit (AnyCPU)". ILSpy for example says in this case "Architecture: AnyCPU (64-bit preferred)" - but ILSpy will not work for non-.NET EXE's. – Matt Oct 18 '17 at 14:42
  • @Matt that makes a lot of sense then; the native "stub" is probably 32 bit and then it initiates the 64 bit runtime where appropriate? Good find. – briantist Oct 18 '17 at 14:43
  • 1
    That might be the case, like the old "MZ" header which just is there for non-Windows ("DOS") OS saying "This application requires Microsoft Windows" ... ;-) – Matt Oct 18 '17 at 14:46
  • @Matt yesss it was actually a complete executable, and in visual studio you could set what you wanted it to be. You could literally support both DOS and Windows versions of the app in a single file, or the "DOS version" could do something completely different. I wrote an application for Windows, and then the DOS exe inside was its own menu system offering utilities to do things you had to do while Windows wasn't running (change start menu caption, etc.). – briantist Oct 18 '17 at 14:49
  • 2
    Yeah, the good old times, where you had a DOS debugger in the shell and could disassemble the code (which just contained one single DOS call printing this message)... and replace the text by "The answer is 42." :-D – Matt Oct 18 '17 at 14:52
  • Does this work for ARM executables? – Aaron Franke Dec 08 '21 at 01:53
  • @AaronFranke I'm afraid I don't know.. – briantist Dec 08 '21 at 02:21
  • This should be the first answer – Pouria P May 12 '22 at 08:21
70

I can confirm that the file utility (e.g. from cygwin) will distinguish between 32- and 64-bit executables. They appear as follows:

32.exe: PE32 executable (GUI) Intel 80386, for MS Windows
64.exe: PE32+ executable (console) x86-64, for MS Windows

As you can see, it's very obvious which is which. Additionally it distinguishes between console and GUI executables, also obvious which is which.

I say Reinstate Monica
  • 25,487
  • 19
  • 95
  • 131
wmassingham
  • 827
  • 6
  • 12
53

Many people have the excellent 7-zip installed, and have added the 7-Zip folder to their PATH. 7-zip understands file formats other than ZIP and RAR, such as MSI files and PE executables. Simply use the command line 7z.exe on the PE file (Exe or DLL) in question:

7z l some.exe | more
7z l some.exe | findstr CPU

Output will include lines as follows, with the CPU line reading either x86 or x64, which is what is being asked here:

Path = C:\Extra\AV\neroAacEnc.exe
Type = PE
CPU = x86
Characteristics = Executable 32-bit

Path = C:\Extra\AV\LAME\lame_enc.dll
Type = PE
CPU = x86
Characteristics = Executable DLL 32-bit

Path = C:\Extra\AV\FFmpeg\bin\ffmpeg.exe
Type = PE
CPU = x64
64-bit = +
Characteristics = Executable LargeAddress NoRelocs NoLineNums NoLocalSyms NoDebugInfo

Path = C:\Extra\AV\FFmpeg\bin\avcodec-56.dll
Type = PE
CPU = x64
64-bit = +
Characteristics = Executable DLL LargeAddress NoLineNums NoLocalSyms NoDebugInfo
Lumi
  • 1,563
  • 3
  • 14
  • 26
34

A simple method is to run it (assuming you trust it) and take a look at the process tab in task manager. 32bit processes will show "* 32" at the end of the process name. If it's not something your willing to run on your computer you can try EXE Explorer. It will show a whole bunch of info on executables including if it's 32 or 64bit.

Dracs
  • 2,704
  • 26
  • 27
  • 11
    Unfortunately, this requires you to run the executable. Perhaps you need to check the architecture of the program as a troubleshooting method on why it is not running. – Mike Christiansen Oct 02 '12 at 16:20
  • 11
    How do **you** run a DLL? – Sam Hobbs Nov 03 '16 at 19:57
  • 1
    @user34660 [RUNDLL32.EXE ,](https://stackoverflow.com/a/3044435/1105214) – samus Dec 14 '17 at 18:53
  • 1
    @samusarin that should be in the post. – Sam Hobbs Dec 15 '17 at 01:22
  • @user34660 You're technically correct, a DLL doesn't have a **`main`** entry point and so will not execute as a stand alone process. There is an initialization function called when it is loaded but that isn't "main". – samus Dec 18 '17 at 19:21
  • 1
    You can also see if a program is 64bit or 32 bit on Task Manager's Details tab, just have to enable the "Platorm" column by right clicking on one of the columns and click Select Columns – Shayan Nov 24 '20 at 06:23
25

Here's a Powershell solution, no external dependencies or anything. Open Powershell, paste the function in there (hit Enter twice so that you return to the prompt), then use it as in my examples below the function:

function Test-is64Bit {
    param($FilePath=“$env:windir\notepad.exe”)

    [int32]$MACHINE_OFFSET = 4
    [int32]$PE_POINTER_OFFSET = 60

    [byte[]]$data = New-Object -TypeName System.Byte[] -ArgumentList 4096
    $stream = New-Object -TypeName System.IO.FileStream -ArgumentList ($FilePath, 'Open', 'Read')
    $stream.Read($data, 0, 4096) | Out-Null

    [int32]$PE_HEADER_ADDR = [System.BitConverter]::ToInt32($data, $PE_POINTER_OFFSET)
    [int32]$machineUint = [System.BitConverter]::ToUInt16($data, $PE_HEADER_ADDR + $MACHINE_OFFSET)
    $stream.Close()

    $result = "" | select FilePath, FileType, Is64Bit
    $result.FilePath = $FilePath
    $result.Is64Bit = $false

    switch ($machineUint) 
    {
        0      { $result.FileType = 'Native' }
        0x014c { $result.FileType = 'x86' }
        0x0200 { $result.FileType = 'Itanium' }
        0x8664 { $result.FileType = 'x64'; $result.is64Bit = $true; }
    }

    $result
}

Here's example output:

D:\> Test-is64bit

FilePath               FileType Is64Bit
--------               -------- -------
C:\Windows\notepad.exe x64         True


D:\> Test-is64bit 'C:\Program Files (x86)\Mozilla Firefox\firefox.exe'

FilePath                                           FileType Is64Bit
--------                                           -------- -------
C:\Program Files (x86)\Mozilla Firefox\firefox.exe x86        False
Persistent13
  • 113
  • 5
megamorf
  • 2,363
  • 15
  • 21
  • Slickness. The above script seems to leave a reference to the file open. Couldn't build until I first closed powershell (ran script to interrogate DLL in \bin). – samus Oct 20 '16 at 13:27
  • 1
    Very cool. +1. Itanium is definitely 64bit though :) – Rich Homolka Jul 13 '17 at 21:24
  • @samusarin: maybe add `$stream.dispose();` after the close? Should release file handles. ( https://stackoverflow.com/questions/1999858/how-bad-is-it-to-not-dispose-in-powershell ) – Yorik Dec 13 '17 at 22:41
  • 3
    a more complete version can be found in [Check if exe is 64-bit](https://reverseengineering.stackexchange.com/a/11373/2563) – phuclv Oct 16 '18 at 16:02
  • +1 Exactly what I was scrolling down looking for. No need to link to an sdk or put rando binaries in my repo to run these checks during CI – user1169420 Jun 16 '21 at 21:46
  • if you're curious about the `$result = "" | select FilePath, FileType, Is64Bit` section, that's how you could create objects before WinPs 4 and `[pscustomobject]` -- meaning it's from before 2012 – monkey Aug 20 '22 at 01:32
23

The 64-bit version of Process Explorer can tell you. Simply run the executable and open the process's properties window. On the main tab there's an entry which says "Image:32 Bit" or "Image:64 Bit".

enter image description here

Andrew Lambert
  • 7,635
  • 3
  • 30
  • 47
22

Most simple way (when the data aren't confidential)

I find that Virustotal File detail is the simplest way to find out if a binary is 32 bit or 64 bit.

The Additional information option provides in addition much helpful informations about the file.

Virustotal analysis


[Virustotal TrID

marsh-wiggle
  • 2,914
  • 6
  • 28
  • 42
16

The method of running an executable & then checking in process explorer or similar tool, has some obvious drawbacks:

  1. We have to execute the process.
  2. For the short lived processes (like echo hello world types.), process explorer might not even register that a new process has started.

Dumpbin.exe method can solve the purpose probably.

Another alternative would be to use cygwin's file command. However, I have not tested it on windows. It works well on Linuxes.

Usage: file program_under_test.exe

EDIT: Just tested file.exe on window. works fine. :)

anishsane
  • 905
  • 1
  • 8
  • 18
  • This adds nothing that wasn't said by Dracs or Richard. This still requires running the program which the author wanted to avoid. – Ramhound Oct 19 '12 at 10:45
  • 1
    Just wanted to say, that there are some situations, where Dracs's method will not be much helpful. – anishsane Oct 19 '12 at 10:49
  • 3
    >>This still requires running the program which the author wanted to avoid: No.. we run it like: file.exe program_under_test.exe – anishsane Oct 19 '12 at 10:49
  • 1
    And those who wish to avoid installing the whole `cygwin` package can grab the [gnuwin32 `file` package](http://gnuwin32.sourceforge.net/packages/file.htm). – Bob Oct 19 '12 at 11:32
  • I just ran the cygwin "file" command and it says nothing about 32 versus 64 bits: `MS-DOS executable PE for MS Windows (console), Mono/.Net assembly` – MarcH Sep 04 '13 at 12:14
  • Looks like your 'file' binary itself is 32 bit. Hence it will not be able to detect 32 vs 64 bit. You need 64 bit version of file utility. Check here: http://cygwin.com/ml/cygwin-announce/2013-07/msg00030.html – anishsane Sep 04 '13 at 12:25
  • 7
    @anishsane Completely wrong. `file` simply reads data from the disk in binary format and checks for any magic numbers identifying them, comparing against a database. Windows' 32-bit programs come up as PE32, and both 64-bit and .NET programs come up as PE32+. The bitness of `file` itself makes absolutely zero difference - both 32-bit and 64-bit applications can read data from the disk, which is all it needs. – Bob Jan 17 '14 at 02:24
  • @MarcH No, it told you it's a .NET assembly, which doesn't have bit-ness. It's neither win32 nor win64, it's .NET. – clacke Dec 11 '14 at 13:55
  • @clacke interesting thanks. Now here is something even more interesting: /cygdrive/c/Program Files/Syncplicity/Syncplicity.exe: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows This one runs without any *32 in task manager. – MarcH Dec 14 '14 at 18:02
  • ... and sigcheck.exe reports Syncplicity.exe as 32 bits. – MarcH Dec 14 '14 at 18:09
  • 1
    @MarcH Ha! That *is* interesting. I'm guessing that means the .NET runtime stub is 32-bit. So it runs a 32-bit process for a fraction of a second, but all that process does is start the .NET runtime, which creates a native 64-bit process. – clacke Dec 16 '14 at 15:15
  • Makes me think that PE32+ .NET files make no sense, they should all be PE32 to make sure they run on both platforms. But maybe the stub code never runs -- it's possible that Windows discovers that it's a .NET binary and just runs .NET directly. Would be great to hear a comment from someone who actually knows. :-) – clacke Dec 16 '14 at 15:17
  • 1
    It seems that Windows 2000 ran the stub to initiate the .NET runtime, but XP and later detects a .NET binary and runs .NET itself. It doesn't create a new process though, it starts .NET in the existing process and if it's a PE32 on a 64-bit system, it converts it in-memory to PE32+ before proceeding. https://social.microsoft.com/Forums/ru-RU/14d2158d-9df7-448b-a2ac-adfcac2be6cb/how-does-the-clr-get-loaded – clacke Dec 16 '14 at 15:28
11

My two cents will be just download dependency walker and check what for architecture has been used in one of the executable file.

How to use it:

Just simply download app, start it up, click on open icon → find an *.exe file → select and on the bottom after reflection scan is done you see a grid with data where one column has "architecture" details in it (x86, x64)

Open executable and see the build architecture

dependency walker screenshot

st35ly
  • 211
  • 2
  • 5
11

Even an executable marked as 32-bit can run as 64-bit if, for example, it's a .NET executable that can run as 32- or 64-bit. For more information see https://stackoverflow.com/questions/3782191/how-do-i-determine-if-a-net-application-is-32-or-64-bit, which has an answer that says that the CORFLAGS utility can be used to determine how a .NET application will run.

CORFLAGS.EXE output

For 32-bit executable:

Version   : v2.0.50727
CLR Header: 2.5
PE        : PE32
CorFlags  : 0x3
ILONLY    : 1
32BITREQ  : 1
32BITPREF : 0
Signed    : 0

For 64-bit executable:

Version   : v2.0.50727
CLR Header: 2.5
PE        : PE32+
CorFlags  : 0x1
ILONLY    : 1
32BITREQ  : 0
32BITPREF : 0
Signed    : 0

For executable that can run as 32- or 64-bit and will run as 64-bit when possible:

Version   : v2.0.50727
CLR Header: 2.5
PE        : PE32
CorFlags  : 0x1
ILONLY    : 1
32BITREQ  : 0
32BITPREF : 0
Signed    : 0

For executable that can run as 32- or 64-bit, but will run as 32-bit unless loaded into a 64-bit process:

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32
CorFlags  : 0x20003
ILONLY    : 1
32BITREQ  : 0
32BITPREF : 1
Signed    : 0
BlueMonkMN
  • 467
  • 1
  • 7
  • 17
  • Cool command, but it won't work for native (non-managed) executables / dlls. (`corflags : error CF008 : The specified file does not have a valid managed header`) – Tomasz Gandor Sep 15 '16 at 08:08
  • 1
    @TomaszGandor Yes, the context of this answer was managed code only. Unmanaged code is answered by the other answers. As far as I know, only managed code can switch between executing as both 32- and 64-bit. – BlueMonkMN Aug 25 '18 at 14:24
  • I personally would use other solutions, but summarizing that matter and showing all possible cases deserved an upvote. – Binarus Jan 28 '21 at 22:11
10

If you are on Windows 7, on a Windows Explorer, right click on the executable and select Properties. At the properties window select the Compatibility tab. If under the Compatibility Mode section you see Windows XP, this is a 32 bit executable. If you see Windows Vista, it is 64 bit.

axxis
  • 229
  • 2
  • 6
  • -1 not true at all. Various 32 and 64 bit binaries are all shown an Compatibility Mode of `Windows 8` – Peter Hahndorf Jun 16 '15 at 12:14
  • @Peter I've tried quite a few on Windows 7 and it always worked for me. Could you give an example of a binary where the default compatibility mode is Windows 8? Also what Windows are you on? Thanks. – axxis Jun 16 '15 at 18:46
  • I'm on Server 2012 R2 and tried a few random binaries. Some 32bit ones show as `Windows XP SP2` but others show as `Vista` or `Windows 8`. So this method is not correct. – Peter Hahndorf Jun 18 '15 at 03:27
  • 2
    @PeterHahndorf their language is a bit off but what he meant is when you open up the compatibility drop-down, if XP is an option at all it is 32bit. Otherwise if the only options you have are Vista-onwards, it's x64 – Hashbrown Oct 14 '19 at 04:27
  • Nice trick! As stated above, open the drop-down to see all the options. If xp is there at all = 32bit – Danny Parker Jun 18 '21 at 13:02
8

How to add 32/64 bit test to your context menu

Create a text file named exetest.reg and containing this code:

Windows Registry Editor Version 5.00

; What will appear in the contextual menu when right-clicking on a .exe file
[HKEY_CLASSES_ROOT\exefile\shell\command32_64]
@="32/64 bit test"

; What to do with it
; here, %1 is the file given as argument of the script
[HKEY_CLASSES_ROOT\exefile\shell\command32_64\command]
@="\"c:\\temp\\x86TestStart.bat\" \"%1\""

Create a text file named x86TestStart.bat containing just this line of code and save it in C:\temp:

c:\temp\x86or64.vbs %1

Create a text file named x86or64.vbs containing this code and save it in C:\temp:

rem Reading binary file in VBScript: http://stackoverflow.com/questions/21249440/modify-first-two-bytes-of-a-file-using-vbscript
rem Info on executables: https://dmoj.ca/problem/exe

rem x86/64 signature is located dinamycally; its position is addressed
rem from bytes in 0x3C-0x3D position.

rem Possible signatures;
rem "PE..L" (hex code: 50.45.00.00.4C) = 32 bit
rem "PE..d†" (hex code: 50.45.00.00.64.86) = 64 bit

' ------------------------------------
' Source code by Jumpkack 2015
' ------------------------------------

' Read all arguments from command line:
Set args = Wscript.Arguments

' Store first argument (full path to file)
FileName = args(0)

' Find address of executable signature:
FirstChars = readBinary(FileName)
FirstChars = FirstChars
Addr1 = asc(mid(FirstChars,61,1))
Addr2 = asc(mid(FirstChars,62,1))
AddrFinal = Addr2*256 + Addr1 + 1

' Check signature:
if ucase(hex(asc(mid(FirstChars,AddrFinal+4,2)))) = "4C" then Wscript.Echo Filename & " is a 32 bit executable."
if ucase(hex(asc(mid(FirstChars,AddrFinal+4,2)))) = "64" then Wscript.Echo Filename & " is a 64 bit executable."


Function readBinary(path)
    Dim a, fso, file, i, ts
    Set fso = CreateObject("Scripting.FileSystemObject")
    Set file = fso.getFile(path)
    If isNull(file) Then
        wscript.echo "File not found: " & path
        Exit Function
    End If
    Set ts = file.OpenAsTextStream()
    'a = makeArray(file.size)
    a=""
    i = 0
    While (Not ts.atEndOfStream) and (i<60000)
       'a(i) = ts.read(1)
       a = a + ts.read(1)
       i = i + 1
    Wend
    ts.close
    readBinary = a
 End Function

Double click on exetest.reg file: a new key will be added in the windows registry:

[HKEY_CLASSES_ROOT\exefile\shell\command32_64\command]

It will appear as "32/64 bit test" in context menu upon right clicking on an executable file.

Clicking the item will result in starting batch file c:\\temp\\x86TestStart.bat\, which starts VBscript file x86or64.vbs , which reads exe signature and shows result.

If you cannot or don't want to tamper with registry, just copy the .vbs file in QuickLaunch bar, and drag executable over it.

jumpjack
  • 405
  • 5
  • 9
  • I find this solution to take too much effort, and I therefore won't use it. However, putting it together really deserved my upvote. Well done ... – Binarus Jan 28 '21 at 22:10
  • The line `FirstChars = FirstChars` is pointless and can be deleted. Not sure if that was meant to be something different? – Frank Lesniak Jan 29 '21 at 07:24
  • 2
    I wanted to thank you for posting this answer. It inspired me to write a more-generic function that I posted to [my GitHub repo](https://github.com/franklesniak/VBScript_Resources) in a file called `GetExecutableProcessorArchitectureFromFile.vbs`. It reads an exe's PE header, gets the machine type, and returns the processor architecture (i.e., if the executable was running and accessed the PROCESSOR_ARCHITECTURE environment variable, the contents of that variable), in string format. – Frank Lesniak Jan 31 '21 at 06:43
7

Yet, WSL's file command works greatly.

file /mnt/c/p/bin/rg.exe would output:

/mnt/c/p/bin/rg.exe: PE32+ executable (console) x86-64, for MS Windows

file /mnt/c/p/bin/u.exe would output:

/mnt/c/p/bin/u.exe: PE32 executable (GUI) Intel 80386, for MS Windows, UPX compressed
phuclv
  • 26,555
  • 15
  • 113
  • 235
Bohr
  • 534
  • 5
  • 10
6

The platform column in the task manager of windows 10

Windows 7 doesn't have a platform column. So Windows 7 task manager won't show it.

In windows 10 choosing columns is not under 'view' anymore. In Windows 10, when in the details tab, you right click column header then 'select columns'. Then check the box for 'platform'.

enter image description here

enter image description here

barlop
  • 23,380
  • 43
  • 145
  • 225
  • 1
    This requires running the application, which might be undesirable. Also, you "cannot" run a DLL. – Andreas Rejbrand Nov 12 '19 at 09:26
  • 1
    @AndreasRejbrand fair point in a sense, though he didn't mention a dll, he just said application.. also, and the DLL will match the EXE in 'bitness' – barlop Nov 12 '19 at 19:42
6

you can also use the file tool from within the msys2 bundle of mingw-w64. It works like the unix command. Similar works the file tool from GNUwin32.

li ki
  • 150
  • 6
Bastian Ebeling
  • 261
  • 1
  • 5
  • 14
4

The Simplest Solution is that the 32-bit version has windows XP listed on the compatibility tab of the properties ( tested on Windows 7 & 10 ) of the executable file.

Firefox 32 Bit:

enter image description here

Firefox 64 Bit:

enter image description here

Mostafa
  • 171
  • 4
3

I haven't seen this mentioned. There is a PE viewer program called CFF Explorer by NTCore, which can provide you this information. It can be downloaded and run as portable, but you can install it as well, if you wish.

Right click on the binary (.exe, .dll etc.) and select "Open with CFF Explorer". Go to Nt Headers -> File Header -> On the "Characteristics" field click "Click here"

If it's a 32bit program, the checkbox "32 bit word machine" will be ticked. For instance, i have installed the 32bit version of Notepad++ as you can see in the image below. Otherwise, it's 64bit.

enter image description here

KeyC0de
  • 219
  • 1
  • 7
  • 19
  • There is a quicker way with CFF explorer: immediately when loading a file, under "file type" you have "Portable Executable 64" or "Portable Executable 32" – Arthur.V Sep 05 '19 at 11:25
2

my two cents: as a C++ developer, dependency walker (http://www.dependencywalker.com/) is very informative, not only displays 64/32 bits, but also every Dll involved: enter image description here

You can see 64 on left of every file name...

TomEus
  • 3,657
  • 18
  • 35
ingconti
  • 119
  • 2
2

My simple version in Powershell, seems to be 100% reliable from my tests.

Clear-Host
$Check32Bit = $null
$Check64Bit = $null

$File = "C:\WINDOWS\system32\notepad.exe"

$ExeData = get-content $File -totalcount 50

$Check32Bit = $ExeData | select-string -Pattern "PE..L" -Quiet
$Check64Bit = $ExeData | select-string -Pattern "PE..d†" -Quiet

if ($Check32Bit) {
"File is 32bit (x86)"
}
elseif ($Check64Bit) {
"File is 64bit (x64)"
}
else {
"Couldn't identify if the file is 32bit or 64bit"
}
Rakha
  • 121
  • 3
2

As pointed out in a comment by @user1055604, the easiest out-of-the-box way of doing this on Windows 10 is:

dumpbin /headers yourfile.lib | findstr "machine"

This one-liner will produce an intuitive result as an output. For example, on a 64-bit library I just tested, it printed the following:

8664 machine (x64)

Hackstaar
  • 131
  • 4
  • Dumpbin is not part of a default Windows install. It comes with the Common Tools for Visual C++. See https://stackoverflow.com/a/38616596/102351 – Scorpion Dec 07 '22 at 07:13
2

Many excellent answers already, some claiming "most simple", but the absolute simplest way is inspecting the folder path.

C:\Program Files (x86)\ has only 32-bit stuff

Roland
  • 387
  • 2
  • 14
1

You can use corflags from VS command prompt to change machine type

https://docs.microsoft.com/en-us/dotnet/framework/tools/corflags-exe-corflags-conversion-tool

Change Machine Type:

corflags d:\abc.exe /32BITREQ- 

Verify using corflags:

corflags d:\abc.exe 

32BITREQ : 0 ** 0 means 64 bit

phuclv
  • 26,555
  • 15
  • 113
  • 235
tomcat
  • 111
  • 3
1

I know they are many answers here, but none of them are really portable and require some kind of tool to use. I wanted to solve this in a programmatic way for all platforms. This will work on anything with a C compiler.

#include <stdio.h>
#include <fstream>      // std::fstream
#include <stdio.h>
#include <string.h>


char Header      [0x200];
char Elf32Magic  [20] = "\x7f\x45\x4c\x46\01";  //7F 45 4C 46  01 // ELF32 
char Elf64Magic  [20] = "\x7f\x45\x4c\x46\02";  //7F 45 4C 46  02 // ELF64
char Win32Magic  [20] = "\x50\x45\x00\x00\x4C\x01";// PE32
char Win64Magic  [20] = "\x50\x45\x00\x00\x64\x86";// PE64

char PeHeader[20] = {};
void CheckWinHeader(){
  int k = 0;
  for (int i = 0; i < 0x200; i++)
  {
   if(Header[i] == 0x50 && Header[i+1] == 0x45) // PE     
     {

      for(int j = i; j < i + 6; j++)
      {
        PeHeader[k] = Header[j];
        k++;
       //printf("%hhx", Header[j]); 
      }
     }
  }
}


int main(){
  std::fstream fs; 
  fs.open ("/home/PATH/TO/YOUR/BINARY", std::fstream::in | std::fstream::out | std::fstream::app);
  fs.read( Header , 0x200);
 
  if(memcmp ( Header, Elf32Magic, 5 ) == 0 ){
    printf("ELF 32 Match Found ! \n");
  }
  if(memcmp ( Header, Elf64Magic, 5 ) == 0 ){
    printf("Elf 64 Match Found ! \n");
  }

  CheckWinHeader();

  if(memcmp ( &PeHeader, Win32Magic, 6 ) == 0 ){
    printf("Win 32 Match Found ! \n");
  }

  if(memcmp ( &PeHeader, Win64Magic, 6 ) == 0 ){
    printf("Win 64 Match Found ! \n");
  }

 fs.close();
 return 0;
}

compile by using any compiler. I used g++.

g++ Bincheck.cpp -o bincheck
./bincheck
phuclv
  • 26,555
  • 15
  • 113
  • 235
LUser
  • 159
  • 3
  • There's no C compiler by default in Windows so this isn't quite useful. If you have gcc then you'll have `file` command and if you have MSVC there's `dumpbin` available so there's no need to compiler such a program. OTOH there's notepad and powershell on Windows so you can check the binary type using either way easily without any 3rd party tools – phuclv Aug 11 '20 at 14:05
1

If you want to scan a folder structure for 32/64 bit DLL's or executables, you can also try a free tool called ScanFor64bit, found at: https://canservices.nl/download-tools ScanFor64bit allows you to enter a drive-letter or directory-path and one or more filemasks to scan for 32 or 64 bitness. The result is a list sorted by 32bit files first and 64bit second. I have used it a lot to check computers with Java to make sure the 64 bit version is used.

Output example of ScanFor64bit:

1

Something different from all the excellent answers above, but use PowerShell to search for the telltale "This program must be run under Win32"?

PS C:\Program Files\Snap Inc> ls -R . -filter *.exe | % { $file = $_; Select-String -Path $_ -Encoding 'oem' -Pattern 'under Win32' -SimpleMatch -Quiet } | % { Write-Output "$file is Win32: $_" }

Snap Camera.exe is Win32: False
unins000.exe is Win32: True
installer.exe is Win32: False

This also matches the results for the PE L and PE d† trick.

Drakes
  • 387
  • 1
  • 3
  • 15
1
  • run the application
  • open Task Manager
  • right click and create dump file
  • note down path
  • go to path and open .DMP dump in Visual Studio
  • there you get all the details
  • check process architecture:
user429538
  • 19
  • 1
  • 4
    I feel obligated to underscore the fact that this answer requires running the application. Previous commenters suggested that this might be undesirable. Also, Visual Studio will not automatically be available on all Windows platforms. – G-Man Says 'Reinstate Monica' Mar 19 '15 at 13:46