合同会社小村ソフト
相談する
メニュー

Arm版Windowsで業務アプリは動くのか ── x64エミュレーション(Prism)とネイティブDLL・COMの現実

· · Windows on Arm, Arm64, x64エミュレーション, ネイティブ連携, P/Invoke, COM, ドライバー, C#, .NET, Windows開発, 技術相談

「来月からの新しいPC、Copilot+ PCというやつにするんですが、うちの業務システムは動きますか？」── Snapdragon搭載PCの法人導入が進むにつれて、この質問を受ける開発会社・情シスが増えています。カタログには「既存アプリもエミュレーションで動作」と書いてある。でも自社の業務アプリは、C#の画面の裏でベンダー提供のネイティブDLLをP/Invokeし、帳票はCOMコンポーネント経由、おまけに専用機器のドライバーまで入っている。「動きますか？」に即答できないのが正直なところではないでしょうか。

答えを先に言えば、「アプリ本体はたいてい動く。危ないのはアプリの周辺にいる連中」です。x86/x64のユーザーモードコードはWindows 11のエミュレーションがかなりの精度で面倒を見てくれる一方、ドライバー・シェル拡張・プロセス内のアーキテクチャ混在という「エミュレーションの守備範囲外」がはっきり存在します。そしてこの守備範囲外こそ、業務アプリが好んで使ってきた領域です。

この記事では、Windows on Armのエミュレーションの仕組みと限界、x64とArm64をプロセス内で混ぜられないという大原則、.NETアプリ特有の組み合わせ問題、そして「自社アプリがArm機で動くか」を確認する実務手順を、Microsoft Learnで裏取りできる範囲で整理します。

1. まず結論

  • 純粋なマネージド(.NET)アプリや普通のx86/x64デスクトップアプリは、Arm版Windows 11のエミュレーションでほぼ動きます。エミュレーションはOS組み込みで、アプリの修正も追加コンポーネントも不要です。1
  • エミュレーションが面倒を見るのはユーザーモードのコードだけです。カーネルモードドライバーはエミュレーションされず、Arm64ネイティブが必須です。UMDFドライバーやプリンタードライバーもOSのアーキテクチャに一致させる必要があります。23
  • シェル拡張・IME・支援技術など「他プロセス(Explorer等)にロードされるDLL」も、システムと同じArm64への再コンパイルが必要です。エミュレーションでは救えません。4
  • 1つのプロセス内でx64とArm64は混在できません。x64/Arm64ECプロセスがロードできるのはx64とArm64ECのバイナリ、Arm64プロセスがロードできるのはArm64のバイナリだけです。x64のexeからArm64のDLLは呼べず、逆も呼べません。5
  • この制約を1ファイルで越えるための仕組みがArm64EC(x64と同一プロセスで混在できるネイティブArm64コード)とArm64X(Arm64とArm64ECを1つのPEに同居させ、どちらのプロセスにもロードできるバイナリ)です。両アーキテクチャから呼ばれるCOMインプロセスサーバーやプラグインはArm64Xの出番です。56
  • .NETはArm64を正式サポートしており、RID win-arm64 でネイティブ発行できます。一方でAnyCPUのアプリをArm64の.NETランタイムで動かすとプロセスはArm64として走るため、x64しかないネイティブDLLをP/Invokeしていると読み込みに失敗する、という組み合わせ問題が起きます。785
  • 検証環境は、実機(Copilot+ PC等)のほか、AzureのWindows 11 Arm64 VM、Arm機上のHyper-VやApple SiliconのMacで使えるWindows 11 Arm64 ISOで用意できます。※x64機のHyper-VではArm64 VMは作れません。910

2. Arm版Windowsとは ── Snapdragon搭載PCとPrism

Arm版Windowsは、Arm64プロセッサー上で動くWindowsです。2024年以降、「Copilot+ PC」── 毎秒40兆回以上の演算(40+ TOPS)が可能なNPUを搭載したWindows 11 PCの新カテゴリー ── の多くがArmベースのSnapdragon Xシリーズを採用したことで、開発者が意識せざるを得ない存在になりました。1112

既存アプリとの互換性を支えるのがOS組み込みのエミュレーションです。仕組みの要点は次のとおりです。1

  • エミュレーターはx86/x64命令のブロックをArm64命令へJITコンパイルし、変換結果をモジュールごとにキャッシュして2回目以降の起動を速くします。
  • Windows 11はx86とx64の両方をエミュレーションできます。Windows 10 on Armがエミュレーションできるのはx86のみなので、x64業務アプリの話は実質Windows 11前提です。
  • Windows 11 24H2では新しいエミュレーターPrismが導入され、従来より性能が向上しCPU使用率が下がりました。PrismはQualcomm Snapdragon向けに最適化されています。
  • 32bit(x86)アプリは、x64版Windowsと同じWOW64レイヤーの上で動き、ファイルシステム・レジストリのリダイレクトを受けます。一方x64アプリにはWOW64レイヤーがなく、システムバイナリが後述のArm64X形式でコンパイルされているため、x64アプリはリダイレクトなしでOS全体(ファイルシステムもレジストリも)にアクセスできます。1

エミュレーション下のアプリから見えるCPU情報は「エミュレートされた仮想プロセッサー」のものです。互換性のため GetNativeSystemInfo すらエミュレートされた値を返すので、ホストがArm64かどうかを知りたければ IsWow64Process2 や GetMachineTypeAttributes を使います。13

なお、エミュレーションで問題が出たアプリ向けに、exeを右クリック→プロパティ→互換性タブからエミュレーション設定(既定/安全/厳密/非常に厳密のプリセットと個別詳細設定)を変更する仕組みがWindows側に用意されています。互換性と引き換えに性能が落ちる調整ですが、「昔のWindows on Armでは動いていたのに」というケースの逃げ道として覚えておく価値があります。14

3. エミュレーションで動くもの・動かないもの

「動きますか？」への回答は、アプリ本体ではなく依存物の種類で決まります。判断表にまとめます。

分類 Arm版Windows 11での扱い 根拠・備考
x86/x64のユーザーモードアプリ(exe + 同アーキテクチャのDLL一式) エミュレーションで動く 無修正・追加インストール不要1
.NET(マネージド)アプリ 動く(Arm64ネイティブ実行も可) 第5章参照8
カーネルモードドライバー 動かない。Arm64ネイティブ必須 カーネルにエミュレーションはない23
UMDFドライバー・プリンタードライバー OSと同じArm64が必須 アプリ本体はエミュで動いても、ドライバー依存の機能は使えない3
シェル拡張・IME・支援技術(他プロセスにロードされるDLL) Arm64への再コンパイルが必要 Explorerの右クリックメニュー、クラウドストレージのアイコン表示など4
動的コード生成を禁止したx86アプリ エミュレーションでは動かない エミュレーターは実行時にArm64命令を生成するため、ProcessDynamicCodePolicy 緩和が必要4
古いOpenGL・アンチチートドライバー依存のゲーム 動かないことがある OpenGL 3.3超やArm未対応アンチチートが障壁15
周辺機器(プリンター、スキャナー、専用デバイス) Arm64ドライバーの有無で決まる OS同梱またはメーカー提供のArm64ドライバーが必要15
ウイルス対策・「Windowsの体験を変える」系ソフト 要個別確認 Arm対応は進んだが製品ごとの確認を推奨15

業務アプリの文脈で言い直すと、危険信号は次のようなものです。

  • VPNクライアント、資産管理エージェント、セキュリティ製品 ── カーネルドライバーの塊です。Arm64対応版の有無をベンダーに確認する必要があります。
  • USBドングル認証、専用機器(計測器・決済端末等) ── デバイスドライバーがArm64で提供されているかが生命線です。
  • 「Explorerに機能を足す」系ツール ── シェル拡張はArm64のExplorerにロードされるため、x64のままでは機能しません。
  • アプリ本体がこれらに該当しなくても、インストーラーがドライバーを同梱しているケース(仮想プリンタードライバー方式のPDF出力など)は同じ問題を踏みます。

4. プロセス内のアーキテクチャ混在はできない ── P/InvokeとCOMの現実

32bit時代から「64bitプロセスは32bit DLLをロードできない」という鉄則がありました16。Arm版Windowsにも同じ構造の鉄則があります。ロード可否のルールは公式に次のとおり整理されています。5

プロセスのアーキテクチャ x64 DLL Arm64EC DLL Arm64 DLL Arm64X DLL
x64 / Arm64EC プロセス ロード可 ロード可 不可 ロード可
Arm64 プロセス 不可 不可 ロード可 ロード可

ここで登場する2つの仕組みが、Arm対応の設計を考えるうえでの鍵です。

  • Arm64EC(Emulation Compatible)は、x64の呼び出し規約・スタック使用・データレイアウトに従うことで、同一プロセス内でエミュレーション実行されるx64コードと混在できるネイティブArm64コードのABIです。x64アプリがWindows 11 on Armで動くとき、そのプロセスにロードされるOSコードの大半はArm64ECでコンパイルされており、アプリが知らないままネイティブ速度で実行されています。依存DLLがx64のままでも、自分のコードから順にArm64EC化して性能を上げていく、という段階的移行に使えます。5
  • Arm64Xは、従来のArm64コードとArm64ECコードを1つのPEファイルに同居させたバイナリ形式です。ロードするプロセスがx64ならx64のDLLとして、Arm64ならArm64のDLLとして振る舞うため、両方のアーキテクチャのプロセスから呼ばれる可能性があるDLLに向いています。公式ドキュメントはArm64Xが必要な状況として「x64とArm64の両方のアプリから呼ばれる64bit COMサーバー」「x64/Arm64どちらのアプリにもロードされるプラグイン」「x64/Arm64プロセスに注入される単一バイナリ」を挙げています。6

業務アプリでの実害を具体化しましょう。

ケース1: x64のexe + x64のネイティブDLL(P/Invoke)。プロセス全体がx64で統一されているなら、丸ごとエミュレーションの中で動きます。「一部だけ速くしたい」とArm64のDLLを混ぜることはできません(上表のとおり不可)。

ケース2: COMインプロセスサーバー。COMのin-procサーバーはただのDLLなので、上表のルールがそのまま適用されます。x64クライアントからはx64(またはArm64EC/Arm64X)のCOM DLLしか使えず、アプリをArm64ネイティブ化した瞬間、x64のCOM DLLはロードできなくなります。両対応が必要なら、DLLをArm64X化するか、32bit↔64bitで実績のあるアウトプロセスCOM/IPC分離(プロセスを分けてプロセス間通信でつなぐ)の定石を適用します。アーキテクチャの壁はプロセス境界で越えるのが昔からの基本形です。166

ケース3: 自分がプラグインをホストする/される。Excelアドイン、業務パッケージのプラグイン、印刷ミドルウェアなど、「相手のプロセスに自分のDLLがロードされる」形態は、相手のアーキテクチャに合わせる必要があります。逆に自社アプリがプラグインをホストしているなら、自社アプリをArm64化するとx64のサードパーティプラグインが全滅する、という影響範囲の読みが必要です。

ちなみに、手元のバイナリがどれなのかは開発者コマンドプロンプトで確認できます。5

link /dump /headers MyLibrary.dll | findstr machine
# 8664 machine (x64)            → x64
# 8664 machine (x64) (ARM64X)   → Arm64EC を含む
# AA64 machine (ARM64)          → Arm64
# AA64 machine (ARM64) (ARM64X) → Arm64X

5. .NETアプリの場合 ── AnyCPUの罠とアーキテクチャ判定

.NET(Core系)はWindows Arm64を正式サポートしており、Windows 11/10のArm64は.NET 8/9/10のサポート対象OSに明記されています。発行はRIDに win-arm64 を指定するだけです。177

<!-- 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アプリの場合は、.NET Framework 4.8.1がArm64ネイティブサポートを追加しています(Windows 11のArm64機向け。4.8.1ランタイムはWindows 10のArm機ではネイティブArm64アプリをサポートしません)。x64ビルドのままのFrameworkアプリは、エミュレーションで動く扱いです。1819

問題はネイティブDLLをP/Invokeしている場合の組み合わせです。Arm機では「.NETアプリだからAnyCPUでどこでも動く」という長年の感覚が裏切られます。

  • Arm64の.NET SDK/ランタイムで実行すると、アプリは既定でArm64プロセスとして走ります。8
  • Arm64プロセスはx64のDLLをロードできません(第4章の表)。つまりAnyCPUの自社コードは無傷でも、DllImport しているx64ネイティブDLLの読み込みで失敗します。5
  • 逆に、win-x64 として発行したアプリはプロセス全体がx64となり、エミュレーションの中で(x64ネイティブDLLごと)動きます。この場合Arm64ネイティブの性能は得られませんが、動作互換性は最も高い構成です。12

「動いたり動かなかったりする」ように見える正体は、たいていプロセスのアーキテクチャとネイティブ依存物のアーキテクチャの不一致です。切り分けの第一歩として、実行中のプロセスが何で走っているかをコードで確認できるようにしておくと調査が一気に楽になります。

using System.Runtime.InteropServices;

// プロセス自身のアーキテクチャ(x64エミュレーション下なら X64)
Console.WriteLine($"Process: {RuntimeInformation.ProcessArchitecture}");

// OS本来のアーキテクチャ(Arm機なら Arm64)
Console.WriteLine($"OS: {RuntimeInformation.OSArchitecture}");

注意点として、OSArchitecture が「エミュレーションを剥がした本来のOSアーキテクチャ」を返すようになったのは.NET 7からです。それ以前はエミュレーション下でX64を返していたため、.NET 6以前で「Arm機かどうか」をこのAPIで判定しているコードは期待どおり動きません。2021

.NET固有のチェックポイントをまとめます。

  • NuGetパッケージのネイティブ資産: runtimes/win-x64/native しか持たないパッケージは、win-arm64 発行時に頼るものがありません。パッケージの中身(またはリポジトリ)で win-arm64 資産の有無を確認します。RIDはまさにこの「プラットフォーム固有資産の振り分け」のための仕組みです。7
  • 開発機のSDK構成: Arm機では、Arm64版.NETは通常の C:\Program Files\dotnet\ に、x64版SDKは C:\Program Files\dotnet\x64\ にインストールされ、共存できます。PATHやDOTNET_ROOTがどちらを向いているかで dotnet run の実行アーキテクチャが変わるので、検証時は意識してください。17
  • 例外の読み方: マネージドアセンブリのアーキテクチャ不一致は BadImageFormatException として現れます(公式リファレンスにも「異なるプラットフォームを対象とするコンポーネントの読み込み」が発生条件として明記されています)。22

6. 自社アプリのArm対応チェックリスト

実務では次の3段階で確認するのが効率的です。

段階 やること 判断
① 依存の棚卸し P/InvokeしているネイティブDLL、COMコンポーネント、同梱ドライバー、シェル拡張、ネイティブ資産入りNuGetを一覧化する ドライバー・シェル拡張がゼロなら有望。あれば各ベンダーのArm64対応を確認34
② エミュレーションでの実機確認 x64ビルドのままArm機(またはArm64 VM)にインストールし、主要業務シナリオを一巡する 動けば「x64のまま運用」が選択肢に。動かない箇所は依存物とアーキテクチャ不一致を疑う1
③ Arm64ネイティブビルドの検討 .NETなら win-arm64 発行、C++ならArm64構成を追加してビルドが通るか確認する 通らない原因は依存ライブラリのArm64版不在が典型。更新・差し替え・Arm64EC活用を検討23

②③のための検証環境は、次の選択肢があります。

  • 実機: Copilot+ PC等のSnapdragon搭載機。1台あるとトラブル調査まで含めて最も確実です。12
  • Azure VM: AzureポータルでイメージをArm64でフィルターし、Windows 11のArm64 VM(推奨サイズD2ps_v5等、Ampere Altraベース)を作成できます。手元にArm機が1台もなくても検証を始められるのが利点です。9
  • ローカルVM: Windows 11 Arm64のISOが公式配布されており、Arm機上のHyper-VやArmベースのApple Silicon Mac上でVMを作れます。x64機のHyper-VではArm64 VMは作成できない点に注意してください。10

サードパーティ製品の対応状況は、Microsoftが案内している対応状況サイト(Works on Windows on Arm)で確認できるほか、業務アプリ(LOB)の互換性問題については、対象プランの法人向けにApp Assureプログラムが追加費用なしで支援を提供しています。「動かないので八方塞がり」の前に使える公式窓口がある、というのは情シスへの説明材料としても有効です。1215

7. 当面の現実解 ── 3つの選択肢の使い分け

Arm対応は「全部ネイティブ化」一択ではありません。むしろ多くの業務アプリでは、段階的な使い分けが現実解です。

選択肢 向いているケース 注意点
(a) x64のままエミュレーションで運用 ドライバー・シェル拡張依存がなく、性能も実用十分な場合 Prism(24H2以降)で性能は改善済み。プロセス全体をx64で統一し、Arm64バイナリを混ぜない15
(b) ベンダーのArm64対応を確認・待機 ネイティブDLL・ドライバーがサードパーティ製の場合 「Arm64版DLL(またはArm64X版)の提供予定」を確認。ドライバーは待つ以外の回避策がない323
(c) Arm64ネイティブビルド 純.NETアプリ、または依存のArm64版が揃った場合。性能・電池持ちが要件の場合 win-arm64 発行+全ネイティブ依存のArm64化が条件。プラグインをホストする場合は影響範囲に注意75

C++資産が大きい場合は、(a)と(c)の中間としてArm64ECがあります。x64の依存DLLをそのままに、自分のコードだけを段階的にネイティブ化できるため、「巨大なx64アプリを一気に移行できない」ケースの公式ルートです。523

開発環境の面では、Visual StudioにArm64ネイティブ版があり、Arm機上でArm64/x64/x86すべてをターゲットにできるコンパイラーツールセットが揃っています。CI用のビルドは既存のx64ビルドマシンでのクロスコンパイルでも作れるので、「テスト実行だけArm実機/VMに寄せる」構成が組みやすくなっています。2423

8. まとめ

  • Arm版Windows 11はx86/x64アプリをOS組み込みのエミュレーションで実行でき、24H2以降はPrismで性能も改善されています。x64エミュレーションはWindows 11からで、Windows 10 on Armはx86のみです。
  • エミュレーションの守備範囲はユーザーモードだけです。カーネルモード/UMDF/プリンターの各ドライバー、シェル拡張・IME・支援技術のような「他プロセスにロードされるDLL」はArm64ネイティブが必須です。業務アプリの可否はアプリ本体ではなく、この周辺依存で決まります。
  • プロセス内でx64とArm64は混在できません。x64/Arm64ECプロセスはx64+Arm64ECを、Arm64プロセスはArm64のみをロードできます。COMインプロセスサーバーもプラグインも同じルールに従い、両対応にはArm64X、プロセス境界を越えるならアウトプロセスCOM/IPCが定石です。
  • .NETは win-arm64 でネイティブ発行できますが、Arm64ランタイム上のAnyCPUアプリはArm64プロセスとして走るため、x64のみのネイティブDLLをP/Invokeしていると失敗します。RuntimeInformation.ProcessArchitecture / OSArchitecture(.NET 7以降)で切り分けます。
  • 確認手順は「依存の棚卸し→x64のままエミュレーションで実機確認→必要ならArm64ネイティブ化」の3段階です。検証環境はAzureのArm64 VMやArm64 ISOで用意でき、法人はApp Assureの支援も受けられます。
  • 当面は「エミュレーションで動けばそのまま」「ドライバー・DLLベンダーの対応確認」「要件次第でArm64ネイティブ化(C++はArm64ECの段階移行も)」の使い分けが現実解です。

関連記事

関連する相談領域

合同会社小村ソフトでは、既存業務アプリのArm版Windows対応可否の調査、ネイティブDLL・COM連携を含むアプリのアーキテクチャ移行設計、「Arm機でだけ動かない」不具合の原因解析を扱っています。

参考リンク

  1. Microsoft Learn, How emulation works on Arm. エミュレーションがOS組み込みで無修正のアプリを実行できること、Windows 11がx86/x64両対応でWindows 10 on Armはx86のみであること、x86命令ブロックのJIT変換とキャッシュの仕組み、Windows 11 24H2のPrismとSnapdragon向け最適化、x86アプリはWOW64でリダイレクトを受け、x64アプリはWOW64なしでArm64Xのシステムバイナリを使うことについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Microsoft Learn, How emulation works on Arm. エミュレーションがユーザーモードコードのみをサポートし、ドライバーをサポートしないこと、カーネルモードコンポーネントはArm64としてコンパイルする必要があることについて。 ↩ ↩2

  3. Microsoft Learn, Troubleshooting x86 desktop apps. すべてのカーネルモードドライバー・UMDFドライバー・プリンタードライバーがOSのアーキテクチャに一致する必要があり、アプリ本体がエミュレーションで動いてもドライバー依存の機能は使えないことについて。 ↩ ↩2 ↩3 ↩4 ↩5

  4. Microsoft Learn, Troubleshooting x86 desktop apps. Windowsのプロセスに自分のDLLをロードさせるアプリ(シェル拡張・IME・支援技術)はシステムのアーキテクチャ(Arm64)に合わせた再コンパイルが必要なこと、動的コード生成を禁止したx86アプリはエミュレーションで実行できないことについて。 ↩ ↩2 ↩3 ↩4

  5. Microsoft Learn, Arm64EC - Build and port apps for native performance on Arm. x64/Arm64ECプロセスがx64とArm64ECのバイナリをロードでき、Arm64プロセスはArm64バイナリのみロードできるという相互運用の対応表、Arm64ECがx64のソフトウェア規約に従い同一プロセス内でx64コードと混在できること、x64アプリのプロセスにロードされるOSコードの大半がArm64ECであること、link /dump /headersによるバイナリ種別の確認方法について。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  6. Microsoft Learn, Arm64X PE files. Arm64XがArm64とArm64ECのコードを1つのPEに同居させ、x64/Arm64どちらのプロセスにもロードできること、両アーキテクチャのアプリから呼ばれる64bit COMサーバー・プラグイン・注入DLLがArm64Xを必要とする状況として挙げられていることについて。 ↩ ↩2 ↩3

  7. Microsoft Learn, .NET RID Catalog. WindowsのRIDとしてwin-arm64が定義されていること、RIDがNuGetパッケージのプラットフォーム固有資産の振り分けに使われることについて。 ↩ ↩2 ↩3 ↩4

  8. Microsoft Learn, Windows on Arm. Arm64版.NET SDKで実行すると既定でArm64として実行されること、.NET 8以降がネイティブArm64実行をサポートし、既存のx64 .NETアプリはOSのx64エミュレーションで動くことについて。 ↩ ↩2 ↩3

  9. Microsoft Learn, Quickstart: Create a Windows on Arm virtual machine in the Azure portal. AzureポータルでArm64イメージをフィルターしてWindows 11のArm64 VM(推奨サイズD2ps_v5、Ampere Altraベース)を作成できることについて。 ↩ ↩2

  10. Microsoft Learn, Windows 11 Arm ISO files overview. Windows 11 Arm64のISOが配布されており、Arm機上のHyper-VやApple SiliconのMacでVMを作成できること、x64ハードウェアのHyper-VはArm64 VMをサポートしないことについて。 ↩ ↩2

  11. Microsoft Learn, Develop AI applications for Copilot+ PCs. Copilot+ PCが毎秒40兆回超の演算(40+ TOPS)が可能なNPUを搭載したWindows 11ハードウェアの新カテゴリーであることについて。 ↩

  12. Microsoft Learn, Windows on Arm. Windows 10がx86、Windows 11がx64の無修正実行を追加したこと、Copilot+ PCの多くがSnapdragon Xシリーズを採用していること、Arm対応状況の確認サイト(Works on Windows on Arm)とApp Assure Arm Advisory Serviceの存在について。 ↩ ↩2 ↩3 ↩4

  13. Microsoft Learn, How emulation works on Arm - Detecting emulation. エミュレーション下のアプリにはエミュレートされた仮想プロセッサーの情報が見え、GetNativeSystemInfoも互換性のためエミュレートされた値を返すこと、Arm64ホストの検出にはIsWow64Process2やGetMachineTypeAttributesを使うことについて。 ↩

  14. Microsoft Learn, Adjust emulation settings on Arm. exeのプロパティの互換性タブからPrismのエミュレーション設定(既定/安全/厳密/非常に厳密のプリセットと個別設定)を変更できることについて。 ↩

  15. Microsoft Learn, Arm-based Surface devices FAQ. Armデバイスの制限事項(ドライバーはArm用設計が必要、周辺機器はArm64ドライバー次第、OpenGL 3.3超や未対応アンチチートのゲーム、IME等のカスタマイズ系アプリ、ウイルス対策ソフトの個別確認)と、LOBアプリを含むApp Assureによる互換性支援について。 ↩ ↩2 ↩3 ↩4

  16. Microsoft Learn, Process Interoperability. 64bitプロセスが32bit DLLを(逆も)ロードできないこと、アウトプロセスCOMサーバーとRPCによってアーキテクチャ境界を越えて通信できるという定石について。 ↩ ↩2

  17. Microsoft Learn, Install .NET on Windows. Windows 11/10のArm64が.NET 8/9/10のサポート対象であること、Arm機ではArm64版.NETがC:\Program Files\dotnet\に、x64版SDKがC:\Program Files\dotnet\x64\にインストールされ、PATHやDOTNET_ROOTの調整が必要になり得ることについて。 ↩ ↩2

  18. Microsoft Learn, What’s new in .NET Framework. .NET Framework 4.8.1がArm64ネイティブサポートを追加し、Arm64上でエミュレーション実行されるx64コードより性能面で有利であることについて。 ↩

  19. Microsoft Learn, Develop Apps for Windows IoT Enterprise. .NET Framework 4.8.1のネイティブArm64サポートがWindows 11向けであり、4.8.1ランタイムはWindows 10デバイス上のネイティブArm64アプリをサポートしないことについて。 ↩

  20. Microsoft Learn, RuntimeInformation.OSArchitecture under emulation. .NET 7からOSArchitectureがWindows Arm64上のエミュレーションプロセスでもArm64を返すようになったこと(それ以前はX64を返していた)、プロセスのアーキテクチャにはProcessArchitectureを使うべきことについて。 ↩

  21. Microsoft Learn, RuntimeInformation.ProcessArchitecture Property / RuntimeInformation.OSArchitecture Property. 実行中プロセスのアーキテクチャとOS本来のアーキテクチャを取得するAPIについて。 ↩

  22. Microsoft Learn, BadImageFormatException Class. アプリのコンポーネントが異なるプラットフォームを対象としている場合(異アーキテクチャのアセンブリ読み込み)にBadImageFormatExceptionが発生することについて。 ↩

  23. Microsoft Learn, Add Arm support to your Windows app. Arm64ビルドを阻む典型要因(未対応の依存ライブラリ、アーキテクチャ固有コード、カーネルドライバー)と対処、x64依存を残したままArm64ECで再ビルドする選択肢、テスト用のArm実機・VMの入手方法、クロスコンパイルによるビルドとArm環境でのテストの組み合わせについて。 ↩ ↩2 ↩3 ↩4

  24. Microsoft Learn, Visual Studio on Arm-powered devices. Arm64ネイティブのVisual Studioで.NET/C++の開発ができ、Arm64ホストからArm64/x64/x86をターゲットにするMSVCツールセットが提供されることについて。 ↩

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

自社開発のWindowsアプリがウイルス扱いされたら ── Microsoft Defenderの誤検知対応と、性能影響との付き合い方

配布した自社開発のWindowsアプリがMicrosoft Defenderにウイルスとして検知・隔離されたときの正規の対処を整理します。機械学習・クラウド保護・レピュテーションという現代のウイルス対策の仕組み、Microsoftへの誤検知報告(ファイル申請)、隔離からの復...

記事を読む

ネットワークドライブとUNCパスの落とし穴 ── 業務アプリでファイルサーバー(共有フォルダ)を扱う実務

業務アプリからファイルサーバー(共有フォルダ)へ出力・取り込み・監視を行うときの定番トラブルを整理します。ドライブ文字(Z:)がログオンセッション単位でありサービスや昇格プロセスから見えない理由、Windowsサービスの実行アカウントごとに共有側で必要な権限、資格情報とエラ...

記事を読む

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

Arm版Windowsで普通のx64業務アプリは動きますか？
多くの場合は動きます。Windows 11 on Armにはx86/x64アプリを無修正で実行するエミュレーション機能が組み込まれており、Windows 11 24H2以降はPrismという新しいエミュレーターで性能も改善されています。ただしエミュレーションが面倒を見るのはユーザーモードのコードだけで、カーネルモードドライバーや、Explorerなど他プロセスにロードされるシェル拡張・IMEの類はArm64ネイティブが必須です。アプリ本体よりも周辺の依存物で決まる、と考えてください。
x64のexeからArm64のDLLを呼べますか？
呼べません。1つのプロセスの中でx64とArm64のバイナリを混在させることはできず、x64(またはArm64EC)プロセスがロードできるのはx64とArm64ECのバイナリ、Arm64プロセスがロードできるのはArm64のバイナリだけです。逆方向(Arm64のexeからx64のDLL)も同様に不可です。どうしても両対応の1つのDLLが必要な場合は、Arm64とArm64ECのコードを1ファイルに同居させるArm64Xという形式か、プロセスを分けてIPCで連携する構成を使います。
.NETアプリをArm64対応するには何が必要ですか？
.NET 6以降はWindows Arm64を正式サポートしており、RID(ランタイム識別子)win-arm64を指定してpublishするだけでArm64ネイティブの実行ファイルを作れます。純粋なマネージドコードだけならこれでほぼ完了ですが、P/InvokeしているネイティブDLLやネイティブ資産を含むNuGetパッケージがあれば、それぞれのArm64版が存在するかの確認が必要です。.NET Frameworkアプリの場合は4.8.1がWindows 11上でのArm64ネイティブ実行をサポートしています。
Arm版Windowsで動かないのはどんなソフトですか？
カーネルモードドライバーを含むソフトが筆頭です。ドライバーはエミュレーションされないため、VPNクライアント、セキュリティ製品、仮想デバイス、USBドングル認証などはArm64ドライバーがなければ動きません。次に、シェル拡張・IME・支援技術のようにOS側のプロセスへDLLをロードさせるソフト、動的コード生成を禁止しているアプリ、古いOpenGLやアンチチートドライバーに依存するゲームなどが該当します。周辺機器もArm64ドライバーの有無で使えるかが決まります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る