Как отличить 32-битный EXE от 64-битного: все рабочие способы

Разрядность исполняемого файла чаще всего нужна, когда программа не запускается, отказывается подключать библиотеку или её нужно развернуть на сервере с конкретной архитектурой. Быстрый ориентир: если файл лежит в папке Program Files (x86), он почти наверняка 32-битный, а в Program Files — 64-битный. Но это работает только для установленных программ, а скачанный или перенесённый EXE так не проверишь. Ниже — способы, которые дают точный ответ в любой ситуации, от простых до самых надёжных.

Зачем вообще знать разрядность файла

32-битный EXE запускается и на 32-битной, и на 64-битной Windows (во втором случае через подсистему WOW64). А вот 64-битный EXE на 32-битной системе не запустится вовсе: система сообщит об ошибке вроде «не является приложением Win32» или просто не даст выполнить файл. Отсюда типичные сценарии, когда проверка нужна:

• программа не запускается, и нужно понять, в совместимости ли дело;
• выбираете версию драйвера, DLL или плагина под своё приложение — разрядности должны совпадать;
• разворачиваете ПО на сервере или в контейнере с известной архитектурой;
• анализируете незнакомый файл и хотите понять, под какую платформу он собран.

Важно не путать разрядность файла с разрядностью системы. 64-битная Windows спокойно работает с 32-битными программами, поэтому «файл не запускается на мощном компьютере» — частый повод проверить именно EXE.

Способ 1: свойства файла в проводнике

Самый быстрый вариант, который работает без дополнительных программ. Щёлкните по EXE правой кнопкой мыши, откройте «Свойства» и перейдите на вкладку «Совместимость» (в Windows 10 и новее — «Совместимость» → «Изменить параметры высокой точности DPI» не нужен, смотрим именно вкладку). В некоторых сборках Windows на вкладке «Подробно» или в описании файла указана разрядность, но это зависит от того, как её заполнил разработчик.

Более надёжный путь через проводник: откройте «Свойства» → вкладка «Подробно» и посмотрите поле «Тип файла». Если там написано «Приложение (32-разрядное)» — ответ получен. В Windows 11 это поле отображается чаще, чем в Windows 10, но гарантий нет: если разработчик не заполнил метаданные, поле покажет просто «Приложение».

Поэтому этот способ стоит рассматривать как первую быструю проверку: если ответ есть — хорошо, если нет — переходите к следующим вариантам.

Способ 2: PowerShell — точный ответ за одну команду

PowerShell умеет читать заголовок PE (Portable Executable — стандартный формат исполняемых файлов Windows) и показывать разрядность напрямую. Откройте PowerShell и выполните:

$path = «C:\путь\к\файлу.exe»; [System.Reflection.AssemblyName]::GetAssemblyName($path).ProcessorArchitecture

Одна оговорка: эта команда работает корректно для .NET-сборок. Для обычных нативных EXE она может выдать ошибку или неточный результат. Универсальный вариант для любого EXE — разобрать заголовок вручную:

$bytes = [System.IO.File]::ReadAllBytes(«C:\путь\к\файлу.exe»); $peOffset = [BitConverter]::ToInt32($bytes, 0x3C); $machine = [BitConverter]::ToUInt16($bytes, $peOffset + 4); «0x{0:X4}» -f $machine

Результат интерпретируется так:

• 0x8664 — 64-битный файл (архитектура x64);
• 0x014C — 32-битный файл (архитектура x86);
• 0xAA64 — сборка под Windows on ARM (ARM64);
• 0x01C4 — сборка под 32-битный ARM.

Это самый надёжный программный способ без установки чего-либо: он читает то, что записано в самом файле, а не метаданные, которые разработчик мог и не заполнить.

Способ 3: шестнадцатеричный просмотр заголовка PE

Если хочется понять механику, а не просто получить ответ, откройте EXE в hex-редакторе (HxD, аналоги — любой просмотрщик двоичных файлов). Логика такая:

1. В начале файла найдите сигнатуру 4D 5A (буквы «MZ») — это начало DOS-заголовка.
2. По смещению 0x3C от начала файла лежит четырёхбайтное значение — адрес PE-заголовка. Обычно это что-то вроде 80, E0 или F0 в шестнадцатеричном виде.
3. Перейдите по этому адресу: там будет сигнатура 50 45 00 00 («PE»).
4. Сразу после сигнатуры идут два байта поля Machine. Значение 4C 01 означает 32-битный файл, 64 86 — 64-битный.

Байты записаны в обратном порядке (little-endian), поэтому 0x014C в файле выглядит как «4C 01», а 0x8664 — как «64 86». Способ неудобен для массовой проверки, но он показывает первоисточник: разрядность жёстко зашита в заголовок при компиляции и не зависит от системы, где файл лежит.

Способ 4: сторонние утилиты

Для регулярной работы удобнее специализированные инструменты. Они бесплатны и распространяются в портативном виде:

• Dumpbin из состава Visual Studio (или Build Tools): команда dumpbin /headers файл.exe, в выводе смотрите строку «machine (x86)» или «machine (x64)». Вариант для разработчиков, у кого инструменты уже установлены.
• PE-bear, CFF Explorer, pestudio — графические просмотрщики PE-заголовков: открываете файл и видите поле Machine в человекочитаемом виде.
• Exeinfo PE, Detect It Easy — определяют не только разрядность, но и компилятор, упаковщик, наличие защиты. Удобны при анализе незнакомых файлов.
• Process Explorer от Sysinternals — если программа уже запущена: добавьте колонку «Image Type» и увидите разрядность каждого процесса, включая пометку для 32-битных процессов на 64-битной системе.

Выбор зависит от задачи: для разовой проверки достаточно PowerShell, для анализа подозрительных файлов — pestudio или Detect It Easy, для работы с запущенными процессами — Process Explorer.

Сравнение способов

Способ	Что нужно	Надёжность	Когда удобен
Свойства файла	Только проводник	Средняя: зависит от заполненных метаданных	Быстрая разовая проверка
PowerShell (разбор PE)	Встроенная в Windows консоль	Высокая	Разовая и пакетная проверка без установки ПО
Hex-просмотр заголовка	Hex-редактор	Высокая	Понимание устройства файла, обучение
Dumpbin / PE-редакторы	Установка утилиты	Высокая	Регулярная работа, разработка, анализ
Process Explorer	Утилита Sysinternals	Высокая	Проверка уже запущенных процессов

Пакетная проверка нескольких файлов

Если нужно проверить целую папку, PowerShell справится и с этим. Пример цикла, который выводит имя файла и код архитектуры:

Get-ChildItem «C:\путь\к\папке» -Filter *.exe | ForEach-Object { $b = [System.IO.File]::ReadAllBytes($_.FullName); $off = [BitConverter]::ToInt32($b, 0x3C); $m = [BitConverter]::ToUInt16($b, $off + 4); «{0}: 0x{1:X4}» -f $_.Name, $m }

Такой подход полезен при аудите набора утилит или проверке содержимого дистрибутива перед развёртыванием. Учтите, что для упакованных или повреждённых файлов смещение PE-заголовка может читаться некорректно — в этом случае утилиты вроде Detect It Easy дадут более информативный ответ.

Типичные ошибки и нюансы

• Путаница с папкой SysWOW64. На 64-битной Windows 32-битные системные библиотеки лежат именно в SysWOW64, а 64-битные — в System32. Названия интуитивно «перевёрнуты», и это регулярно сбивает с толку.
• Доверие имени файла. Надписи вроде «setup_x64.exe» в имени — лишь желание разработчика, а не гарантия. Проверяйте заголовок, если разрядность критична.
• AnyCPU у .NET-приложений. Сборка .NET может быть помечена как «AnyCPU»: такой EXE не содержит машинного кода под конкретную архитектуру и запускается в 32- или 64-битном режиме в зависимости от системы и флагов сборки. Для .NET-файлов поле Machine может не дать полной картины — смотрите флаг PE32/PE32+ и корфлаги.
• Установщики. EXE-установщик может быть 32-битным, но устанавливать 64-битное приложение, и наоборот. Разрядность установщика и устанавливаемой программы — разные вещи.
• ARM-сборки. Файлы под Windows on ARM имеют свои коды архитектуры и на обычном x64-компьютере без эмуляции не запустятся.

Что делать после проверки

Если выяснилось, что разрядность файла не подходит под систему, варианты такие: найти альтернативную сборку программы (большинство приложений распространяются в обеих версиях), обновить операционную систему до 64-битной версии (если оборудование это поддерживает) или, для 32-битного файла на 64-битной системе, просто запустить его — он должен работать через подсистему совместимости. Если же 64-битный EXE не запускается на 64-битной Windows, причина почти наверняка не в разрядности: ищите проблему в отсутствующих библиотеках, правах доступа или повреждении файла.

Главный принцип: разрядность зашита в заголовок PE-файла при компиляции, и именно её нужно читать. Для разовой проверки достаточно PowerShell или свойств файла, для регулярной работы поставьте один из PE-просмотрщиков — это займёт минуту и избавит от догадок.