バグ チェック 0x139: KERNEL_SECURITY_CHECK_FAILURE
KERNEL_Standard Edition CURITY_CHECK_FAILUREバグ チェックには、0x00000139の値があります。 このバグ チェックは、カーネルが重要なデータ構造の破損を検出したことを示しています。
重要
この記事は、プログラマー向けです。 コンピューターを使用中に、ブルー スクリーン エラーが表示された場合は、「ブルー スクリーン エラーのトラブルシューティング」を参照してください。
バグ チェック 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 用にフォーマットされたあらゆる種類のハード ディスクに感染する可能性があり、その結果、ディスクが破損すると、システム バグ チェック コードが生成される可能性があります。 ウイルス検出プログラムによって感染のマスター ブート レコードがチェックされていることを確認します。
その他の一般的なトラブルシューティング情報については、バグ チェックのブルー スクリーン データの分析に関する記述を参照してください。