バグ チェック 0x139:KERNEL_SECURITY_CHECK_FAILURE

KERNEL_SECURITY_CHECK_FAILURE のバグチェックの値は0x00000139 です。 このバグチェックは、カーネルが重要なデータ構造の破損を検出したことを示します。

重要

このトピックはプログラマーを対象としています。 コンピューターの使用中にブルー スクリーン エラー コードが表示される場合は、「ブルー スクリーン エラーのトラブルシューティング」を参照してください。

バグチェック 0x139 KERNEL_SECURITY_CHECK_FAILURE パラメーター

パラメーター 説明
1 破損の種類。 詳細については、後の表を参照してください。
2 バグチェックの原因となった例外のトラップフレームのアドレス
3 バグチェックの原因となった例外の例外レコードのアドレス
4 予約されています。

次の表では、パラメーター1に使用できる値について説明します。

パラメーター 1 説明
0 スタックベースのバッファーがオーバーランされました (レガシ/GS 違反)。
1 VTGuard インストルメンテーションコードは、無効な仮想関数テーブルを使用しようとしました。 通常、C++ オブジェクトが破損しているため、破損したオブジェクトの this ポインターを使用して仮想メソッドの呼び出しが試行されました。
2 スタック cookie インストルメンテーションコードは、スタックベースのバッファーオーバーラン (/GS 違反) を検出しました。
3 LIST_ENTRY が破損しています (たとえば、二重の削除)。 詳細については、次の原因に関するセクションを参照してください。
4 予約されています。
5 無効なパラメーターを致命的と見なす関数に無効なパラメーターが渡されました。
6 スタック cookie のセキュリティクッキーがローダーによって正しく初期化されませんでした。 これは、Windows 8 でのみ実行されるドライバーをビルドし、以前のバージョンの Windows でドライバーイメージを読み込もうとした場合に発生する可能性があります。 この問題を回避するには、以前のバージョンの Windows で実行するようにドライバーを構築する必要があります。
7 致命的なプログラム終了が要求されました。
8 コンパイラによって挿入された配列の境界チェックで、無効な配列のインデックス操作が検出されました。
9 RTL_QUERY_REGISTRY_TYPECHECK を指定せずに RTL_QUERY_REGISTRY_DIRECT を指定して Rtlqueryregistryvalues を呼び出しましたが、対象の値が信頼されたシステムハイブにありませんでした。
10 間接呼び出しガードチェックで、無効な制御転送が検出されました。
11 書き込みガードチェックで、無効なメモリ書き込みが検出されました。
12 無効なファイバーコンテキストに切り替えようとしました。
13 無効なレジスタコンテキストを割り当てようとしました。
14 オブジェクトの参照カウントが無効です。
18 無効な jmp_buf コンテキストに切り替えようとしました。
19 読み取り専用データに対して安全ではない変更が行われました。
20 暗号化自己テストが失敗しました。
21 無効な例外チェーンが検出されました。
22 暗号化ライブラリエラーが発生しました。
23 DllMain 内から無効な呼び出しが行われました。
24 無効なイメージのベースアドレスが検出されました。
25 遅延読み込みのインポートの保護中に、回復不能なエラーが発生しました。
26 安全でない拡張機能に対する呼び出しが行われました。
27 非推奨のサービスが呼び出されました。
28 範囲外のバッファーアクセスが検出されました。
29 RTL_BALANCED_NODE RBTree エントリが破損しています。
37 範囲外の switch jumptable エントリが呼び出されました。
38 Longjmp が無効なターゲットに対して試行されました。
39 エクスポートの抑制された呼び出しターゲットを有効な呼び出しターゲットにすることができませんでした。

原因

パラメーター1のテーブルとダンプファイルを使用すると、この種類の多くのバグチェックの原因を絞り込むことができます。

LIST_ENTRY の破損は、追跡するのが困難な場合があります。このバグチェックは、二重にリンクされたリストに一貫性がないことを示しています (個々のリストエントリ要素が追加されるか、リストから削除されるときに検出されます)。 残念ながら、不整合は、破損が発生したときに必ずしも検出されるとは限りません。そのため、根本的な原因を特定するために、一部の検出作業が必要になる場合があります。

リストエントリの破損の一般的な原因には、次のものがあります。

  • ドライバーが、KEVENT などのカーネル同期オブジェクトを破損しています (たとえば、スレッドが同じ KEVENT を待機している間に KEVENT をダブル初期化した場合、または別のスレッドがその KEVENT を使用している間にスタックベースの KEVENT がスコープ外に出ることを許可している場合)。 この種類のバグチェックは、通常、nt で実行されます。Ke * または nt!Ki * コード。 スレッドが同期オブジェクトの待機を終了したとき、またはコードが同期オブジェクトをシグナル状態にしようとしたときに発生する可能性があります。 通常、シグナル状態になっている同期オブジェクトが破損しています。 場合によっては、特別なプールを使用したドライバーの検証機能によって原因を突き止めることができます (破損した同期オブジェクトが、既に解放されているプールブロックにある場合)。
  • ドライバーによって定期的な KTIMER が破損しています。 通常、この種のバグ チェックは nt! で行われます。Ke* または nt!Ki* コードと には、タイマーのシグナルを送信したり、タイマー テーブルに対してタイマーを挿入または削除したりします。 操作されるタイマーは破損している可能性がありますが、どのタイマーが破損しているか識別するには、! timer を使用してタイマー テーブルを検査する (またはタイマー リスト リンクを手動で歩く) 必要がある場合があります。 場合によっては、特別なプールを持つドライバー検証ツールが原因を追跡するのに役立つ場合があります (破損した KTIMER が既に解放されているプール ブロックにある場合)。
  • ドライバーが、内部のリンク リストLIST_ENTRY管理し間違っています。 一般的な例は、2 つの RemoveEntryList 呼び出しの間でリスト エントリを再取得せずに、同じリスト エントリで RemoveEntryList を 2 回呼び出す場合です。 同じリストへのエントリの二重挿入など、他のバリエーションも可能です。
  • ドライバーは、対応するリストからデータ構造を削除せずに LIST_ENTRY を含むデータ構造を解放しました。その結果、古いプール ブロックが再利用された後にリストが検査されると、破損が検出されます。
  • ドライバーは、適切な同期LIST_ENTRY同時実行形式で新しいスタイルのリストを使用し、その結果、一覧が更新されます。

ほとんどの場合、リンクリストを前後に移動し ( dl コマンドと dlb コマンドは、この目的に役立ちます)、結果を比較することで、破損したデータ構造を特定できます。 一覧が前方ウォークと後方ウォークの間で一貫性がない場合は、通常、破損の場所です。 リンク リストの更新操作では、隣接する要素のリスト リンクを変更できます。そのため、破損したリスト エントリの近隣を密接に確認する必要があります。これらは、基になる原因である可能性があります。

多くのシステム コンポーネントは内部的に LIST_ENTRY リストを利用します。システム API を使用するドライバーによるさまざまな種類のリソース管理ミスにより、システムで管理されたリンク リストでリンク リストが破損する可能性があります。

解像度

通常、この問題の原因を特定するには、デバッガーを使用して追加情報を収集する必要があります。 複数のダンプ ファイルを調べて、この停止コードに類似した特性 (停止コードが表示された場合に実行されているコードなど) を確認する必要があります。

詳細については、「新しいデバッガーを使用したクラッシュ ダンプ分析 (WinDbg Windows!analyze 拡張機能と !analyze の使用」を参照してください

イベント ログを使用して、この停止コードに至る上位レベルのイベントが発生した場合に確認します。

これらの一般的なトラブルシューティングのヒントが役に立つ場合があります。

  • 最近システムにハードウェアを追加した場合は、削除または交換してみてください。 または、利用可能なパッチがないか、製造元に確認します。

  • 新しいデバイス ドライバーまたはシステム サービスが最近追加された場合は、それらを削除または更新してみてください。 新しいバグ チェック コードが表示される原因となったシステムの変更内容を確認します。

  • イベント ビューアーを使用してシステム ログで追加のエラー メッセージを確認すると、エラーの原因になっているデバイスやドライバーを特定できる可能性があります。 詳しくは、イベント ビューアーの使用に関するページをご覧ください。 ブルー スクリーンと同じ時間帯に発生した重大なエラーをシステム ログで探します。

  • 次のデバイス マネージャー、感嘆符 (!) でマークされているデバイスを確認します。 エラーが発生しているドライバーのドライバー プロパティに表示されるイベント ログを確認します。 関連するドライバーを更新してみます。

  • ウイルス検出プログラムを実行します。 ウイルスは、コンピューター用にフォーマットされたすべての種類のハード ディスクに感染する可能性Windows、その結果、ディスクの破損によってシステム バグ チェック コードが生成される可能性があります。 ウイルス検出プログラムがマスター ブート レコードの感染を確認します。

  • その他の一般的なトラブルシューティング情報については、「 Blue Screen Data」を参照してください

関連項目

Windows デバッガー (WinDbg) を使用したクラッシュ ダンプ分析

WinDbg によるカーネルモード ダンプ ファイルの分析