Запустятся ли бизнес-приложения на Windows on Arm — эмуляция x64 (Prism) и реальность нативных DLL и COM

«Со следующего месяца ставим новые ПК — вроде Copilot+ PC. Наша бизнес-система на них запустится?» По мере того как компании начинают закупать ПК на Snapdragon, этот вопрос всё чаще слышат разработчики и ИТ-службы. В описании продукта написано: существующие приложения работают через эмуляцию. Но своё бизнес-приложение за экраном на C# вызывает через P/Invoke нативную DLL вендора, отчёты идут через COM-компонент, плюс ещё драйвер специализированного оборудования. Честно говоря, на «запустится?» с ходу не ответишь.

Короткий ответ: само приложение обычно запускается. Риск — в том, что вокруг него. Эмуляция Windows 11 довольно точно обрабатывает пользовательский код x86/x64. Но есть чёткая зона, которую эмуляция не покрывает: драйверы, расширения оболочки, смешение архитектур внутри процесса. И именно в этой зоне бизнес-приложения привыкли жить.

В статье разбираем, как устроена эмуляция Windows on Arm и где у неё пределы, правило «x64 и Arm64 нельзя смешивать в одном процессе», характерную для .NET проблему сочетания AnyCPU и P/Invoke, и практический порядок проверки «запустится ли наше приложение на Arm-машине» — в пределах того, что можно сверить по Microsoft Learn.

1. Сначала вывод

Если нужно сразу, достаточно этих трёх пунктов.

1. Само приложение обычно запускается. Windows 11 on Arm выполняет приложения x86/x64 встроенной в ОС эмуляцией, а с 24H2 производительность ещё улучшил Prism.¹
2. Риск — в окружении. Драйверы режима ядра; DLL, которые загружаются в чужой процесс, как расширения оболочки и IME; несовпадение архитектуры нативных DLL и COM. Запустится ли система, решает не само приложение, а это.²³⁴
3. Проверки достаточно в три этапа. Инвентаризация зависимостей → проверка на Arm-машине в сборке x64 → при необходимости перевод на нативный Arm64. Порядок — в главе 6.

Термины Arm64EC и Arm64X разберём в главе 4; запоминать их сейчас не обязательно. Ниже — расшифровка этих трёх пунктов и источники. К деталям можно вернуться, когда они понадобятся.

• Чисто управляемое (.NET) приложение или обычное десктопное приложение x86/x64 почти наверняка запустится благодаря эмуляции Windows 11 on Arm. Эмуляция встроена в ОС: менять приложение и ставить дополнительные компоненты не нужно.¹
• Эмуляция обрабатывает только код пользовательского режима. Драйверы режима ядра не эмулируются и требуют нативного Arm64. Драйверы UMDF и драйверы принтеров тоже должны совпадать с архитектурой ОС.²³
• Расширения оболочки, IME, средства специальных возможностей — любые DLL, которые загружаются в чужой процесс (Explorer и т. п.), — тоже нужно пересобрать под тот же Arm64, что и система. Эмуляция здесь не поможет.⁴
• В одном процессе x64 и Arm64 сосуществовать не могут. Процесс x64/Arm64EC загружает только двоичные файлы x64 и Arm64EC, процесс Arm64 — только Arm64. Из x64-exe нельзя вызвать Arm64-DLL, и наоборот тоже нельзя.⁵
• Обойти это ограничение в пределах одного файла помогают Arm64EC (нативный код Arm64, который может жить в одном процессе с x64) и Arm64X (двоичный файл, в котором код Arm64 и Arm64EC совмещены в одном PE и который загружается в процесс любого из этих типов). Именно Arm64X нужен, когда внутрипроцессный COM-сервер или плагин вызывают с обеих архитектур.⁵⁶
• .NET официально поддерживает Windows Arm64 начиная с .NET 6 (в актуальных .NET 8/9/10 Arm64-редакции Windows 11/10 прямо указаны в списке поддерживаемых ОС), и нативную публикацию можно сделать с RID win-arm64. Если AnyCPU-приложение запускают на Arm64-рантайме .NET, процесс идёт как Arm64, поэтому P/Invoke к нативной DLL, которая есть только под x64, при загрузке завершится ошибкой — это сочетание стоит держать в уме отдельно.⁷⁸⁵
• Тестовую среду, помимо железа (Copilot+ PC и т. п.), можно развернуть на Arm64-VM с Windows 11 в Azure или через ISO Windows 11 Arm64, который подходит для Hyper-V на Arm-машине и для Mac на Apple Silicon. На Hyper-V на x64-машине Arm64-VM создать нельзя.⁹¹⁰

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 20, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Что такое Windows on Arm — ПК на Snapdragon и Prism

Windows on Arm — это Windows, которая работает на процессоре Arm64. С 2024 года большинство «Copilot+ PC» — новой категории ПК на Windows 11 с NPU, способным выполнять более 40 триллионов операций в секунду (40+ TOPS), — используют Arm-чипы серии Snapdragon X, и разработчикам уже нельзя это игнорировать.¹¹¹²

Совместимость с существующими приложениями обеспечивает эмуляция, встроенная в ОС. Кратко, как она устроена.¹

• Эмулятор выполняет JIT-компиляцию блоков инструкций x86/x64 в инструкции Arm64 и кэширует результат преобразования по модулям, чтобы следующие запуски были быстрее.
• Windows 11 эмулирует и x86, и x64. Windows 10 on Arm эмулирует только x86, поэтому разговор про x64-бизнес-приложения по сути всегда про Windows 11.
• В Windows 11 24H2 появился новый эмулятор Prism: по сравнению с прежним выросла производительность и снизилась нагрузка на CPU. Prism оптимизирован под чипы Qualcomm Snapdragon.
• 32-разрядные (x86) приложения работают поверх того же слоя WOW64, что и в x64-версии Windows, и получают перенаправление файловой системы и реестра. У x64-приложений слоя WOW64 нет: системные двоичные файлы собраны в формате Arm64X (о нём ниже), поэтому x64-приложение обращается ко всей ОС — и к файловой системе, и к реестру — без перенаправления.¹

Сведения о процессоре, которые видит приложение под эмуляцией, относятся к «эмулированному виртуальному процессору». Ради совместимости даже GetNativeSystemInfo возвращает эмулированное значение, поэтому чтобы узнать, действительно ли хост — Arm64, используйте IsWow64Process2 или GetMachineTypeAttributes.¹³

Отдельно: для приложений, у которых под эмуляцией возникают проблемы, Windows даёт способ изменить параметры эмуляции (пресеты «по умолчанию / безопасный / строгий / очень строгий» и отдельные детальные настройки) через правый щелчок по exe → «Свойства» → вкладка «Совместимость». Это обмен: совместимость ценой производительности. Имеет смысл держать в уме как запасной вариант для случаев «на старой Windows on Arm это работало».¹⁴

3. Что эмуляция запускает, а что нет

Ответ на «запустится?» определяется не самим приложением, а типом зависимостей. Прежде чем углубляться в детали, полезно зафиксировать где заканчивается зона действия эмуляции — по слоям. Тогда дальше решать быстрее.

Граница проходит по двум осям: внутри своего процесса или снаружи и пользовательский режим или режим ядра. Перечислить зависимости, которые лежат за этими двумя осями, — по сути и есть вся проверка поддержки Arm. Ниже то же самое, но единицами, которые реально разбирают на практике.

Если переложить это на язык бизнес-приложений, тревожные сигналы такие:

• VPN-клиенты, агенты управления активами, средства защиты — по сути набор драйверов режима ядра. Нужно уточнить у вендора, есть ли версия с поддержкой Arm64.
• Авторизация через USB-донглы, специализированное оборудование (измерительные приборы, платёжные терминалы и т. п.) — решающий фактор: есть ли драйвер устройства под Arm64.
• Инструменты, которые «добавляют функцию в Explorer» — расширения оболочки загружаются в Arm64-версию Explorer, поэтому в сборке x64 они просто не работают.
• Даже если само приложение в эти категории не попадает, тот же удар получает случай, когда установщик содержит драйвер (например, вывод в PDF через драйвер виртуального принтера).

4. Смешивать архитектуры внутри процесса нельзя — реальность P/Invoke и COM

Ещё с 32-разрядной эпохи действовало жёсткое правило: «64-разрядный процесс не может загрузить 32-разрядную DLL».¹⁶ На Windows on Arm действует то же правило по структуре. Официально, что можно загружать, сведено в такую таблицу.⁵

Два механизма ниже — ключ к проектированию поддержки Arm.

• Arm64EC (Emulation Compatible) — это ABI нативного кода Arm64, который следует соглашению о вызовах, использованию стека и раскладке данных x64 и поэтому может жить в одном процессе с x64-кодом, идущим под эмуляцией. Когда x64-приложение работает в Windows 11 on Arm, бо́льшая часть кода ОС, загружаемого в этот процесс, уже собрана как Arm64EC и выполняется с нативной скоростью, приложение об этом не знает. Зависимые DLL можно оставить x64 и постепенно переводить свой код на Arm64EC, поднимая производительность — это путь поэтапной миграции.⁵
• Arm64X — формат двоичного файла, в котором обычный код Arm64 и код Arm64EC совмещены в одном PE-файле. Если загружающий процесс x64, файл ведёт себя как x64-DLL, если Arm64 — как Arm64-DLL. Это удобно для DLL, которую потенциально вызывают процессы обеих архитектур. В официальной документации ситуации, где нужен Arm64X, названы так: «64-разрядный COM-сервер, который вызывают и x64-, и Arm64-приложения», «плагин, загружаемый и в x64-, и в Arm64-приложения», «один двоичный файл, внедряемый в процессы x64/Arm64».⁶

Разберём, чем это оборачивается для бизнес-приложений.

Случай 1: x64-exe + нативная x64-DLL (P/Invoke). Если весь процесс единообразно x64, он целиком работает внутри эмуляции. «Ускорить только часть», подмешав Arm64-DLL, нельзя (как в таблице выше — загрузка запрещена).

Случай 2: внутрипроцессный COM-сервер. In-proc COM-сервер — это просто DLL, поэтому таблица выше применяется напрямую. x64-клиент может использовать только COM-DLL x64 (или Arm64EC/Arm64X). В момент, когда приложение станет нативным Arm64, x64 COM-DLL перестанет загружаться. Если нужна поддержка обеих архитектур, либо собирайте DLL как Arm64X, либо применяйте приём, проверенный ещё на границе 32/64 бит: разнести по процессам и связать через внепроцессный COM или IPC. Архитектурную границу исторически переходят на границе процессов.¹⁶⁶

Случай 3: вы хостите плагин или сами являетесь плагином. Надстройки Excel, плагины бизнес-пакетов, промежуточное ПО для печати и любая схема, где «вашу DLL загружают в чужой процесс», должны совпадать с архитектурой процесса-хоста. И наоборот: если своё приложение само хостит плагины, перевод его на нативный Arm64 отключит все сторонние x64-плагины — зону влияния нужно оценить заранее.

Кстати, к какой архитектуре относится конкретный двоичный файл, можно узнать из командной строки разработчика.⁵

link /dump /headers MyLibrary.dll

Смотреть нужно только одну строку сразу после FILE HEADER VALUES. В официальной документации показан вывод такого вида.⁵

File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
    8664 machine (x64) (ARM64X)

Эту строку machine читают так.

Вывод длинный, поэтому на практике удобно оставить одну строку: link /dump /headers MyLibrary.dll | findstr machine. Если той же командой смотреть промежуточные OBJ/LIB, появится A641 machine (ARM64EC) — это внутренний идентификатор MSVC, а не итоговое значение machine у EXE/DLL.⁵

Если нужно понять уже запущенное приложение, в диспетчере задач на вкладке «Подробности» можно показать столбец «Архитектура». Приложение, чьё исполняемое собрано как Arm64EC, отображается как ARM64 (x64 compatible).⁵

5. Случай .NET-приложений — ловушка AnyCPU и определение архитектуры

.NET (семейство Core) официально поддерживает Windows Arm64 начиная с .NET 6. В актуальных .NET 8/9/10 Arm64-редакции Windows 11/10 прямо указаны в списке поддерживаемых ОС. Для публикации достаточно указать RID win-arm64.¹⁷⁷

<!-- csproj: публикация под нативный Arm64 -->
<PropertyGroup>
  <TargetFramework>net8.0-windows</TargetFramework>
  <RuntimeIdentifiers>win-x64;win-arm64</RuntimeIdentifiers>
</PropertyGroup>

dotnet publish -r win-arm64 -c Release

Если приложение состоит только из управляемого кода, перевод на нативный Arm64 на этом почти закончен. JIT просто генерирует код Arm64, исходники как правило трогать не нужно. Для приложений на .NET Framework нативную поддержку Arm64 добавила версия 4.8.1 (для Arm64-машин под Windows 11; рантайм 4.8.1 не поддерживает нативные Arm64-приложения на Arm-машинах с Windows 10). Приложение на Framework, оставленное в сборке x64, считается работающим через эмуляцию.¹⁸¹⁹

Проблема — в сочетании, которое возникает при P/Invoke к нативной DLL. На Arm-машине привычка «это .NET, значит AnyCPU запустится где угодно» подводит.

• При запуске под Arm64-версией SDK/рантайма .NET приложение по умолчанию работает как процесс Arm64.⁸
• Процесс Arm64 не может загрузить x64-DLL (таблица в главе 4). То есть свой AnyCPU-код остаётся нетронутым, но загрузка нативной x64-DLL, подключённой через DllImport, завершается ошибкой.⁵
• Наоборот, приложение, опубликованное как win-x64, целиком идёт как x64-процесс и работает внутри эмуляции (вместе с нативной x64-DLL). Нативной производительности Arm64 в этом случае нет, зато это конфигурация с максимальной совместимостью.¹²

То, что выглядит как «то работает, то нет», обычно оказывается несовпадением архитектуры процесса и архитектуры его нативных зависимостей. Первый шаг диагностики — уметь из кода сказать, под какой архитектурой реально выполняется текущий процесс. Тогда разбор сразу становится проще.

using System.Runtime.InteropServices;

// Архитектура самого процесса (X64, если идёт под эмуляцией x64)
Console.WriteLine($"Process: {RuntimeInformation.ProcessArchitecture}");

// Реальная архитектура ОС (Arm64 на Arm-машине)
Console.WriteLine($"OS: {RuntimeInformation.OSArchitecture}");

Важно: OSArchitecture начал возвращать «реальную архитектуру ОС, без эмуляции» только с .NET 7. Раньше под эмуляцией он возвращал X64, поэтому код на .NET 6 и старше, который по этому API решает «это Arm-машина?», ведёт себя не так, как ожидают.²⁰²¹

Сведём контрольные точки, специфичные для .NET.

• Нативные файлы в NuGet-пакетах: пакет, в котором есть только runtimes/win-x64/native, при публикации под win-arm64 ничего подставить не может. Проверяйте содержимое пакета (или репозиторий) на ресурсы для win-arm64. RID как раз и нужен для этой «маршрутизации платформенных ресурсов».⁷
• Состав SDK на машине разработки: на Arm-машине Arm64-версия .NET обычно стоит в C:\Program Files\dotnet\, а SDK для x64 — в C:\Program Files\dotnet\x64\, и они могут сосуществовать. Под какой архитектурой реально выполняется dotnet run, зависит от того, куда указывают PATH или DOTNET_ROOT. При проверке это нужно учитывать.¹⁷
• Как читать исключение: несовпадение архитектуры в управляемой сборке проявляется как BadImageFormatException (в официальном справочнике прямо сказано, что условие возникновения — «загрузка компонента, предназначенного для другой платформы»).²²

6. Чек-лист: готовность своего приложения к Arm

На практике эффективнее проверять в три этапа.

Сопоставим, на каком этапе всплывают случаи из главы 4.

Для этапов 2 и 3 тестовую среду можно взять такую.

• Реальное устройство: машина на Snapdragon вроде Copilot+ PC. Хотя бы одно такое устройство даёт наибольшую уверенность, включая разбор проблем.¹²
• VM в Azure: в портале Azure можно отфильтровать образы по Arm64 и создать Arm64-VM с Windows 11 (рекомендуемый размер, например D2ps_v5, на базе Ampere Altra). Плюс в том, что тестирование можно начать, не имея под рукой ни одной Arm-машины.⁹
• Локальная VM: официально распространяется ISO Windows 11 Arm64, VM можно создать на Hyper-V на Arm-машине или на Mac с Arm-based Apple Silicon. На Hyper-V на x64-машине Arm64-VM создать нельзя.¹⁰

Состояние поддержки сторонних продуктов можно проверить на сайте, на который указывает Microsoft (Windows on Arm Ready Software). Дальше, по проблемам совместимости своих бизнес-приложений (LOB) и приложений ISV есть официальная служба App Assure. То, что канал помощи есть до ситуации «не запускается и деваться некуда», полезно и как аргумент для ИТ-службы.¹²¹⁵

Критерии, подходит ли вам программа, такие.²⁴²⁵

Подходит ли ваш набор лицензий, быстрее всего сверить названия планов выше с договором в ИТ-службе и отделе закупок. Порог по числу лицензий и список планов могут меняться, поэтому перед заявкой сверьтесь с актуальной страницей условий FastTrack.

7. Практичное решение на сегодня — три варианта

Поддержка Arm — это не «всё перевести на нативный код». Для многих бизнес-приложений реалистичнее поэтапный выбор по ситуации.

Если объём кода на C++ большой, между (а) и (в) есть промежуточный путь — Arm64EC. Свой код можно постепенно переводить на нативный, оставляя зависимые x64-DLL как есть. Это официальный маршрут для случаев «огромное x64-приложение нельзя перевести за один шаг».⁵²³

Со стороны инструментов есть нативная под Arm64 версия Visual Studio, а на Arm-машине доступен набор компилятора, который собирает сразу под Arm64, x64 и x86. Сборки для CI можно получать кросс-компиляцией на существующей x64-машине, поэтому конфигурация «на Arm-устройство или VM переносится только запуск тестов» собирается проще.²⁶²³

8. Итог

• Windows 11 on Arm запускает приложения x86/x64 встроенной в ОС эмуляцией, а с 24H2 производительность ещё улучшил Prism. Эмуляция x64 появилась начиная с Windows 11, Windows 10 on Arm поддерживает только x86.
• Эмуляция покрывает только пользовательский режим. Драйверы режима ядра, UMDF и принтеров, а также DLL, загружаемые в чужой процесс — расширения оболочки, IME, средства специальных возможностей, — требуют нативного Arm64. Запустится ли бизнес-приложение, решает не оно само, а эти окружающие зависимости.
• Внутри процесса x64 и Arm64 сосуществовать не могут. Процесс x64/Arm64EC загружает x64 и Arm64EC, процесс Arm64 — только Arm64. Внутрипроцессные COM-серверы и плагины подчиняются тому же правилу: стандартный ответ для поддержки обеих архитектур — Arm64X, стандартный ответ для перехода через границу процесса — внепроцессный COM или IPC.
• .NET умеет публиковать нативно под win-arm64, но AnyCPU-приложение на Arm64-рантайме выполняется как процесс Arm64, поэтому P/Invoke к нативной DLL только под x64 завершится ошибкой. Для диагностики используйте RuntimeInformation.ProcessArchitecture / OSArchitecture (последнее — начиная с .NET 7).
• Порядок проверки — три этапа: «инвентаризация зависимостей → проверка на устройстве в исходном виде под эмуляцией → при необходимости перевод на нативный Arm64». Тестовую среду можно развернуть через Arm64-VM в Azure или ISO Arm64, корпоративным клиентам доступна поддержка App Assure.
• На сегодня практичное решение — выбирать по ситуации: «если под эмуляцией работает — оставить как есть», «уточнить у вендоров драйверов и DLL статус поддержки», «перевести на нативный Arm64, если того требуют условия (для C++ возможна и поэтапная миграция через Arm64EC)».

Похожие статьи

• Вызов нативной DLL из C#: обёртка C++/CLI против P/Invoke
• Безопасный вызов Win32 API из C# — практическое руководство по P/Invoke (DllImport / LibraryImport / CsWin32)
• Как вызвать C# Native AOT DLL из C/C++
• Распространение Windows-приложения одним файлом — единый бинарник и пределы зависимости от ОС
• Практический пример COM-моста: вызов 64-битной DLL из 32-битного приложения

Смежные области консультаций

В Komura Software LLC мы занимаемся исследованием готовности существующих бизнес-приложений к Windows on Arm, проектированием миграции архитектуры приложений с нативными DLL и COM-интеграцией, а также анализом первопричин сбоев, которые воспроизводятся только на Arm-машинах.

• Разработка приложений для Windows
• Техническая консультация и ревью архитектуры
• Расследование сбоев и анализ первопричин
• Контакты

Справочные материалы

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Запустится ли обычное x64-бизнес-приложение на Windows on Arm?

В большинстве случаев да. В Windows 11 on Arm встроена эмуляция, которая запускает приложения x86/x64 без изменений, а начиная с Windows 11 24H2 новый эмулятор Prism ещё и улучшил производительность. Но эмуляция обрабатывает только код пользовательского режима. Драйверы режима ядра, а также расширения оболочки и IME, которые загружаются в чужие процессы вроде Explorer, требуют нативного Arm64. Смотреть нужно не на само приложение, а на зависимости вокруг него.

Может ли x64-exe вызвать Arm64-DLL?

Нет. Смешивать двоичные файлы x64 и Arm64 в одном процессе нельзя: процесс x64 (или Arm64EC) загружает только двоичные файлы x64 и Arm64EC, процесс Arm64 — только Arm64. В обратную сторону (Arm64-exe вызывает x64-DLL) тоже нельзя. Если нужна одна DLL на обе архитектуры, варианты — формат Arm64X, в котором код Arm64 и Arm64EC живут в одном файле, либо разнести работу по процессам и связать их через IPC.

Что нужно, чтобы подготовить .NET-приложение к Arm64?

.NET 6 и новее официально поддерживают Windows Arm64. В актуальных .NET 8/9/10 Arm64-редакции Windows 11/10 прямо указаны в списке поддерживаемых ОС. Достаточно опубликовать приложение с RID (идентификатором среды выполнения) win-arm64 — получится нативный исполняемый файл под Arm64. Если код чисто управляемый, на этом почти всё. Если есть нативные DLL через P/Invoke или NuGet-пакеты с нативными файлами, для каждого нужно проверить, есть ли сборка под Arm64. Для приложений на .NET Framework нативное выполнение на Arm64 в Windows 11 даёт версия 4.8.1.

Какое ПО не работает на Windows on Arm?

В первую очередь — ПО с драйверами режима ядра. Драйверы не эмулируются, поэтому VPN-клиенты, средства защиты, виртуальные устройства и авторизация через USB-донглы без драйвера Arm64 не заработают. Дальше — расширения оболочки, IME и средства специальных возможностей, которые загружают DLL в процессы самой ОС; приложения, запрещающие динамическую генерацию кода; игры, зависящие от устаревшего OpenGL или античит-драйверов. Периферия тоже зависит от того, есть ли драйвер Arm64.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.