バグ チェック 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 IRQLs の詳細については、「Windows Internals 7th Edition Part 1 by Pavel Yosifovich、Mark E. Russinovich、David A. ソロモン、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 コマンドを使用してコンテキストを指定されたアドレスに設定します。

この種類のバグ チェックのデバッグを開始するには、 kkbkckdkpkPkv (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 コマンドを使用して、このメモリ領域の詳細を確認します。

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

uubuu (組み立て) コマンドを使用して、パラメーター 4 でメモリを参照したアドレス内のコードを確認します。

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

ドライバーの検証ツール

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

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

解説

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

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

  • バグ チェックのメッセージでドライバーが特定された場合は、そのドライバーを無効にするか、ドライバーの更新状況を製造元に確認します。

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

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