バグ チェック 0xD1: DRIVER_IRQL_NOT_LESS_OR_EQUAL

DRIVER_IRQL_NOT_LESS_OR_EQUAL バグ チェックには、0x000000D1 の値があります。 これは、カーネル モード ドライバーが高すぎるプロセス IRQL でページング可能なメモリにアクセスしようとしたことを示します。

重要

この記事は、プログラマー向けです。 コンピューターを使用中に、ブルー スクリーン エラーが表示された場合は、「ブルー スクリーン エラーのトラブルシューティング」を参照してください。

DRIVER_IRQL_NOT_LESS_OR_EQUAL パラメーター

パラメーター	説明
1	メモリ参照済み。
2	参照時の IRQL。
3	0 - 読み取り 1 - 書き込み 2 - 実行 8 - 実行
4	メモリを参照したアドレス。 このアドレスで ln (最も近いシンボルをリストする)を使用 して、関数の名前を確認します。

原因

原因を特定するには、Windows デバッガー、プログラミング エクスペリエンス、および障害が発生しているモジュールのソース コードへのアクセスが必要です。

通常、このエラーが発生する場合、 割り込み要求レベル (IRQL) が高すぎる間に、ドライバーがページング可能な (または完全に無効な) アドレスにアクセスしようとしました。 考えられる原因を以下に示します。

• DISPATCH_LEVEL 以上で実行中に、無効なポインター (NULL ポインターや解放されたポインターなど) を逆参照する。

• DISPATCH_LEVEL 以上でページング可能なデータにアクセスする。

• DISPATCH_LEVEL 以上でページング可能なコードを実行する。

エラーの原因となったドライバーを特定できる場合は、その名前がブルー スクリーンに出力され、メモリ内の場所 (PUNICODE_STRING) KiBugCheckDriver に格納されます。 これを表示するには、 dx (デバッガー オブジェクト モデル式の表示) デバッガーコマンドを使用します: dx KiBugCheckDriver。

このバグチェックは、通常、不適切なメモリ アドレスを使用したドライバーによって発生します。

ページ フォールトの原因として考えられるのは、次のイベントです。

• この関数はページング可能としてマークされ、管理者特権の IRQL (ロックの取得を含む) で実行されていました。

• 関数呼び出しが別のドライバーの関数に対して行われ、そのドライバーがアンロードされました。

• 無効なポインターである関数ポインターを使用して関数が呼び出されました。

Windows IRQLについては、 「Windows Internals 7th Edition Part 1 by Pavel Yosifovich, Mark E. Russinovich, David A. Solomon and Alex Ionescu を参照してください。

解決方法

開発中のドライバーによって問題が発生した場合は、バグ チェックの時点で実行されていた関数が次の値であることを確認します。

• ページング可能としてマークされていません
• ページアウトできる他のインライン関数は呼び出しません。

!analyze デバッガー拡張機能では、バグ チェックに関する情報が表示され、根本原因の特定に役立ちます。 次の例は !analyze からの出力です。

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: fffff808add27150, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff808adc386a6, address which referenced memory

エラーの原因となったドライバーを特定できる場合は、その名前がブルー スクリーンに出力され、メモリ内の場所 (PUNICODE_STRING) KiBugCheckDriver に格納されます。 これを表示するには、dx (デバッガー オブジェクト モデル式の表示) デバッガーコマンドを使用します: dx KiBugCheckDriver。

0: kd> dx KiBugCheckDriver
KiBugCheckDriver                 : 0xffffc6092de892c8 : "Wdf01000.sys" [Type: _UNICODE_STRING *]

ダンプ ファイルでトラップ フレームを使用できる場合は、.trap コマンドを 使用して、指定されたアドレスにコンテキストを設定します。

この種のバグ チェックのデバッグを開始するには、k、kb 、kc、kd 、 kp、 kP、 kv (display stack backtrace)コマンドを使用して スタック トレースを調べます 。

デバッガーで !irql 実行して、 コマンドを デバッガーが中断する前に、ターゲット コンピューター上のプロセッサの IRQL に関する情報を表示します。 次に例を示します。

0: kd> !irql
Debugger saved IRQL for processor 0x0 -- 2 (DISPATCH_LEVEL)

この種のバグ チェックのほとんどの場合、問題は IRQL レベルではなく、アクセスされているメモリです。

このバグチェックは通常、不適切なメモリ アドレスを使用したドライバーによって発生するため、パラメーター 1、3、4 を使用してさらに調査します。

ln (最も近いシンボルのリスト)をパラメーター 4 と共に使用 して、呼び出された関数の名前を確認します。 また、!analyze 出力を 調べて、エラーコードが特定されているかどうかを確認します。

パラメーター 1 アドレスで !pool を使用 して、ページ プールかどうかを確認します。 !address と高度な !pte コマンドを使用して 、このメモリ領域の詳細を確認します。

表示メモリー ・コマンドを 使用して、パラメーター 1 のコマンドで参照されるメモリーを調べます。

u, ub, uu (unassemble) コマンドを使って、パラメータ4のメモリーを参照したアドレスのコードを調べます。

コマンド lm t n を使用して、メモリに読み込まれているモジュールの一覧を表示します。 !!memusage を使用して、システム メモリの全般的な状態を調べます。

ドライバーの検証ツール

ドライバーの検証ツールは、リアルタイムで実行してドライバーの動作を調べるためのツールです。 たとえば、ドライバーの検証ツールでは、メモリ プールなどのメモリ リソースの使用がチェックされます。 ドライバー コードの実行でエラーが特定された場合は、ドライバー コードのその部分をさらに詳しく調査できるように、事前に例外が作成されます。 ドライバーの検証ツール マネージャーは、Windows に組み込まれており、すべての Windows PC で使用できます。

ドライバーの検証ツール マネージャーを起動するには、コマンド プロンプトで「 Verifier 」と入力します。 どのドライバーを検証するかを構成できます。 ドライバーを検証するコードが実行されるとオーバーヘッドが増えるので、検証するドライバーの数を可能な限り少なくするようにしてください。 詳細については、「ドライバーの検証ツール」を参照してください。

解説

Windows デバッガーを使用してこの問題に取り組む機能がない場合は、いくつかの基本的なトラブルシューティング手法を使用できます。

• イベント ビューアーのシステム ログで、このバグ チェックの原因になっているデバイスまたはドライバーの特定に役立つ可能性がある追加のエラー メッセージを調べます。

• バグ チェック メッセージでドライバーがわかる場合は、ドライバーを無効にするか、製造元にドライバーの更新プログラムを確認します。

• インストールされた新しいハードウェアが、インストールされている Windows のバージョンと互換性があることを確認します。 たとえば、 Windows 10 の仕様で必要なハードウェアに関する情報を取得できます。

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