次の方法で共有


バグ チェック 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++ オブジェクトが破損し、破損したオブジェクトの this ポインターを使用して仮想メソッド呼び出しが試行されました。
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 内から無効な呼び出しが行われました。
二十四 無効なイメージ ベース アドレスが検出されました。
二十五 遅延ロード・インポートの保護中にリカバリー不能な障害が発生しました。
26 安全でない内線番号に呼び出しが行われました。
二十七 非推奨のサービスが呼び出されました。
28 領域外のバッファ・アクセスが検出されました。
二十九 RTL_BALANCED_NODE RBTree エントリが破損しています。
37 範囲外のスイッチ ジャンプ テーブル エントリが呼び出されました。
三十八 無効なターゲットに対して 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 によるカーネルモード ダンプ ファイルの分析