次の方法で共有

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

  • [アーティクル]

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

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

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

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

正しいフォルダーへのインストールテスト

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

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

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

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

  • バックグラウンド
    • デジタル署名されたファイルを使用すると、ファイルが本物であることを確認し、ファイルが改ざんされているかどうかを検出できます。
    • カーネル モードのコード署名の適用は、コード整合性 (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 サービスには適用されません。 アプリ マニフェストは埋め込みでも外部でもかまいません。
    • マニフェストを作成するには、.manifest <app_name>.exe名前のファイルを作成し、EXE と同じディレクトリに格納します。 アプリに内部マニフェストがある場合、外部マニフェストは無視されることに注意してください。
      • たとえば、<requestedExecutionLevel level=""asInvoker |highestAvailable |requireAdministrator"" uiAccess=""true|false""/>
      • アプリのメイン プロセスは、標準ユーザー (asInvoker) として実行する必要があります。 管理機能は、管理特権で実行される別のプロセスに移動する必要があります。
      • 昇格された特権を必要とするユーザー向けのアプリは、Authenticode 署名されている必要があります。
  • テストの詳細
    • exes に接続しているすべてのユーザーは、asInvoker 属性でマークする必要があります。 highestAvailable または requireAdministrator としてマークされている場合は、正しく authenticode 署名されている必要があります。 アプリの exe には、uiAccess 属性を true に設定しないでください。 サービスとして実行されるすべての exe は、この特定のチェックから除外されます。
  • 修正アクション
    • アプリのマニフェスト ファイルで、正しいエントリとアクセス許可レベルを確認します。
  • 例外と免除
    • 昇格された特権でメイン プロセスを実行するアプリには免除が必要です (administrator または highestAvailable 必要です)。 主なプロセスは、ユーザーのエントリ ポイントをアプリに提供するプロセスです。
    • 免除は、次のシナリオのために考慮されます:
      • 実行レベルが highestAvailable 設定されている管理ツールまたはシステム ツール、Administrator、またはその両方が必要です。
      • ユーザー インターフェイス特権分離 (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 メッセージ、またはその他の互換性修正を使用せずに完全に機能している必要があります。 互換性マニフェストを使用すると、さまざまなバージョンの OS でアプリに適切な互換性動作を提供できます
    • AppInit: Apps は、HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs レジストリ キーに読み込む DLL を一覧表示してはなりません。
    • スイッチバック: アプリケーションはスイッチバック マニフェストを提供する必要があります。 マニフェストが見つからない場合は、Windows アプリ認定キットに警告メッセージが表示されます。 Windows アプリ認定キットでは、マニフェストに有効な OS GUID が含まれていることも確認されます。
  • 修正アクション
    • 互換性修正を使用するアプリのコンポーネントを修正します。
    • アプリが機能の互換性修正に依存していないことを確認します。
    • アプリがマニフェストされ、互換性セクションに適切な値が含まれているかどうかを確認します
  • 追加情報
    • 詳細については、「AppInit DLL」を参照してください。

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

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

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

  • バックグラウンド
    • アプリケーションでは、Windows セキュリティ機能をオプトインする必要があります。 既定の Windows セキュリティ保護を変更すると、お客様のリスクが高まる可能性があります。
  • テストの詳細
    • BinScope Binary Analyzer を実行して、アプリのセキュリティをテストします。 詳細については、のを参照してください。
  • 修正アクション
    • テストで特定された問題のトラブルシューティングと修正を行います。 アプリをリビルドして再テストします。

高 DPI テスト

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

  • バックグラウンド
    • このチェックでは、アプリの 2 つの側面を検証します。たとえば、ユーザーがアプリのエントリ ポイントに直面する主な実行可能ファイルは、HIGH-DPI 認識のためにマニフェストする必要があり、高 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() 関数を呼び出すのも良い方法ではありません。
  • 追加情報