KD を使用したユーザーモード エラーのデバッグ

ユーザー モード エラーを適切にデバッグするには、CDB または WinDbg が必要です。 ただし、ユーザー モード デバッガーが存在しないために、ユーザー モード例外が KD に割り込むことがあります。 カーネル モードの問題のデバッグ中に、特定のユーザー モード プロセスが実行していることを監視するのに役立つときもあります。

既定では、カーネル デバッガーは、指定されたアドレスに一致する最初のユーザー モード シンボルを読み込もうとします (k、u、または ln コマンドの場合)。

残念ながら、ユーザー モード シンボルがシンボル パスに指定されていないことや、最初のシンボルが正しくないことがよくあります。 シンボルがない場合は、シンボルをシンボル パスにコピーするか、または .sympath (シンボル パスの設定) コマンドを使用してシンボル ツリー全体をポイントしてから、.reload (モジュールの再読み込み) コマンドを使用します。 間違ったシンボルが読み込まれる場合は、.reload <binary.ext> を実行してシンボルを明示的に読み込むことができます。

ほとんどの Windows DLL はリベースされるため、異なるアドレスで読み込まれますが、例外があります。 ビデオ アダプターは最も一般的な例外です。 同じベース アドレスで読み込まれるビデオ アダプターは数十個あるため、KD はほとんどの場合、ati.dll (最初のビデオ シンボル、アルファベット順) を見つけます。 ビデオの場合は、lm コマンドを使用して特定できる .sys ファイルも読み込まれます。 その情報を使用すると、.reload を発行して正しいビデオ DLL を取得できます。 デバッガーが混乱し、特定のシンボルを再読み込みすることで正しいスタックが得られるときもあります。 関数を逆アセンブルして、シンボルが正しく見えるかどうかを確認します。

ビデオ DLL と同様に、ほぼすべての実行可能ファイルが同じアドレスで読み込まれるため、KD はアクセスを報告します。 アクセスでスタック トレースが表示される場合は、指定された実行可能ファイル名の !process を実行し、.reload を実行します。 実行可能ファイルのシンボル パスにシンボルがない場合は、パスにシンボルをコピーし、再度 .reload を実行します。

完全なシンボル ツリーがシンボル パス内にあるときでも、KD または WinDbg で正しいユーザー モード シンボルの読み込みに問題が発生することがあります。 この場合、ntdll.dll と kernel32.dll が必要になる最も一般的なシンボルの 2 つです。 KD からの CSRSS のデバッグの場合、winsrv.dll と csrsrv.dll も読み込まれる一般的な DLL です。