MSIX トラブルシューティング ガイド

このガイドでは、インストール、署名、アプリ インストーラーの配信、不足している依存関係、ランタイム動作に関する最も一般的な MSIX エラーについて説明します。 各セクションには、症状、根本原因、および解決策が含まれています。

デプロイ イベントの完全なログについては、イベント ビューアーを開き、Applications およびサービス ログ → Microsoft → Windows → AppxDeployment-Server → Operational

インストール エラー

0x80070005 — アクセスが拒否されました

現象: Add-AppxPackage またはアプリ インストーラーがエラー コード 0x80070005で失敗する。

対象: Windows 10以降、Windows 11

原因と修正:

アプリが使用中のため、パッケージのインストールがブロックされました

現象: パッケージが使用中であることを示すエラーが表示され、更新または再インストールが失敗します。 イベント ビューアーでは、デプロイ操作が拒否されたことがわかります。

対象: Windows 10以降、Windows 11

修正: 更新する前に、アプリの実行中のすべてのインスタンスを閉じます。 アプリがバックグラウンド サービスであるか、バックグラウンド タスクが登録されている場合は、それらを終了する必要がある場合もあります。

Get-Process -Name "MyApp" | Stop-Process -Force
Add-AppxPackage -Path .\updated-app.msix

エンタープライズ展開の場合は、Intune またはConfiguration Managerを使用してメンテナンス期間中に更新プログラムをスケジュールすることを検討してください。

MinVersion またはアーキテクチャの不一致

Symptom: "このバージョンのWindowsと互換性がないため、パッケージをインストールできませんでした" や "パッケージはこのコンピューターに適用できません" などのエラーでインストールに失敗します。

Applies to: Windows 10 以降

原因と修正:

Add-AppxPackage は成功しますが、[スタート] メニューにアプリがありません

現象: PowerShell は成功を報告しますが、スタート メニューまたはアプリの一覧にアプリが表示されません。

対象: Windows 10以降、Windows 11

一般的な原因:

• ユーザーごとのインストールとマシンごとのインストール: 現在のユーザーに対してのみインストール Add-AppxPackage 。 管理者として実行しているが、別のユーザーのアプリが必要な場合は、代わりに Add-AppxProvisionedPackage を使用します。
• パッケージが登録されているが、タイルがピン留めされていない: アプリはインストールされていますが、[スタート] メニューが更新されていません。 サインアウトしてもう一度サインインするか、[ Settings → Apps]\(アプリの設定 \) をオンにしてインストールを確認します。
• マニフェストにスタート メニュー エントリがない: <Application>のAppxManifest.xml要素に、有効なVisualElementsを持つSquare150x150Logo エントリが含まれていることを確認します。
• パッケージ ファミリ名の重複: 新しいバージョンまたは古いバージョンのアプリが同じパッケージ ファミリ名で既にインストールされている場合、新しいインストールによって自動的に置き換えられる可能性があります。 Get-AppxPackage -Name "YourPackageFamilyName"で確認します。

署名と証明書のエラー

信頼されていない証明書 (0x800B0109)

現象: "証明書チェーンは処理されましたが、信頼プロバイダーによって信頼されていないルート証明書で終了しました" というエラー 0x800B0109 でインストールが失敗します。

適用対象: Windows 10、Windows 11以降

原因: パッケージの署名に使用される証明書が、デバイスの信頼された証明書ストアにありません。 これは、開発に自己署名証明書を使用する場合に一般的です。

修正: 署名証明書をデバイスの ローカル コンピューター→信頼されたユーザー ストアにインポートします (現在のユーザー ストアではなく、アプリ インストーラーはコンピューター ストアのみをチェックします)。

# Export the certificate from the package first (if needed)
$cert = (Get-AuthenticodeSignature -FilePath .\app.msix).SignerCertificate
Export-Certificate -Cert $cert -FilePath .\app-cert.cer

# Import into Trusted People (requires administrator rights)
Import-Certificate -FilePath .\app-cert.cer -CertStoreLocation Cert:\LocalMachine\TrustedPeople

運用アプリの場合は、信頼された CA または Azure Artifact Signing (旧称 Trusted Signing) によって発行された証明書を使用します。この証明書は、Microsoft ID 検証ルート証明機関にチェーンされており、Windows 10 バージョン 1809 以降および Windows 11 で既定で信頼されています。

Publisher名の不一致 (0x8007000B、イベント ID 150)

Symptom: SignTool が で失敗し、イベント ビューアー (AppxPackagingOM 操作ログ) に Event ID 150

error 0x8007000B: The app manifest publisher name (CN=Contoso) must match
the subject name of the signing certificate (CN=Contoso, C=US).

適用対象: Windows 10以降、Windows 11

Cause: Publisher の AppxManifest.xml 属性は、署名証明書の subject name と完全に一致する必要があります。これには、すべての識別名フィールドが同じ順序で含まれます。

修正:

1. 証明書から正確なサブジェクト名を取得します。

   (Get-Item Cert:\CurrentUser\My\THUMBPRINT).Subject
   # Example output: CN=Contoso, C=US
   

2. 正確に一致するように AppxManifest.xml を更新します。

   <Identity Name="Contoso.MyApp"
             Publisher="CN=Contoso, C=US"
             ... />
   

3. MakeAppx.exeを使用して再パッケージ化し、再署名します。

アプリ インストーラーと Web 配信エラー

.appinstaller ファイルのスキーマ バージョンの不一致

現象: アプリ インストーラーは、多くの場合、無効なファイルまたはサポートされていないスキーマに関する一般的なエラーが発生して、 .appinstaller ファイルの解析または処理に失敗します。

Applies to: Windows 10 以降 (バージョンに依存 — 表を参照)

Cause: Uri ルート要素の <AppInstaller> 属性は、インストールされているバージョンのWindowsがサポートしていないスキーマ バージョンを指定します。

リリース別 WindowsのSchema バージョン:

修正: .appinstaller ファイル内のスキーマ URI を、サポートされている最小 OS で必要な最小バージョンに設定します。

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller Uri="https://example.com/app.appinstaller"
              Version="1.0.0.0"
              xmlns="http://schemas.microsoft.com/appx/appinstaller/2017">

古いWindows 10バージョンをサポートする必要がある場合は、最新のスキーマ バージョンを使用しないでください。

MIME タイプが正しくないか、Content-Length が欠落しているファイル

現象: HTTP/HTTPS エンドポイントからインストールすると、アプリ インストーラーが失敗します。 このエラーは、 0x80072F76 ("不明なエラー") や "アプリのインストールに失敗しました" などの一般的なエラーです。

Applies to: Windows 10 以降

原因: Web サーバーは、 .msix、 .msixbundle、または .appinstaller ファイルに正しくない Content-Type ヘッダーを指定して提供しているか、 Content-Length ヘッダーを省略しています。

修正: 正しい MIME の種類で MSIX 関連のファイルを提供するように Web サーバーを構成します。

また、すべての応答に有効な Content-Length ヘッダーが含まれていることを確認します。これは、 GET 要求と HEAD 要求の両方に適用されます。

IIS の場合は、 web.configに MIME の種類のマッピングを追加します。 Azure Static Web Appsまたは GitHub Pages の場合、これらの拡張機能の MIME の種類には、明示的な構成またはカスタム ホスティング ソリューションが必要な場合があります。

依存関係に不足がある

フレームワーク パッケージがインストールされていない (VCLibs、.NET、Windows アプリ SDK)

Symptom: アプリは正常にインストールされますが、起動時にクラッシュするか、Microsoft.VCLibs、Microsoft.WindowsAppRuntime、Microsoft.NET.Native などのパッケージ ファミリ名を参照する依存関係エラーでインストールが失敗します。

対象: Windows 10以降、Windows 11

一般的なフレームワークとそれらを取得する場所:

開発用の修正: Add-AppxPackage を使用してローカルにインストールする場合は、最初に -DependencyPackages パラメーターを追加するか、フレームワーク パッケージをインストールします。

# Install VCLibs dependency first
Add-AppxPackage -Path .\Microsoft.VCLibs.x64.14.00.Desktop.appx

# Then install your app
Add-AppxPackage -Path .\MyApp.msix

配布の修正: ストアの外部に配布する場合は、.appinstallerの<Dependencies> ファイルにフレームワーク パッケージを含めます。

<Dependencies>
  <Package Name="Microsoft.VCLibs.140.00.UWPDesktop"
           Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
           Version="14.0.30704.0"
           Uri="https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx"
           ProcessorArchitecture="x64"/>
</Dependencies>

CI/CD で SignTool が見つかりません

Symptom: CI/CD パイプライン (GitHub Actions、Azure DevOps) は、'signtool' is not recognized as an internal or external command や SignTool.exe: not found などのエラーで失敗します。

Applies to: Windows 10以降、Windows 11（署名用マシン）

Cause: SignTool は Windows SDK の一部であり、既定では標準の CI ランナー イメージには含まれていません。

Fixes:

Option 1 — パイプラインに Windows SDK をインストールします (GitHub Actions):

- name: Install Windows SDK
  run: |
    winget install --id Microsoft.WindowsSDK.10.0.22621 --accept-source-agreements --accept-package-agreements

オプション 2 —WinApp CLI を使用して 下さい(MSIX 署名のための最も簡単な):

- name: Install WinApp CLI
  run: winget install -e --id Microsoft.WinAppCLI --source winget --accept-source-agreements
- name: Sign MSIX
  run: winapp sign output\MyApp.msix --cert ${{ secrets.CERT_THUMBPRINT }}

Option 3 — Azure成果物署名を使用します (運用環境に推奨):

- name: Sign with Azure Artifact Signing
  uses: azure/trusted-signing-action@v0
  with:
    azure-tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    azure-client-id: ${{ secrets.AZURE_CLIENT_ID }}
    azure-client-secret: ${{ secrets.AZURE_CLIENT_SECRET }}
    endpoint: ${{ secrets.AZURE_ARTIFACT_SIGNING_ENDPOINT }}
    trusted-signing-account-name: ${{ secrets.AZURE_CODE_SIGNING_NAME }}
    certificate-profile-name: ${{ secrets.AZURE_CERT_PROFILE_NAME }}
    files-folder: ${{ github.workspace }}\output
    files-folder-filter: msix

CI/CD 署名のセットアップの完全なチュートリアルについては、「 MSIX パッケージへの署名 - エンド ツー エンド ガイド」を参照してください。

ランタイムと仮想化の動作

MSIX パッケージは、軽量アプリ コンテナー内で実行されます。 バグと思われるいくつかの動作は、実際には設計上のものであり、コンテナーはシステムの残りの部分を保護するためにファイルとレジストリの操作をインターセプトします。

ファイルの書き込みが消えそうな理由 (VFS ファイルリダイレクト)

現象: アプリは実行時に C:\Program Files\MyApp\config.ini のようなパスにファイルを書き込みますが、ファイルはそこに表示されません。 アプリは値を正しく読み取りますが、他のプロセスやユーザーには表示されません。

Applies to: Windows 10以降、Windows 11

説明: MSIX は 仮想ファイル システム (VFS) リダイレクトを 使用します。 保護されたシステム パスへの書き込みは、ユーザーごとのコンテナーに自動的にリダイレクトされます。

%LocalAppData%\Packages\<PackageFamilyName>\LocalCache\Local\VFS\

これは仕様です。MSIX アプリが共有システムの場所を変更するのを防ぎ、クリーン アンインストールをサポートします。

オプション:

• 代わりにアプリ データ フォルダーを使用します。保持する必要があるユーザーごとのデータに対して、 ApplicationData.Current.LocalFolder (WinRT) または %LocalAppData%\Packages\<PFN>\LocalState\ に書き込みます。
• デバイス間でローミングする必要があるデータには、AppData\Roamingを使用してください。
• VFS コンテナーを調べて 、リダイレクトされたファイルを確認します。 %LocalAppData%\Packages\<PackageFamilyName>\LocalCache\

仮想化されるパスの詳細については、「 MSIX コンテナーでのランタイムの問題のトラブルシューティング」を参照してください。

レジストリの書き込みが消えるように見える理由 (レジストリの仮想化)

現象: アプリは実行時に HKEY_LOCAL_MACHINE\Software\MyApp\ に書き込みますが、値が他のプロセスに表示されないか、再インストールしても存続します。

Applies to: Windows 10以降、Windows 11

説明: MSIX は、 HKLM\Software への書き込みをインターセプトし、システムの残りの部分から分離されたパッケージごとのレジストリ ハイブにリダイレクトします。 アンインストール時に、ハイブが削除されます。

オプション:

• ユーザーごとの設定を HKEY_CURRENT_USER\Software\<AppName> に書き込みます。これらは仮想化 されず 、永続化されません。
• 構造化設定ストレージには、Windows ApplicationData API を使用します。
• AppxManifest.xml <Extensions> / メカニズムを使用して、<com:Extension>内のユーザーまたはプロセス間で共有する必要があるレジストリ エントリを宣言します。

MSIX コンテナーの動作の詳細については、「パッケージ 化されたデスクトップ アプリが Windowsでどのように実行されるかを理解する」を参照してください。

WINDOWS 10 MSIX の制限事項

一部の MSIX 機能には、Windows 11または特定のWindows 10 バージョンが必要です。 Windows 10デバイスに展開する場合は、次の点に注意してください。

Windows 10バージョン 2004 (ビルド 19041) 以降が必要な機能

Windows 11が必要な機能

バージョン 1709 より古いWindows 10 デバイス

MSIX は、1709 (Fall Creators Update) より前のWindows 10バージョンではネイティブにサポートされていません。 MSIX パッケージをこれらのデバイスに展開するには、MSIX Core を使用します。これは、下位レベルのWindows 10 バージョンの互換性レイヤーを提供します。

マニフェスト拡張機能

一部の AppxManifest.xml 名前空間拡張機能はWindows 11専用です。 Windows 10を対象とするパッケージで宣言すると、パッケージ化中にスキーマ検証が失敗したり、インストール中に拒否されたりする可能性があります。 各拡張機能ごとに一覧表示されているアプリ パッケージ マニフェスト スキーマ リファレンスをMinOSVersion

デバッグのヒント

特定のWindows 10 ビルドで使用できる MSIX 機能を確認するには、OS バージョンごとの機能の可用性の一覧を示す MSIX の機能とサポートされているプラットフォーム ページを確認します。

関連するリソース

• MSIX パッケージへの署名の概要
• MSIX パッケージに署名する - エンド ツー エンド ガイド
• SignTool の既知の問題とトラブルシューティング
• アプリ インストーラーに関する問題のトラブルシューティング
• MSIX コンテナーでのランタイムの問題のトラブルシューティング
• Windows アプリのパッケージ化、展開、クエリのトラブルシューティング