次の方法で共有


バグ チェック 0x139: KERNEL_SECURITY_CHECK_FAILURE

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

Von Bedeutung

この記事は、プログラマー向けです。 コンピューターの使用中にブルー スクリーン エラー コードを受け取るお客様は、「 ブルー スクリーン エラーのトラブルシューティング」を参照してください。

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

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

次の表では、パラメーター 1 の可能な値について説明します。

パラメーター 1 説明
0 スタック ベースのバッファーがオーバーラン (レガシ /GS 違反) です。
1 VTGuard インストルメンテーション コードで、不正な仮想関数テーブルを使用する試みが検出されました。 通常、C++ オブジェクトが破損し、仮想メソッド呼び出しが破損したオブジェクトの この ポインターを使用しようとしました。
2 スタック Cookie インストルメンテーション コードで、スタックベースのバッファ オーバーラン (/GS 違反) が検出されました。
3 LIST_ENTRYが破損しています (二重削除など)。 詳細については、次の「原因」セクションを参照してください。
4 予約済み
5 無効なパラメーターを致命的と見なす関数に無効なパラメーターが渡されました。
6 ローダーがスタック Cookie セキュリティ Cookie を適切に初期化しませんでした。 このバグ チェックは、Windows 8 でのみ実行するドライバーをビルドし、以前のバージョンの Windows でドライバー イメージを読み込もうとしたときに発生します。 この問題を回避するには、以前のバージョンの Windows で実行するドライバーをビルドする必要があります。
7 致命的なプログラム出口が要求されました。
8 コンパイラによって挿入された配列境界チェックで、無効な配列インデックス作成操作が検出されました。
9 rtlQueryRegistryValues への呼び出しは、RTL_QUERY_REGISTRY_TYPECHECKなしでRTL_QUERY_REGISTRY_DIRECTを指定して行われ、ターゲット値が信頼されたシステム ハイブにありませんでした。
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 範囲外のスイッチ ジャンプ テーブル エントリが呼び出されました。
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 を使用するドライバーによるさまざまな種類のリソース管理ミスにより、システム管理リンク リストでリンク リストが破損する可能性があります。

解決策

リスト エントリの破損の問題の原因を特定するには、通常、デバッガーを使用して他の情報を収集する必要があります。 複数のダンプ ファイルを調べて、停止コードが表示されたときに実行されるコードなど、停止コードの特性が似ているかどうかを確認する必要があります。

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

イベント ログを使用して、停止コードまでの上位レベルのイベントが発生しているかどうかを確認します。

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

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

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

  • イベント ビューアーのシステム ログで、エラーの原因となっているデバイスまたはドライバーを特定するのに役立つ可能性のあるその他のエラー メッセージを確認します。 ブルー スクリーンと同じ時間帯に発生した重大なエラーをシステム ログで探します。

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

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

  • 一般的なトラブルシューティング情報については、「 バグ チェックのブルー スクリーン データの分析」を参照してください。

こちらも参照ください

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

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