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.

  • This question is similar, however it requires some work to check it. – ST3 Aug 8 '14 at 11:42
  • 2
    @Guillaume: Executable images are not processes. Task Manager only shows processes. – IInspectable Apr 12 '17 at 16:03

19 Answers 19

up vote 269 down vote accepted

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 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 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:




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 few. In my case in 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 x64 executable and 0x14c for x86. 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.

  • 16
    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
  • 4
    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 8 '15 at 20:01
  • 2
    @CoDEmanX this option means the IDE or JIT makes the choice for you. See this question or this blog post for more details. – Alexander Revo Aug 1 '16 at 11:30
  • 2
    @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
  • 3
    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 at 4:20

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


            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
                   Application can handle large (>2GB) addresses


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


             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
                   32 bit word machine
  • 1
    You could also see (IA64) for a 64bit Itanium exe. – Darryl Braaten Nov 17 '11 at 17:01
  • 17
    as i read elsewhere on superuser, using dumpbin /headers | findstr "machine" greatly simplifies the presentation of what the QA is looking for... – user1055604 Mar 17 '13 at 14:10
  • 3
    Dumpbin.exe is located here: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin – Devid Jul 30 '14 at 11:12
  • 3
    @David: not necessarily (different version of VS, not using the default install location, using version from the Windows SDK): that is why I didn't specify. – Richard Jul 30 '14 at 11:17
  • 5
    It's easiest to use dumpbin if you launch it from the visual studio command-line: – Ben Apr 27 '15 at 22:51

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


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

    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
  • 3
    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
  • 1
    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
  • 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
  • 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

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.

  • 1
    This solution is pretty commonly available for any developers who have installed msysgit. – FrontierPsycho Feb 6 '17 at 15:59
  • Why executable files in windows have MZ instead of PE? – Mohammadreza Panahi May 15 at 13:44

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.

  • 7
    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 2 '12 at 16:20
  • 6
    How do you run a DLL? – user34660 Nov 3 '16 at 19:57
  • 1
    @user34660 RUNDLL32.EXE <dllname>,<entrypoint> – samsara Dec 14 '17 at 18:53
  • 1
    @samusarin that should be in the post. – user34660 Dec 15 '17 at 1: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". – samsara Dec 18 '17 at 19:21

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

  • 23
    Simply run the executable And what if you don’t want to run the program? – Synetech Feb 6 '14 at 9:23
  • 2
    @Synetech The original question doesn't imply that's the case. – Andrew Lambert Feb 6 '14 at 18:13
  • This is the easiest method for me I think, unless the executable exits too fast. – starbeamrainbowlabs Jan 27 '15 at 11:00
  • 7
    How do you run a DLL? – user34660 Nov 3 '16 at 19:58

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

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. :)

  • 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. – Bob Oct 19 '12 at 11:32
  • 6
    @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 2:24
  • 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

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

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 {

    [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)

    $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; }


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
  • 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). – samsara 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. (… ) – Yorik Dec 13 '17 at 22:41

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, which has an answer that says that the CORFLAGS utility can be used to determine how a .NET application will run.


For 32-bit executable:

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

For 64-bit executable:

Version   : v2.0.50727
CLR Header: 2.5
PE        : PE32+
CorFlags  : 0x1
ILONLY    : 1
32BITREQ  : 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
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
Signed    : 0
  • 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 8:08

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

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.

  • -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 3:27

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
@="32/64 bit test"

; What to do with it
; here, %1 is the file given as argument of the script
@="\"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:
rem Info on executables:

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: = 32 bit
rem "PE..d†" (hex code: = 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)
    i = 0
    While (Not ts.atEndOfStream) and (i<60000)
       'a(i) =
       a = a +
       i = i + 1
    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.

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 a *.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

  • 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:
  • 3
    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 Mar 19 '15 at 13:46

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

my two cents: as a C++ developer, dependency walker ( 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...

  • Screenshot does not display the answer - 32bit vs 64bit info... – TomEus Sep 28 '17 at 7:51

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.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.