ブルースクリーンエラーのチェック|パソコントラブル出張修理
TOP > 技術情報 > ブルースクリーン > 0x00000139 KERNEL_SECURITY_CHECK_FAILURE
STOP:0x00000139 KERNEL_SECURITY_CHECK_FAILUREエラーの概要です。
これは、カーネルが重要なデータ構造の破損を検出したことを示します。
KERNEL_SECURITY_CHECK_FAILUREパラメータ
以下のパラメータがブルースクリーンに表示されます。
第一パラメータ
破損のタイプ。詳細については次の表を参照してください。
第二パラメータ
バグチェックの原因となった例外のトラップフレームのアドレス
第三パラメータ
バグチェックの原因となった例外の例外レコードのアドレス
第四パラメータ
予約済み
次の表は、パラメータ1の値を説明しています。
第一パラメータ | 説明 |
---|---|
0 | スタックベースのバッファ(レガシーGS違反)ラン状態になりました。 |
1 | VTGuardインスツルメンテーション・コードは違法仮想関数テーブルを使用しようとする試みを検出しました。 典型的には、C++オブジェクトが破損した後、仮想メソッド呼び出しはこのポインタが破損したのオブジェクトを使用しようとしました。 |
2 | スタッククッキー計測コードは、スタックベースのバッファオーバーラン(GS違反)を検出しました。 |
3 | LIST_ENTRY(例えば、二重削除)破損していました。詳細については、次の原因を参照してください。 |
4 | 予約済み |
5 | 無効なパラメータが無効なパラメータが致命的とみなし関数に渡されました。 |
6 | スタッククッキーセキュリティCookieは、適切にローダによって初期化されませんでした。 これは、Windows 8上で動作するようにドライバを構築し、以前のバージョンのWindowsにドライバイメージをロードしようとすることによって 引き起こされることがあります。 この問題を回避するには、以前のバージョンのWindows上で実行するようにドライバをビルドする必要があります。 |
7 | 致命的なプログラムの終了が要求されました。 |
8 | 配列の範囲が不正配列のインデックス操作を検出したコンパイラによって挿入を確認してください。 |
9 | RtlQueryRegistryValuesへの呼び出しはRTL_QUERY_REGISTRY_TYPECHECKせずRTL_QUERY_REGISTRY_DIRECT指定行われ、 目標値は信頼できるシステムハイブではありませんでした。 |
原因
このバグチェックのほとんどの原因は簡単になる傾向があります。唯一の例外は、コード3、LIST_ENTRYの破損です。
バグチェックのこのタイプは、追跡するのが困難になると矛盾が二重リンクリスト
(個々のリスト項目の要素を追加したり、リストから削除されたときに検出された)に導入されたことを示しています。
残念なことに、矛盾が必ずしも破損が発生した時に検出されていません。
リストエントリの破損の一般的な原因は次のとおりです。
■別のスレッドがそのkeventを使用していたときに、ドライバは、そのkevent(スレッドがその同じそのkeventで待機している、
またはスタックベースのそのkeventがスコープの外に行くことを許可していた間に、
たとえば二重keventを初期化するように、カーネル同期オブジェクトを、破損しています)
バグチェックのこのタイプは通常、Nnt!Keまたはnt!Kiコードで発生します。
スレッドは、同期オブジェクト上またはときにコードがシグナル状態に同期オブジェクトを入れようと
待機を終??了するときにそれが起こることがあります。
通常、合図される同期オブジェクトは壊れているものです。
時には、特別なプール付きのDriver Verifierは、(壊れた同期オブジェクトがすでに解放されているプールのブロックにある場合)は、
原因を追跡するのに役立ちます。
■ドライバは、定期的なKTIMERが破損しています。バグチェックのこのタイプは通常、nt!Keまたはnt!Kiコードで発生し、
タイマーをシグナリング、またはタイマーテーブルからタイマーを挿入または削除が含まれます。
操作されているタイマーが壊れているものであってもよいですが、
それはタイマーでテーブルを検査する必要があるかもしれません。
タイマータイマーが壊れているかを識別するために(または手動でタイマーリストのリンクを歩いて)
時には、特別なプール付きのDriver Verifierは、(壊れKTIMERはすでに解放されているプールのブロックにある場合)は、
原因を追跡するのに役立ちます。
■ドライバが内部LIST_ENTRYスタイルリンクリストを不手際ています。
典型的な例では、2つのRemoveEntryListコール間のリストのエントリを再挿入することなく、
同じリストのエントリに二回RemoveEntryListを呼び出すことになります。
その他のバリエーションは、そのような二重同じリストにエントリを挿入するように可能です。
■ドライバが古いプールブロックが再利用された後にリストが検査されたときに破損が後で検出されてしまい、
それに対応するリストからデータ構造を削除せずにLIST_ENTRYを含むデータ構造を解放しました。
■ドライバがリストに引き裂かれたアップデートで、その結果、適切な同期せずに同時方式でLIST_ENTRYスタイルのリストを使用しています。
ほとんどのケースでは、両方の前方と後方のその結果を比較すします。
(リンクリストを歩くことによって、破損したデータ構造を識別することができ、DLとDLBのコマンドは、この目的のために有用でです。)
リストは前方と後方の徒歩の間で矛盾しているところでは、典型的な障害の場所です。
リンクリストの更新操作は隣接する要素のリストリンクを変更することができるので、それらは、基礎となる原因である可能性があります。
多くのシステムコンポーネントが内部LIST_ENTRYリストを活用しているため、
システムAPIを使用してドライバによるリソース不始末の様々なタイプのシステム管理リンクリスト内のリンクリストの破損を
引き起こす可能性があります。
※この内容は、Microsoftのバグチェックコードの解説を参考にして要点をまとめたものとなります。
翻訳内容は必ずしも正しいとは限りませんのでご容赦願います。
詳しい内容は
http://msdn.microsoft.com/en-us/library/windows/hardware/jj569891(v=vs.85).aspxをご覧下さい。