次の方法で共有

パッケージ サポート フレームワークを始めましょう

Package Support Framework は、MSIX コンテナーで実行できるように、既存のデスクトップ アプリケーションに (コードを変更せずに) 修正プログラムを適用するのに役立つオープン ソース キットです。 パッケージ サポート フレームワークは、アプリケーションで最新のランタイム環境のベスト プラクティスに従うのに役立ちます。

この記事では、パッケージ サポート フレームワークの各コンポーネントについて詳しく説明し、それを使用するためのステップ バイ ステップ ガイドを示します。

パッケージ サポート フレームワーク内の内容を理解する

パッケージ サポート フレームワークには、実行可能ファイル、ランタイム マネージャー DLL、および一連のランタイム修正プログラムが含まれています。

パッケージ サポート フレームワーク

プロセスを次に示します。

  1. アプリケーションに適用する修正プログラムを指定する構成ファイルを作成します。
  2. パッケージ サポート フレームワーク (PSF) ランチャー実行可能ファイルを指すパッケージを変更します。

ユーザーがアプリケーションを起動すると、パッケージ サポート フレームワーク起動ツールが実行される最初の実行可能ファイルになります。 構成ファイルが読み取られ、ランタイム修正プログラムとランタイム マネージャー DLL がアプリケーション プロセスに挿入されます。 ランタイム マネージャーは、アプリケーションが MSIX コンテナー内で実行する必要がある場合に修正プログラムを適用します。

パッケージ サポート フレームワークによる DLL インジェクション

手順 1: パッケージ化されたアプリケーションの互換性の問題を特定する

まず、アプリケーションのパッケージを作成します。 次に、インストールして実行し、動作を確認します。 互換性の問題を特定するのに役立つエラー メッセージが表示される場合があります。 プロセス モニターを使用して問題を特定することもできます。 一般的な問題は、作業ディレクトリとプログラム パスのアクセス許可に関するアプリケーションの前提条件に関連しています。

プロセス モニターを使用して問題を特定する

プロセス モニター は、アプリのファイルとレジストリの操作とその結果を監視するための強力なユーティリティです。 これは、アプリケーションの互換性の問題を理解するのに役立ちます。 プロセス モニターを開いた後、フィルター (フィルター > フィルター...) を追加して、アプリケーション実行可能ファイルからのイベントのみを含めます。

ProcMon アプリ フィルター

イベントの一覧が表示されます。 これらのイベントの多くでは、[結果] 列に SUCCESS という単語が表示されます。

ProcMon イベント

必要に応じて、イベントをフィルター処理して、エラーのみを表示できます。

ProcMon 除外成功

ファイルシステム・アクセスの失敗が疑われる場合は、System32/SysWOW64 またはパッケージ・ファイル・パスの下にある失敗したイベントを検索します。 ここでもフィルターが役立ちます。 このリストの一番下から開始し、上にスクロールします。 この一覧の下部に表示されるエラーは、最近発生しました。 "アクセス拒否" や "パス/名前が見つかりません" などの文字列を含むエラーに最も注意を払い、疑わしい内容を無視します。 PSFSample には 2 つの問題があります。 これらの問題は、次の図に示す一覧で確認できます。

ProcMon Config.txt

この画像に表示される最初の問題では、アプリケーションが "C:\Windows\SysWOW64" パスにある "Config.txt" ファイルから読み取りに失敗しています。 アプリケーションがそのパスを直接参照しようとしている可能性は低いです。 ほとんどの場合、相対パスを使用してそのファイルから読み取ろうとしています。既定では、"System32/SysWOW64" はアプリケーションの作業ディレクトリです。 これは、アプリケーションが現在の作業ディレクトリがパッケージ内のどこかに設定されることを想定していることを示しています。 appx 内を見ると、ファイルが実行可能ファイルと同じディレクトリに存在していることがわかります。

アプリ Config.txt

2 番目の問題が次の図に表示されます。

ProcMon Logfile

この問題では、アプリケーションがパッケージ パスに.log ファイルを書き込めなかった。 これは、ファイル リダイレクトの修正が役立つ可能性があることを示唆しています。

手順 2: ランタイム修正プログラムを見つける

PSF には、ファイル リダイレクトの修正など、現在使用できるランタイム修正プログラムが含まれています。

ファイル リダイレクトの修正

ファイル リダイレクトの修正を使用すると、MSIX コンテナーで実行されているアプリケーションからアクセスできないディレクトリ内のデータの書き込みまたは読み取りの試行をリダイレクトできます。

たとえば、アプリケーションがアプリケーションの実行可能ファイルと同じディレクトリにあるログ ファイルに書き込む場合、 ファイル リダイレクトの修正を 使用して、ローカル アプリ データ ストアなどの別の場所にそのログ ファイルを作成できます。

コミュニティからのランタイム修正

GitHub ページへのコミュニティの投稿を確認してください。 他の開発者が自分と同様の問題を解決し、ランタイム修正プログラムを共有している可能性があります。

手順 3: ランタイム修正プログラムを適用する

Windows SDK からいくつかの簡単なツールを使用して、次の手順に従って、既存のランタイム修正プログラムを適用できます。

  • パッケージ レイアウト フォルダーを作成する
  • パッケージ サポート フレームワーク ファイルを取得する
  • それらをパッケージに追加する
  • パッケージ マニフェストを変更する
  • 構成ファイルを作成する

各タスクを実行してみましょう。

パッケージ レイアウト フォルダーを作成する

.msix (または.appx) ファイルが既にある場合は、パッケージのステージング領域として機能するレイアウト フォルダーにその内容をアンパックできます。 MakeAppx ツールを使用することで、コマンドプロンプトからこれを実行できます。SDK のインストールパスに基づいて、Windows 10 PC 上で makeappx.exe ツールを見つけることができます: x86: C:\Program Files (x86)\Windows Kits\10\bin\x86\makeappx.exe, x64: C:\Program Files (x86)\Windows Kits\10\bin\x64\makeappx.exe。

makeappx unpack /p PSFSamplePackage_1.0.60.0_AnyCPU_Debug.msix /d PackageContents

これにより、次のような内容が提供されます。

パッケージ レイアウト

最初に .msix (または.appx) ファイルがない場合は、パッケージ フォルダーとファイルを最初から作成できます。

パッケージ サポート フレームワーク ファイルを取得する

PSF Nuget パッケージを取得するには、スタンドアロンの Nuget コマンド ライン ツールを使用するか、Visual Studio を使用します。

コマンド ライン ツールを使用してパッケージを取得する

次の場所から Nuget コマンド ライン ツールをインストールします: https://www.nuget.org/downloads。 次に、Nuget コマンド ラインから次のコマンドを実行します。

nuget install Microsoft.PackageSupportFramework

または、パッケージ拡張機能の名前を .zip に変更し、解凍することもできます。 必要なすべてのファイルは、/bin フォルダーの下にあります。

Visual Studio を使用してパッケージを取得する

Visual Studio で、ソリューションまたはプロジェクト ノードを右クリックし、[Nuget パッケージの管理] コマンドのいずれかを選択します。 Microsoft.PackageSupportFramework または PSF を検索して、Nuget.org でパッケージを検索します。次に、インストールします。

パッケージ サポート フレームワーク ファイルをパッケージに追加する

必要な 32 ビットおよび 64 ビット PSF DLL と実行可能ファイルをパッケージ ディレクトリに追加します。 ガイドとして次の表を使用します。 また、必要なランタイム修正も含める必要があります。 この例では、ファイル リダイレクトランタイムの修正が必要です。

アプリケーション実行可能ファイルは x64 です アプリケーション実行可能ファイルは x86 です
PSFLauncher64.exe PSFLauncher32.exe
PSFRuntime64.dll PSFRuntime32.dll
PSFRunDll64.exe PSFRunDll32.exe

パッケージのコンテンツは次のようになります。

パッケージ バイナリ

パッケージ マニフェストを変更する

テキスト エディターでパッケージ マニフェストを開き、Executable要素のApplication属性を PSF Launcher 実行可能ファイルの名前に設定します。 ターゲット アプリケーションのアーキテクチャがわかっている場合は、適切なバージョン、PSFLauncher32.exe、または PSFLauncher64.exeを選択します。 そうでない場合は、すべてのケースで PSFLauncher32.exe が機能します。 例を次に示します。

<Package ...>
  ...
  <Applications>
    <Application Id="PSFSample"
                 Executable="PSFLauncher32.exe"
                 EntryPoint="Windows.FullTrustApplication">
      ...
    </Application>
  </Applications>
</Package>

構成ファイルを作成する

config.jsonファイル名を作成し、そのファイルをパッケージのルート フォルダーに保存します。 config.json ファイルの宣言されたアプリ ID を、置き換えた実行可能ファイルを指すよう変更します。 プロセス モニターを使用して得た知識を使用して、作業ディレクトリを設定したり、ファイル リダイレクト修正を使用して、パッケージ相対 "PSFSampleApp" ディレクトリの下にある.log ファイルに読み取り/書き込みをリダイレクトしたりすることもできます。

{
    "applications": [
        {
            "id": "PSFSample",
            "executable": "PSFSampleApp/PSFSample.exe",
            "workingDirectory": "PSFSampleApp/"
        }
    ],
    "processes": [
        {
            "executable": "PSFSample",
            "fixups": [
                {
                    "dll": "FileRedirectionFixup.dll",
                    "config": {
                        "redirectedPaths": {
                            "packageRelative": [
                                {
                                    "base": "PSFSampleApp/",
                                    "patterns": [
                                        ".*\\.log"
                                    ]
                                }
                            ]
                        }
                    }
                }
            ]
        }
    ]
}

config.json スキーマのガイドを次に示します。

配列 鍵 価値
アプリケーション 身分証明書 パッケージ マニフェストのId要素のApplication属性の値を使用します。
アプリケーション 実行可能ファイル 開始する実行可能ファイルへのパッケージ相対パス。 ほとんどの場合、変更する前にパッケージ マニフェスト ファイルからこの値を取得できます。 Executable要素のApplication属性の値です。
アプリケーション 作業ディレクトリ (workingDirectory) (省略可能)起動するアプリケーションの作業ディレクトリとして使用するパッケージ相対パス。 この値を設定しない場合、オペレーティング システムはアプリケーションの作業ディレクトリとして System32 ディレクトリを使用します。
プロセス 実行可能ファイル ほとんどの場合、パスとファイル拡張子を削除して上記で構成した executable の名前になります。
修正 dll 読み込む修正プログラム .msix/.appx のパッケージ相対パス。
修正 設定 (省略可能)fixup dll の動作を制御します。 この値の正確な形式は、修正ごとに異なります。各修正では、この "BLOB" を必要に応じて解釈できるためです。

applications、processes、およびfixupsキーは配列です。 つまり、config.json ファイルを使用して、複数のアプリケーション、プロセス、および修正 DLL を指定できます。

アプリをパッケージ化してテストする

次に、パッケージを作成します。

makeappx pack /d PackageContents /p PSFSamplePackageFixup.msix

次に、それに署名します。

signtool sign /a /v /fd sha256 /f ExportedSigningCertificate.pfx PSFSamplePackageFixup.msix

詳細については、パッケージ署名証明書を作成する方法と、signtool を使用してパッケージに署名する方法を参照してください。

PowerShell を使用して、パッケージをインストールします。

注

最初にパッケージをアンインストールすることを忘れないでください。

powershell Add-AppPackage .\PSFSamplePackageFixup.msix

アプリケーションを実行し、ランタイム修正が適用された動作を観察します。 必要に応じて、診断とパッケージ化の手順を繰り返します。

パッケージ サポート フレームワークが実行されているかどうかを確認する

ランタイム修正プログラムが実行されているかどうかを確認できます。 これを行う方法は、 タスク マネージャー を開き、[ 詳細] をクリックすることです。 パッケージ サポート フレームワークが適用されたアプリを検索し、アプリの詳細を展開して詳細を確認します。 パッケージ サポート フレームワークが実行されていることを確認できる必要があります。

トレースの修正を使用する

パッケージ化されたアプリケーションの互換性の問題を診断する別の手法は、Trace Fixup を使用することです。 この DLL は PSF に含まれており、プロセス モニターと同様に、アプリの動作の詳細な診断ビューを提供します。 これは、アプリケーションの互換性の問題を明らかにするために特別に設計されています。 Trace Fixup を使用するには、DLL をパッケージに追加し、次のフラグメントを config.jsonに追加してから、アプリケーションをパッケージ化してインストールします。

{
    "dll": "TraceFixup.dll",
    "config": {
        "traceLevels": {
            "filesystem": "allFailures"
        }
    }
}

既定では、"予期される" と見なされる可能性があるエラーが Trace Fixup によって除外されます。 たとえば、アプリケーションでは、ファイルが既に存在するかどうかを確認せずに無条件にファイルを削除しようとして、結果が無視される場合があります。 これは、予期しないエラーが除外されるという残念な結果を招くので、上記の例では、ファイルシステム関数からすべてのエラーを受け取ることを選択します。 これは、Config.txt ファイルからの読み取りが失敗し、"ファイルが見つかりません" というメッセージが表示される前からわかっているためです。 これは、頻繁に発生する障害であり、一般的に予期しないものとは見なされません。 実際には、予期しないエラーに対してのみフィルター処理を開始し、それでも特定できない問題がある場合は、すべてのエラーにフォールバックすることをお勧めします。

既定では、Trace Fixup からの出力は、アタッチされたデバッガーに送信されます。 この例では、デバッガーをアタッチせず、代わりに SysInternals の DebugView プログラムを使用してその出力を表示します。 アプリを実行すると、以前と同じエラーが表示され、同じランタイム修正が示されます。

TraceShim ファイルが見つかりません

TraceShim アクセスが拒否されました

ランタイム修正をデバッグし、拡張するか、新しく作成する

Visual Studio を使用して、ランタイム修正のデバッグ、ランタイム修正の拡張、またはゼロからの作成を行うことができます。 成功するには、これらの操作を行う必要があります。

  • パッケージ プロジェクトを追加する
  • ランタイム修正のプロジェクトを追加する
  • PSF Launcherの実行ファイルを起動するプロジェクトを追加する
  • パッケージ 化プロジェクトを構成する

完了すると、ソリューションは次のようになります。

完成したソリューション

この例の各プロジェクトを見てみましょう。

プロジェクト 目的
デスクトップアプリケーションパッケージ このプロジェクトは Windows アプリケーション パッケージ プロジェクト に基づいており、MSIX パッケージを出力します。
ランタイム修正 これは、ランタイム修正として機能する 1 つ以上の置換関数を含む C++ Dynamic-Linked ライブラリ プロジェクトです。
PSFLauncher これは C++ 空のプロジェクトです。 このプロジェクトは、パッケージ サポート フレームワークのランタイム配布可能ファイルを収集する場所です。 実行可能ファイルを出力します。 その実行可能ファイルは、ソリューションを開始するときに最初に実行されます。
WinFormsDesktopApplication このプロジェクトには、デスクトップ アプリケーションのソース コードが含まれています。

これらの種類のプロジェクトをすべて含む完全なサンプルについては、 PSFSample を参照してください。

ソリューションでこれらの各プロジェクトを作成して構成する手順を見てみましょう。

パッケージ ソリューションを作成する

デスクトップ アプリケーション用のソリューションがまだない場合は、Visual Studio で新しい空の ソリューション を作成します。

空のソリューション

また、使用しているアプリケーション プロジェクトを追加することもできます。

パッケージ プロジェクトを追加する

Windows アプリケーション パッケージ プロジェクトがまだない場合は、プロジェクトを作成してソリューションに追加します。

パッケージ プロジェクト テンプレート

Windows アプリケーション パッケージ プロジェクトの詳細については、「 Visual Studio を使用してアプリケーションをパッケージ化する」を参照してください。

ソリューション エクスプローラーで、パッケージ プロジェクトを右クリックし、[編集] を選択し、プロジェクト ファイルの下部に追加します。

<Target Name="PSFRemoveSourceProject" AfterTargets="ExpandProjectReferences" BeforeTargets="_ConvertItems">
<ItemGroup>
  <FilteredNonWapProjProjectOutput Include="@(_FilteredNonWapProjProjectOutput)">
  <SourceProject Condition="'%(_FilteredNonWapProjProjectOutput.SourceProject)'=='<your runtime fix project name goes here>'" />
  </FilteredNonWapProjProjectOutput>
  <_FilteredNonWapProjProjectOutput Remove="@(_FilteredNonWapProjProjectOutput)" />
  <_FilteredNonWapProjProjectOutput Include="@(FilteredNonWapProjProjectOutput)" />
</ItemGroup>
</Target>

ランタイム修正のプロジェクトを追加する

ソリューションに C++ Dynamic-Link ライブラリ (DLL) プロジェクトを追加します。

ランタイム修正ライブラリ

そのプロジェクトを右クリックし、[ プロパティ] を選択します。

プロパティ ページで、[ C++ 言語標準 ] フィールドを見つけて、そのフィールドの横にあるドロップダウン リストで、 ISO C++17 標準 (/std:c++17) オプションを 選択します。

ISO 17 オプション

そのプロジェクトを右クリックし、コンテキスト メニューの [ Nuget パッケージの管理 ] オプションを選択します。 [パッケージ ソース] オプションが [すべて] または [nuget.org] に設定されていることを確認します。

そのフィールドの横にある設定アイコンをクリックします。

PSF* Nuget パッケージを検索し、このプロジェクト用にインストールします。

nuget パッケージ

既存のランタイム修正プログラムをデバッグまたは拡張する場合は、このガイドの「ランタイム修正プログラムの検索」セクションで説明されているガイダンスを使用して取得した ランタイム修正ファイルを 追加します。

まったく新しい修正プログラムを作成する場合は、このプロジェクトにまだ何も追加しないでください。 このガイドの後のセクションで、このプロジェクトに適切なファイルを追加するのを手伝います。 ここでは、ソリューションの設定を続けます。

PSF Launcherの実行ファイルを起動するプロジェクトを追加する

C++ 空の プロジェクト プロジェクトをソリューションに追加します。

空のプロジェクト

前のセクションで説明したのと同じガイダンスを使用して、 PSF Nuget パッケージをこのプロジェクトに追加します。

プロジェクトのプロパティ ページを開き、[ 全般 設定] ページで、アプリケーションのアーキテクチャに応じてターゲット 名 プロパティを PSFLauncher32 または PSFLauncher64 に設定します。

PSF ランチャー リファレンス

ソリューション内のランタイム修正プロジェクトへのプロジェクト参照を追加します。

ランタイム修正リファレンス

参照を右クリックし、[ プロパティ ] ウィンドウでこれらの値を適用します。

プロパティ 価値
ローカルにコピー 正しい
ローカル サテライト アセンブリをコピーする 正しい
参照アセンブリの出力 正しい
リンク ライブラリの依存関係 いいえ
リンク ライブラリの依存関係の入力 いいえ

パッケージ 化プロジェクトを構成する

パッケージ 化プロジェクトで、[ アプリケーション ] フォルダーを右クリックし、[ 参照の追加] を選択します。

プロジェクト参照の追加

PSF ランチャー プロジェクトとデスクトップ アプリケーション プロジェクトを選択し、[ OK] ボタンを選択します。

デスクトップ プロジェクト

注

アプリケーションのソース コードがない場合は、PSF Launcher プロジェクトを選択するだけです。 構成ファイルを作成するときに実行可能ファイルを参照する方法について説明します。

[アプリケーション] ノードで、PSF ランチャー アプリケーションを右クリックし、[エントリ ポイントとして設定] を選択します。

エントリ ポイントを設定する

パッケージ プロジェクトに config.json という名前のファイルを追加し、次の json テキストをコピーしてファイルに貼り付けます。 [パッケージ アクション] プロパティを [コンテンツ] に設定します。

{
    "applications": [
        {
            "id": "",
            "executable": "",
            "workingDirectory": ""
        }
    ],
    "processes": [
        {
            "executable": "",
            "fixups": [
                {
                    "dll": "",
                    "config": {
                    }
                }
            ]
        }
    ]
}

各キーの値を指定します。 次の表を参考にしてください。

配列 鍵 価値
アプリケーション 身分証明書 パッケージ マニフェストのId要素のApplication属性の値を使用します。
アプリケーション 実行可能ファイル 開始する実行可能ファイルへのパッケージ相対パス。 ほとんどの場合、変更する前にパッケージ マニフェスト ファイルからこの値を取得できます。 Executable要素のApplication属性の値です。
アプリケーション 作業ディレクトリ (workingDirectory) (省略可能)起動するアプリケーションの作業ディレクトリとして使用するパッケージ相対パス。 この値を設定しない場合、オペレーティング システムはアプリケーションの作業ディレクトリとして System32 ディレクトリを使用します。
プロセス 実行可能ファイル ほとんどの場合、パスとファイル拡張子を削除して上記で構成した executable の名前になります。
修正 dll 読み込む修正プログラムの DLL へのパッケージ相対パス。
修正 設定 (省略可能)修正 DLL の動作を制御します。 この値の正確な形式は、修正ごとに異なります。各修正では、この "BLOB" を必要に応じて解釈できるためです。

完了すると、 config.json ファイルは次のようになります。

{
  "applications": [
    {
      "id": "DesktopApplication",
      "executable": "DesktopApplication/WinFormsDesktopApplication.exe",
      "workingDirectory": "WinFormsDesktopApplication"
    }
  ],
  "processes": [
    {
      "executable": ".*App.*",
      "fixups": [ { "dll": "RuntimeFix.dll" } ]
    }
  ]
}

注

applications、processes、およびfixupsキーは配列です。 つまり、config.json ファイルを使用して、複数のアプリケーション、プロセス、および修正 DLL を指定できます。

ランタイム修正プログラムをデバッグする

Visual Studio で F5 キーを押してデバッガーを起動します。 最初に起動するのは PSF ランチャー アプリケーションで、ターゲット デスクトップ アプリケーションを起動します。 ターゲット デスクトップ アプリケーションをデバッグするには、 Debug->Attach to Process を選択し、アプリケーション プロセスを選択して、デスクトップ アプリケーション プロセスに手動でアタッチする必要があります。 ネイティブ ランタイム修正 DLL を使用した .NET アプリケーションのデバッグを許可するには、マネージド コードとネイティブ コードの種類 (混合モードデバッグ) を選択します。

これを設定したら、デスクトップ アプリケーション コードとランタイム修正プロジェクトのコード行の横にブレークポイントを設定できます。 アプリケーションにソース コードがない場合は、ランタイム修正プロジェクトのコード行の横にのみブレークポイントを設定できます。

F5 デバッグでは、.msix/.appx パッケージからインストールするのではなく、パッケージ レイアウト フォルダー パスからルース ファイルを展開してアプリケーションを実行するため、通常、レイアウト フォルダーにはインストールされているパッケージ フォルダーと同じセキュリティ制限はありません。 その結果、ランタイム修正を適用する前に、パッケージ パスのアクセス拒否エラーを再現できない場合があります。

この問題に対処するには、F5 ルーズ ファイルの展開ではなく、.msix/.appx パッケージの展開を使用します。 .msix/.appx パッケージ ファイルを作成するには、前述のように Windows SDK の MakeAppx ユーティリティを使用します。 または、Visual Studio 内からアプリケーション プロジェクト ノードを右クリックし、[ストア] -> [アプリ パッケージの作成] を選択します。

Visual Studio のもう 1 つの問題は、デバッガーによって起動された子プロセスにアタッチするためのサポートが組み込まれていないということです。 これにより、ターゲット アプリケーションのスタートアップ パスでロジックをデバッグすることが困難になります。これは、起動後に Visual Studio によって手動でアタッチする必要があります。

この問題に対処するには、子プロセスアタッチをサポートするデバッガーを使用します。 一般に、Just-In-Time (JIT) デバッガーをターゲット アプリケーションにアタッチすることはできません。 これは、ほとんどの JIT 手法では、ImageFileExecutionOptions レジストリ キーを使用して、ターゲット アプリの代わりにデバッガーを起動する必要があるためです。 これにより、ターゲット アプリに FixupRuntime.dll を挿入するために PSFLauncher.exe によって使用される迂回メカニズムが廃止されます。 Windows 用デバッグ ツールに含まれており、 Windows SDK から取得された WinDbg では、子プロセスアタッチがサポートされています。 また、UWP アプリの直接 起動とデバッグもサポートされるようになりました。

ターゲット アプリケーションの起動を子プロセスとしてデバッグするには、 WinDbgを開始します。

windbg.exe -plmPackage PSFSampleWithFixup_1.0.59.0_x86__7s220nvg1hg3m -plmApp PSFSample

WinDbg プロンプトで、子デバッグを有効にして、適切なブレークポイントを設定します。

.childdbg 1
g

(ターゲット アプリケーションが起動してデバッガーに割り込むまで実行)

sxe ld fixup.dll
g

(fixup DLL が読み込まれるまで実行します)

bp ...

注

PLMDebug は、起動時にデバッガーをアプリにアタッチするためにも使用でき、 Windows 用デバッグ ツールにも含まれています。 ただし、WinDbg によって提供される直接サポートよりも、使用が複雑になります。

支援

質問がありますか? MSIX 技術コミュニティ サイトの Package Support Framework の会話スペースでお問い合わせください。