次の方法で共有

Windows アプリ認定キットのテスト

  • [アーティクル]

デスクトップ アプリを認定するためのテストの詳細を次に示します。 詳細については、「 Windows アプリ認定キットの使用」を参照してください。

クリーンリバーシブルインストール

アプリをインストールしてアンインストールし、残りのファイルとレジストリ エントリを確認します。

  • 背景
    • クリーンで元に戻せるインストールにより、ユーザーはアプリを展開および削除できます。 このテストに合格するには、アプリで次の操作を行う必要があります。
      • アプリは、アプリをインストールまたはアンインストールした直後にシステムの再起動を強制しません。 アプリのインストールまたはアンインストール プロセスでは、完了後すぐにシステムを再起動する必要はありません。 システムを再起動する必要がある場合、ユーザーは都合の良い方法でシステムを再起動できる必要があります。
      • このアプリは、8.3 個の短いファイル名 (SFN) に依存していません。 アプリのインストールおよびアンインストール プロセスでは、長いファイル名とフォルダー パスを使用できる必要があります。
      • アプリでサイレント インストール/アンインストールがブロックされない
      • アプリは、システム レジストリに必要なエントリを作成します。 Windows インベントリ ツールとテレメトリ ツールには、インストールされているアプリに関する完全な情報が必要です。 アプリインストーラーは、検出とアンインストールを成功させるために正しいレジストリ エントリを作成する必要があります。
    • MSI ベースのインストーラーを使用している場合、MSI によって以下のレジストリ エントリが自動的に作成されます。 MSI インストーラーを使用していない場合、インストール モジュールはインストール時に次のレジストリ エントリを作成する必要があります。
      • DisplayName
      • InstallLocation
      • Publisher
      • UninstallString
      • VersionMajor または MajorVersion
      • VersionMinor または MinorVersion
    • アプリは、[プログラムの追加と削除] ですべてのエントリを削除する必要があります。
  • テストの詳細
    • このテストでは、アプリのインストールプロセスとアンインストールプロセスで必要な動作を確認します。
  • 修正措置
    • 上記の要件に照らして、アプリの設計と動作を確認します。

正しいフォルダーテストにインストールする

アプリがプログラムとデータ ファイルを正しいフォルダーに書き込むかどうかを確認します。

  • 背景
    • アプリは、ユーザーのデータと設定を承認されていないアクセスから保護しながら、必要なデータと設定にアクセスできるように、ユーザー システムとユーザーごとのフォルダーを正しく行う必要があります。
  • プログラム ファイル フォルダー
    • アプリは、既定で Program Files フォルダーにインストールする必要があります (ネイティブ 32 ビットおよび 64 ビット アプリの場合は %ProgramFiles%、x64 で実行されている 32 ビット アプリの場合は %ProgramFiles(x86)%)。
    • メモ： このフォルダーに対して構成されたセキュリティアクセス許可のため、アプリはユーザー データまたはアプリ データを Program Files フォルダーに格納しないでください。
    • Windows システム フォルダーの ACL では、管理者アカウントのみが読み取りと書き込みを行うことができます。 その結果、標準ユーザー アカウントはこれらのフォルダーにアクセスできなくなります。 ただし、ファイル仮想化を使用すると、通常は管理者のみが書き込み可能なシステムの場所に、構成ファイルなどのファイルを格納できます。 このような状況で標準ユーザーとしてプログラムを実行すると、必要なファイルにアクセスできない場合にエラーが発生する可能性があります。
    • アプリでは 、既知のフォルダー を使用して、データに確実にアクセスできるようにする必要があります。
    • メモ： Windows では、アプリの互換性を向上させ、Windows でアプリを標準ユーザーとして実行するときの問題を排除するためのファイル仮想化が提供されます。 アプリは、将来のバージョンの Windows に存在する仮想化に依存しないようにする必要があります。
  • ユーザー固有のアプリ データ フォルダー
    • "マシンごとの" インストールでは、インストール中にアプリがユーザー固有のデータを書き込む必要はありません。 ユーザー固有のインストール データは、ユーザーが初めてアプリを起動するときにのみ書き込む必要があります。 これは、インストール時にデータを格納する適切なユーザーの場所がないためです。 インストール後にコンピューター レベルで既定の関連付け動作を変更しようとすると、アプリが失敗します。 代わりに、ユーザー単位のレベルで既定値を要求する必要があります。これにより、複数のユーザーが互いの既定値を上書きできなくなります。
    • コンピューターの他のユーザーと共有しないように、特定のユーザー専用のすべてのアプリ データを Users\username>\<AppData に格納する必要があります。
    • コンピューター上のユーザー間で共有する必要があるすべてのアプリ データは、ProgramData 内に格納する必要があります。
  • その他のシステム フォルダーとレジストリ キー
    • アプリは、Windows ディレクトリまたはサブディレクトリに直接書き込むべきではありません。 これらのディレクトリにフォントやドライバーなどのファイルをインストールするには、正しい方法を使用します。
    • 次の 1 つ以上の場所にエントリを追加するなどして、起動時にアプリを自動的に起動しないようにする必要があります。
      • レジストリの実行キー HKLM と、またはソフトウェア\Microsoft\Windows\CurrentVersion の HKCU
      • レジストリ実行キー HKLM、またはソフトウェア\Wow6432Node\Microsoft\windows\CurrentVersion の HKCU
      • [スタート] メニュー [すべて] [プログラムの > スタートアップ]
  • テストの詳細
    • このテストでは、Windows が提供するファイル システム内の特定の場所をアプリが使用して、プログラムとソフトウェア コンポーネント、共有アプリ データ、およびユーザーに固有のアプリ データを格納することを確認します。
  • 問題への対応
    • アプリでシステムのフォルダーがどのように使用されているかを確認し、正しく使用されていることを確認します。
  • 例外と権利放棄
    • デスクトップ アプリがグローバル アセンブリ キャッシュ (GAC) に書き込むには放棄が必要です (.NET アプリでは、アセンブリの依存関係を非公開にし、アセンブリの共有が明示的に必要でない限り、アプリのディレクトリに格納する必要があります)。
    • [プログラム ファイル] フォルダーへのインストールは、SW ロゴを実現するためのデスクトップ SW パッケージの要件ではなく、SW Fundamentals カテゴリの下に限られます。

デジタル署名されたファイル テスト

実行可能ファイルとデバイス ドライバーをテストして、有効なデジタル署名があることを確認します。

  • 背景
    • デジタル署名されたファイルを使用すると、ファイルが本物であることを確認し、ファイルが改ざんされているかどうかを検出できます。
    • カーネル モードのコード署名の適用は、コード整合性 (CI) とも呼ばれる Windows 機能です。 CI は、メモリに読み込まれるたびにファイルの整合性を確認することで、Windows のセキュリティを向上させます。 CI は、悪意のあるコードがシステム バイナリ ファイルを変更したかどうかを検出し、カーネル モジュールの署名が正しく検証されない場合に診断およびシステム監査ログ イベントを生成します。
    • アプリに昇格されたアクセス許可が必要な場合、昇格プロンプトには、昇格されたアクセスを要求している実行可能ファイルに関するコンテキスト情報が表示されます。 アプリが Authenticode 署名されているかどうかに応じて、ユーザーに同意プロンプトまたは資格情報プロンプトが表示される場合があります。
    • 厳密な名前を使用すると、秘密キーをセキュリティで保護している限り、サード パーティがコードをスプーフィングできなくなります。 .NET Frameworkは、アセンブリを読み込むか GAC にインストールするときにデジタル署名を検証します。 秘密キーにアクセスしないと、悪意のあるユーザーがコードを変更してもう一度署名することはできません。
  • テストの詳細
    • .exe、.dll、.ocx、.sys、.cpl、.drv、.scr のファイル拡張子を持つファイルなど、すべての実行可能ファイルは Authenticode 証明書で署名する必要があります。
    • アプリによってインストールされるすべてのカーネル モード ドライバーには、WHQL または DRS プログラムによって取得された Microsoft 署名が必要です。 すべてのファイル システム フィルター ドライバーは WHQL 署名されている必要があります。
  • 修正措置
    • アプリの実行可能ファイルに署名します。
    • makecert.exeを使用して証明書を生成するか、VeriSign、Thawte、Microsoft CA などの商用証明機関 (CA) からコード署名キーを取得します。
  • 例外と権利放棄
    • 権利放棄は、署名されていないサードパーティの再頒布可能パッケージに対してのみ考慮されます。 この権利放棄を許可するには、再頒布可能パッケージの署名付きバージョンを要求する通信証明が必要です。
    • ドライバーは Windows ハードウェア認定で認定されている必要があるため、デバイス付加価値ソフトウェア パッケージはカーネル モード ドライバー認定から除外されます。

x64 Windows テストのサポート

アプリをテストして、インストール先のプラットフォーム アーキテクチャ用に.exeがビルドされていることを確認します。

  • 背景
    • 実行可能ファイルは、インストールされているプロセッサ アーキテクチャ用にビルドする必要があります。 一部の実行可能ファイルは、別のプロセッサ アーキテクチャで実行される可能性がありますが、これは信頼できません。
    • アーキテクチャの互換性は重要です。32 ビット プロセスでは 64 ビット DLL を読み込めず、64 ビット プロセスでは 32 ビット DLL を読み込むことができないためです。 同様に、64 ビット バージョンの Windows では、16 ビット Windows ベースのアプリケーションの実行はサポートされていません。ハンドルには 64 ビット Windows 上で 32 個の重要なビットがあるため、16 ビット アプリケーションに渡すことができません。 したがって、16 ビット アプリケーションを起動しようとすると、64 ビット バージョンの Windows で失敗します。
    • 32 ビット デバイス ドライバーは、64 ビット バージョンの Windows では実行できないため、64 ビット アーキテクチャに移植する必要があります。
    • ユーザー モード アプリケーションの場合、64 ビット Windows には WOW64 が含まれています。これにより、32 ビット Windows アプリケーションは、パフォーマンスが低下するにもかかわらず、64 ビット Windows を実行するシステムで実行できます。 デバイス ドライバーに同等の変換レイヤーは存在しません。
    • 64 ビット バージョンの Windows との互換性を維持するには、アプリで 64 ビットをネイティブにサポートするか、少なくとも 32 ビット Windows ベースのアプリを 64 ビット システムでシームレスに実行する必要があります。
      • アプリとそのインストーラーには、16 ビット コードを含めたり、16 ビット コンポーネントに依存したりすることはできません。
      • アプリのセットアップでは、64 ビット バージョンの Windows で適切なドライバーとコンポーネントを検出してインストールする必要があります。
      • シェル プラグインは、64 ビット バージョンの Windows で実行する必要があります。
      • WoW64 エミュレーターで実行されるアプリは、Wow64 仮想化メカニズムをバイパスしないようにしてください。 アプリが WoW64 エミュレーターで実行されているかどうかを検出する必要がある特定のシナリオがある場合は、 IsWow64Process を呼び出して実行する必要があります。
  • テストの詳細
    • アプリでは、16 ビット バイナリをインストールしないでください。 アプリは、64 ビット コンピューターで実行することが想定されている場合は、32 ビット カーネル モード ドライバーをインストールしないでください。
  • 是正措置
    • インストールするプロセッサ アーキテクチャ用の実行可能ファイルとドライバーをビルドします。

OS バージョン チェック テスト

アプリが実行されている Windows のバージョンを確認する方法をテストします。

  • 背景
    • アプリは、将来のバージョンの Windows との互換性を確保するために、必要なバージョン以上のバージョンをテストして OS バージョンをチェックします。
  • テストの詳細
    • さまざまなバージョンの Windows でのアプリの実行をシミュレートして、それがどのように反応するかを確認します。
  • 問題への対応
    • 現在のバージョンがアプリ、サービス、またはドライバーに必要なバージョン以上であるかどうかをテストして、正しいバージョンの Windows をテストします。
    • ドライバー インストーラーとアンインストール モジュールは、OS バージョンをチェックしないでください。
  • 例外と権利放棄
    • 権利放棄は、次の条件を満たすアプリに対して考慮されます (デスクトップ アプリ認定にのみ適用されます)
      • Windows XP、Windows Vista、Windows 7 で実行され、OS バージョンをチェックして、特定のオペレーティング システムにインストールするコンポーネントを決定する必要がある 1 つのパッケージとして配信されるアプリ。
      • 承認された API 呼び出しのみを使用して OS の最小バージョンのみをチェックするアプリ (インストール時のみ、実行時ではない) と、アプリ マニフェストの最小バージョン要件を必要に応じて一覧表示するアプリ。
      • ウイルス対策アプリやファイアウォール アプリなどのセキュリティ アプリ、デフラグ ユーティリティやバックアップ アプリなどのシステム ユーティリティ、承認された API 呼び出しのみを使用して OS バージョンをチェックするツール診断。

ユーザー アカウント制御 (UAC) テスト

アプリをテストして、実行するために不必要に昇格されたアクセス許可が必要ないことを確認します。

  • 背景
    • ユーザーが管理者である場合にのみ動作またはインストールするアプリは、ユーザーに不必要に昇格されたアクセス許可を持つアプリの実行を強制します。これにより、マルウェアがユーザーのコンピューターに入る可能性があります。
    • ユーザーが常に昇格されたアクセス トークンを使用してアプリを実行するように強制されると、アプリは、詐欺的または悪意のあるコードのエントリ ポイントとしてサーバーに接続できます。 このマルウェアは、オペレーティング システムを簡単に変更したり、他のユーザーに影響を与えたりする可能性があります。 管理者はアプリをインストールし、コンピューター上で任意のアプリまたはスクリプトを実行できるため、完全な管理者アクセス権を持つユーザーを制御することはほとんど不可能です。 IT マネージャーは、ユーザーが標準ユーザーとしてログオンする "標準デスクトップ" を作成する方法を常に模索しています。 標準デスクトップは、ヘルプ デスクのコストを大幅に削減し、IT オーバーヘッドを削減します。
    • ほとんどのアプリケーションでは、実行時に管理者特権は必要ありません。 標準ユーザー アカウントは、それらを実行できる必要があります。 Windows アプリには、アプリの実行に必要な特権を OS に通知する実行レベルを定義するためのマニフェスト (埋め込みまたは外部) が必要です。 アプリ マニフェストは、.dll ファイルではなく、.exe ファイルにのみ適用されます。 ユーザー アカウント制御 (UAC) は、プロセスの作成時に DLL を検査しません。 UAC ルールは Microsoft サービスには適用されません。 アプリ マニフェストは埋め込みでも外部でもかまいません。
    • マニフェストを作成するには、.exe.manifest という名前 <app_name> ファイルを作成し、EXE と同じディレクトリに格納します。 アプリに内部マニフェストがある場合、外部マニフェストはすべて無視されることに注意してください。
      • たとえば、 <requestedExecutionLevel level=""asInvoker | highestAvailable | requireAdministrator"" uiAccess=""true|false""/>
      • アプリのメイン プロセスは、標準ユーザー (asInvoker) として実行する必要があります。 管理機能は、管理特権で実行される別のプロセスに移動する必要があります。
      • 昇格された特権を必要とするユーザー向けアプリは、Authenticode 署名されている必要があります。
  • テストの詳細
    • すべてのユーザー向け exes は asInvoker 属性でマークする必要があります。 highestAvailable または requireAdministrator としてマークされている場合は、正しく authenticode 署名されている必要があります。 アプリ exe に uiAccess 属性を true に設定しないでください。 サービスとして実行されるすべての exe は、この特定のチェックから除外されます。
  • 問題への対応
    • アプリのマニフェスト ファイルで、正しいエントリとアクセス許可レベルを確認します。
  • 例外と権利放棄
    • 昇格された特権 (requireAdministrator または highestAvailable) を使用してメイン プロセスを実行するアプリでは、権利放棄が必要です。 メイン プロセスは、ユーザーのエントリ ポイントをアプリに提供するプロセスです。
    • 権利放棄は、次のシナリオで考慮されます。
      • 実行レベルが highestAvailable、 requireAdministrator、またはその両方に設定されている管理ツールまたはシステム ツール。
      • ユーザー インターフェイス特権の分離 (UIPI) をバイパスするには、アクセシビリティまたは UI オートメーション フレームワーク アプリのみが uiAccess フラグを TRUE に設定します。 アプリの使用率を適切に開始するには、このフラグは Authenticode 署名済みである必要があり、Program Files などのファイル システム内の保護された場所に存在する必要があります。

システム再起動マネージャー メッセージに準拠する

システムのシャットダウンと再起動メッセージに対するアプリの応答方法をテストします。

  • 背景
    • ユーザーに応答性の高いシャットダウンまたは電源オフ エクスペリエンスを提供するために、システムがシャットダウンしていることを通知されたら、アプリはできるだけ早く終了する必要があります。
    • 重大なシャットダウンでは、false を WM_QUERYENDSESSION に返すアプリは WM_ENDSESSION 送信され、閉じられますが、WM_QUERYENDSESSIONに応答してタイムアウトしたアプリは強制的に終了されます。
  • テストの詳細
    • アプリがメッセージのシャットダウンと終了にどのように応答するかを調べます。
  • 問題への対応
    • アプリがこのテストに失敗した場合は、次の Windows メッセージの処理方法を確認します。
      • LPARAM = ENDSESSION_CLOSEAPP(0x1) を使用したWM_QUERYENDSESSION: デスクトップ アプリは、再起動の準備としてすぐに応答 (TRUE) する必要があります。 コンソール アプリは 、SetConsoleCtrlHandler を呼び出してシャットダウン通知を受け取ることができます。 サービスは RegisterServiceCtrlHandlerEx を呼び出して、ハンドラー ルーチンでシャットダウン通知を受け取ることができます。
      • LPARAM = ENDSESSION_CLOSEAPP(0x1 を使用したWM_ENDSESSION): アプリは 30 秒以内に 0 の値を返し、シャットダウンする必要があります。 少なくとも、アプリはユーザー データを保存して準備し、再起動後に必要な情報を示す必要があります。
    • CTRL_C_EVENT通知を受け取るコンソール アプリは、直ちにシャットダウンする必要があります。 ドライバーは、システムのシャットダウン イベントを拒否することはできません。
    • メモ： 中断できない操作のためにシャットダウンをブロックする必要があるアプリでは、 ShutdownBlockReasonCreate を使用して、理由を説明する文字列をユーザーに登録する必要があります。 操作が完了したら、アプリは ShutdownBlockReasonDestroy を呼び出して、システムをシャットダウンできることを示す必要があります。

セーフ モード テスト

ドライバーまたはサービスがセーフ モードで起動するように構成されているかどうかをテストします。

  • 背景
    • セーフ モードを使用すると、ユーザーは Windows に関する問題を診断してトラブルシューティングできます。 オペレーティング システムの基本的な操作に必要なドライバーとサービス、または診断および回復サービスを提供するサービスのみをセーフ モードで読み込む必要があります。 セーフ モードで他のファイルを読み込むと、オペレーティング システムに関する問題のトラブルシューティングがより困難になります。
    • 既定では、Windows にプレインストールされているドライバーとサービスのみがセーフ モードで起動します。 他のすべてのドライバーとサービスは、システムが基本的な操作または診断と回復のために必要とする場合を除き、無効にする必要があります。
  • テストの詳細
    • アプリによってインストールされたドライバーは、セーフ モードで読み込むためのマークを付けないようにしてください。
  • 問題への対応
    • ドライバーまたはサービスをセーフ モードで起動しない場合は、レジストリ キーからアプリのエントリを削除します。
  • 例外と免除
    • セーフ モードで起動する必要があるドライバーとサービスは、認定を受ける権利放棄が必要です。 権利放棄要求には、SafeBoot レジストリ キーに追加する各ドライバーとサービスを含め、ドライバーまたはサービスをセーフ モードで実行する必要がある技術的な理由について説明する必要があります。 アプリ インストーラーは、このようなすべてのドライバーとサービスを次のレジストリ キーに登録する必要があります。
      • HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal
      • HKLM/System/CurrentControlSet/Control/SafeBoot/Network
  • メモ： セーフ モードで起動するドライバーとサービスをテストして、エラーなしでセーフ モードで機能することを確認する必要があります。

マルチユーザー セッション テスト

複数のセッションで同時に実行する場合のアプリの動作をテストします。

  • 背景
    • Windows ユーザーは、同時セッションを実行できる必要があります。 アプリは、ローカルまたはリモートで複数のセッションで実行する場合、アプリの通常の機能が悪影響を受けないようにする必要があります。 アプリ設定とデータ ファイルはユーザー固有であり、ユーザーのプライバシーと設定はユーザーのセッションに制限する必要があります。
  • テストの詳細
    • アプリの複数の同時実行インスタンスを実行して、次のテストを行います。
      • 同時に実行されているアプリの複数のインスタンスは、互いに分離されます。
    • これは、あるインスタンスのユーザー データが別のインスタンスに表示されないことを意味します。 アクティブでないユーザー セッションのサウンドは、アクティブなユーザー セッションでは聞こえないはずです。 複数のアプリ インスタンスが共有リソースを使用する場合、アプリは競合がないことを確認する必要があります。
      • アプリが複数のユーザーに対してインストールされている場合は、正しいフォルダーとレジストリの場所にデータが格納されます。
      • アプリは、ローカル アクセスとリモート アクセスの両方に対して複数のユーザー セッション (高速ユーザー切り替え) で実行できます。
    • これを確認するには、アプリの既存のインスタンスに対して他のターミナル サービス (TS) セッションをチェックする必要があります。 アプリが複数のユーザー セッションまたはリモート アクセスをサポートしていない場合は、そのようなセッションから起動されたときに、ユーザーに対してこれを明確に言う必要があります。
  • 是正措置
    • アプリがシステム全体のデータ ファイルや設定をユーザー固有のデータ ストア (ユーザー プロファイルや HKCU など) に格納していないことを確認します。 その場合、その情報は他のユーザーが使用できなくなります。
    • アプリでは、インストール時にシステム全体の構成ファイルとデータ ファイルをインストールし、ユーザーが実行したときにインストール後にユーザー固有のファイルと設定を作成する必要があります。
    • アプリで複数の同時セッション (ローカルまたはリモート) がブロックされないようにします。 アプリは、グローバル ミューテックスまたはその他の名前付きオブジェクトに依存して、複数の同時実行セッションをチェックしたりブロックしたりしてはなりません。
    • アプリでユーザーごとに複数の同時セッションを許可できない場合は、ミューテックスやその他の名前付きオブジェクトに対して、ユーザーごとまたはセッションごとの名前空間を使用します。

テストがクラッシュしてハングする

認証テスト中にアプリを監視して、アプリがクラッシュやハングを起こしたタイミングを記録します。

  • バックグラウンド
    • クラッシュやハングなどのアプリの障害は、ユーザーにとって大きな中断であり、フラストレーションを引き起こします。 このような障害を排除すると、アプリの安定性と信頼性が向上し、全体的にユーザーのアプリ エクスペリエンスが向上します。 応答しなくなったアプリやクラッシュしたアプリは、データが失われたり操作性が低下したりする原因になることがあります。
  • テストの詳細
    • 認定テストを通じて、アプリの復元性や安定性をテストします。
    • Windows アプリ認定キットは 、IApplicationActivationManager::ActivateApplication を呼び出して Windows ストア アプリを起動します。 ActivateApplication でアプリを起動する場合は、ユーザー アカウント制御 (UAC) を有効にし、画面解像度を 1024 x 768 または 768 x 1024 以上にする必要があります。 どちらの条件も満たされない場合は、アプリはこのテストに合格しません。
  • 是正措置
    • テスト コンピューターで UAC が有効になっていることを確認します。
    • 十分な大きさの画面を備えたコンピューターでテストを実行していることを確認します。
    • テスト プラットフォームが ActivateApplication の前提条件を満たしているにもかかわらずアプリの起動に失敗する場合は、アクティブ化イベント ログを確認して問題のトラブルシューティングを行うことができます。 イベント ログでこのようなエントリを見つけるには、次の手順を実行します。
      1. eventvwr.exe開き、\Windows Logs\Application ノードに移動します。
      2. ビューをフィルター処理してイベント ID 5900 ～ 6000 を表示します。
      3. アプリが起動しなかった理由を説明している可能性のある情報のログ エントリを確認します。
    • 問題のあるファイルをトラブルシューティングして問題を特定し、修正します。 アプリをリビルドして再テストします。
  • その他のリソース

互換性と回復性のテスト

  • 背景
    • このチェックでは、アプリの 2 つの側面を検証します。たとえば、アプリメイン実行可能ファイル (たとえば、ユーザーが直面するアプリのエントリ ポイント) を、互換性のためにマニフェストにし、適切な GUID を宣言する必要があります。 この新しいテストをサポートするために、レポートには "互換性 & の回復性" の下にサブ ノードがあります。 これらの条件の一方または両方が見つからない場合、アプリは失敗します。
  • テストの詳細
    • 互換性： アプリは、Windows 互換モード、AppHelp メッセージ、またはその他の互換性修正を使用せずに完全に機能する必要があります。 互換性マニフェストを使用すると、Windows はさまざまなバージョンの OS でアプリに適切な互換性動作を提供できます
    • AppInit: アプリでは、HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLsレジストリ キーに読み込む DLL を一覧表示することはできません。
    • スイッチバック: アプリケーションはスイッチバック マニフェストを提供する必要があります。 マニフェストが見つからない場合は、Windows アプリ認定キットに警告メッセージが表示されます。 Windows アプリ認定キットでは、マニフェストに有効な OS GUID が含まれていることも確認されます。
  • 問題への対応
    • 互換性修正を使用するアプリのコンポーネントを修正します。
    • アプリが機能の互換性修正に依存していないことを確認します。
    • アプリがマニフェストされ、互換性セクションに適切な値が含まれることを確認します
  • 追加情報

Windows セキュリティベスト プラクティス テスト

  • 背景
    • アプリで既定の Windows セキュリティ設定を変更しないでください
  • テストの詳細
    • Attack Surface Analyzer を実行して、アプリのセキュリティをテストします。 このアプローチでは、テストごとに障害のカテゴリを追加します。 たとえば、セキュリティ テストのカテゴリには次のようなものがあります。
      • 初期化エラー
      • セキュリティ アーキテクチャの失敗
      • バッファー オーバーフローエラーの可能性
      • クラッシュエラー
    • 詳細については、 こちらを参照してください。
  • 問題への対応
    • テストによって特定された問題のトラブルシューティングと修正。 アプリをリビルドして再テストします。

Windows セキュリティ機能テスト

  • 背景
    • アプリケーションでは、Windows セキュリティ機能をオプトインする必要があります。 Windows 既定のセキュリティ保護を変更すると、ユーザーが危険にさらされるリスクが増大します。
  • テストの詳細
  • 問題への対応
    • テストによって特定された問題のトラブルシューティングと修正。 アプリをリビルドして再テストします。

高 DPI テスト

Win32 アプリでは DPI 対応を強くお勧めします。 さまざまな高 DPI ディスプレイ設定でアプリの UI を一貫して適切に表示することが重要です。 高 DPI ディスプレイ設定で実行されている非 DPI 対応アプリでは、UI 要素の不適切なスケーリング、クリップされたテキスト、ぼやけた画像などの問題が発生する可能性があります。 アプリが DPI 対応であることを宣言するには、2 つの方法があります。 1 つは DPI を宣言する方法です。

  • 背景
    • このチェックでは、アプリの 2 つの側面を検証します。たとえば、ユーザーが直面するアプリのエントリ ポイントメイン実行可能ファイルは、高 DPI 認識用にマニフェストする必要があり、HIGH-DPI をサポートするために適切な API が呼び出されていることを確認します。 これらの条件の一方または両方が見つからない場合、アプリは失敗します。 このチェックでは、デスクトップ レポートに新しいセクションが導入されます。次の例を参照してください。
  • テストの詳細
    • テストでは、次のいずれかを検出すると警告が生成されます。
      • メイン EXE は、マニフェストで DPI 認識を宣言せず、SetProcessDPIAware API を呼び出しません。 (DPI 認識マニフェストの追加を忘れた場合は、開発者に警告します)。
      • メイン EXE はマニフェストで DPI 認識を宣言しませんが、SetProcessDPIAware API を呼び出します (API を呼び出す代わりにマニフェストを使用して DPI 認識を宣言する必要があることを開発者に警告します)。
      • mainEXE はマニフェストで DPI 認識を宣言しますが、SetProcessDPIAware API も呼び出します (API を呼び出す必要はないことを開発者に警告します)。
      • EXEs メインされていないバイナリに対して、API を呼び出す場合は警告を表示します (API の呼び出しはお勧めしません)。
  • 問題への対応
    • SetProcessDPIAware() 関数の使用はお勧めしません。 DLL が初期化中に DPI 設定をキャッシュする場合、アプリで SetProcessDPIAware() を呼び出すと競合状態が発生する可能性があります。 DLL で SetProcessDPIAware() 関数を呼び出すのも良い方法ではありません。
  • 追加情報