!analyze 拡張機能の使用Using the !analyze Extension

クラッシュしたターゲットコンピューターまたはアプリケーションをデバッグするための最初の手順は、 ! analyze 拡張コマンドを使用することです。The first step in debugging a crashed target computer or application is to use the !analyze extension command.

この拡張機能では、大量の自動分析が実行されます。This extension performs a tremendous amount of automated analysis. この分析の結果はコマンドウィンドウデバッガーに表示されます。The results of this analysis are displayed in the Debugger Command window.

データの完全な詳細表示を行うには、 -v オプションを使用する必要があります。You should use the -v option for a fully verbose display of data. その他のオプションの詳細については、「」 を参照し てください。For details on other options, see the !analyze reference page.

このトピックの内容は次のとおりです。This topic contains:

  • User-Mode! analyze-v の例A User-Mode !analyze -v Example
  • Kernel-Mode! analyze-v の例A Kernel-Mode !analyze -v Example
  • [フラグ] フィールドと triage.ini ファイルThe Followup Field and the triage.ini File
  • その他の! 分析手法Additional !analyze Techniques

User-Mode! analyze-v の例A User-Mode !analyze -v Example

この例では、例外が発生したユーザーモードアプリケーションにデバッガーがアタッチされています。In this example, the debugger is attached to a user-mode application that has encountered an exception.

0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

Debugger SolutionDb Connection::Open failed 80004005

インターネットに接続している場合、デバッガーは、Microsoft によって管理されているクラッシュソリューションのデータベースにアクセスしようとします。If you are connected to the internet, the debugger attempts to access a database of crash solutions maintained by Microsoft. この場合、コンピューターがインターネットにアクセスできなかったか、web サイトが機能していないことを示すエラーメッセージが表示されています。In this case, an error message was displayed, indicating that either your machine was unable to access the internet or the web site was not working.

FAULTING_IP: 
ntdll!PropertyLengthAsVariant+73
77f97704 cc               int     3

[エラーが発生した _ IP] フィールドには、エラー発生時の命令ポインターが表示されます。The FAULTING_IP field shows the instruction pointer at the time of the fault.

EXCEPTION_RECORD:  ffffffff -- (.exr ffffffffffffffff)
ExceptionAddress: 77f97704 (ntdll!PropertyLengthAsVariant+0x00000073)
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 3
   Parameter[0]: 00000000
   Parameter[1]: 00010101
   Parameter[2]: ffffffff

[例外 _ レコード] フィールドには、このクラッシュの例外レコードが表示されます。The EXCEPTION_RECORD field shows the exception record for this crash. この情報は、[ 例外レコードの表示 ] コマンドを使用して表示することもできます。This information can also be viewed by using the .exr (Display Exception Record) command.

BUGCHECK_STR:  80000003

バグチェックの _ STR フィールドは、例外コードを示しています。The BUGCHECK_STR field shows the exception code. 名前は名称です。 バグチェック とは、実際にはカーネルモードのクラッシュを意味します。The name is a misnomer—the term bug check actually signifies a kernel-mode crash. ユーザーモードのデバッグでは、例外コード (この場合は 0x80000003) が表示されます。In user-mode debugging, the exception code will be displayed—in this case, 0x80000003.

DEFAULT_BUCKET_ID:  APPLICATION_FAULT

"既定の _ バケット _ ID" フィールドには、このエラーが属するエラーの一般的なカテゴリが表示されます。The DEFAULT_BUCKET_ID field shows the general category of failures that this failure belongs to.

PROCESS_NAME:  MyApp.exe

[プロセス _ 名] フィールドには、例外を発生させたプロセスの名前を指定します。The PROCESS_NAME field specifies the name of the process that raised the exception.

LAST_CONTROL_TRANSFER:  from 01050963 to 77f97704

最後の _ _ [制御転送] フィールドには、スタックの最後の呼び出しが表示されます。The LAST_CONTROL_TRANSFER field shows the last call on the stack. この例では、アドレス0x01050963 のコードは、0X7・97704の関数と呼ばれていました。In this case, the code at address 0x01050963 called a function at 0x77F97704. これらのアドレスを ln (一番近いシンボルの一覧表示) コマンドと共に使用して、これらのアドレスがどのモジュールと関数に存在するかを判断できます。You can use these addresses with the ln (List Nearest Symbols) command to determine what modules and functions these addresses reside in.

STACK_TEXT:  
0006b9dc 01050963 00000000 0006ba04 000603fd ntdll!PropertyLengthAsVariant+0x73
0006b9f0 010509af 00000002 0006ba04 77e1a449 MyApp!FatalErrorBox+0x55 [D:\source_files\MyApp\util.c @ 541]
0006da04 01029f4e 01069850 0000034f 01069828 MyApp!ShowAssert+0x47 [D:\source_files\MyApp\util.c @ 579]
0006db6c 010590c3 000e01ea 0006fee4 0006feec MyApp!SelectColor+0x103 [D:\source_files\MyApp\colors.c @ 849]
0006fe04 77e11d0a 000e01ea 00000111 0000413c MyApp!MainWndProc+0x1322 [D:\source_files\MyApp\MyApp.c @ 1031]
0006fe24 77e11bc8 01057da1 000e01ea 00000111 USER32!UserCallWinProc+0x18
0006feb0 77e172b4 0006fee4 00000001 010518bf USER32!DispatchMessageWorker+0x2d0
0006febc 010518bf 0006fee4 00000000 01057c5d USER32!DispatchMessageA+0xb
0006fec8 01057c5d 0006fee4 77f82b95 77f83920 MyApp!ProcessQCQPMessage+0x3b [D:\source_files\MyApp\util.c @ 2212]
0006ff70 01062cbf 00000001 00683ed8 00682b88 MyApp!main+0x1e6 [D:\source_files\MyApp\MyApp.c @ 263]
0006ffc0 77e9ca90 77f82b95 77f83920 7ffdf000 MyApp!mainCRTStartup+0xff [D:\source_files\MyApp\crtexe.c @ 338]
0006fff0 00000000 01062bc0 00000000 000000c8 KERNEL32!BaseProcessStart+0x3d

スタックテキストフィールドには、エラーが発生した _ コンポーネントのスタックトレースが表示されます。The STACK_TEXT field shows a stack trace of the faulting component.

FOLLOWUP_IP: 
MyApp!FatalErrorBox+55
01050963 5e               pop     esi

FOLLOWUP_NAME:  dbg

SYMBOL_NAME:  MyApp!FatalErrorBox+55

MODULE_NAME:  MyApp

IMAGE_NAME:  MyApp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  383490a9

! Analyzeによって、エラーの原因と考えられる命令が判別されると、[フォローアップ IP] フィールドに表示され _ ます。When !analyze determines the instruction that has probably caused the error, it displays it in the FOLLOWUP_IP field. [シンボル _ 名]、[モジュール _ 名]、[イメージ _ 名]、および [デバッグ _ FLR イメージのタイムスタンプ] の各フィールドには、 _ _ この命令に対応するシンボル、モジュール、イメージの名前、およびイメージのタイムスタンプが表示されます。The SYMBOL_NAME, MODULE_NAME, IMAGE_NAME, and DEBUG_FLR_IMAGE_TIMESTAMP fields show the symbol, module, image name, and image timestamp corresponding to this instruction.

STACK_COMMAND:  .ecxr ; kb

Stack _ コマンドフィールドは、スタックテキストを取得するために使用されたコマンドを示して _ います。The STACK_COMMAND field shows the command that was used to obtain the STACK_TEXT. このコマンドを使用すると、このスタックトレースの表示を繰り返したり、関連するスタック情報を取得するように変更したりできます。You can use this command to repeat this stack trace display, or alter it to obtain related stack information.

BUCKET_ID:  80000003_MyApp!FatalErrorBox+55

バケット ID フィールドには、 _ 現在のエラーが属するエラーの特定のカテゴリが表示されます。The BUCKET_ID field shows the specific category of failures that the current failure belongs to. このカテゴリは、デバッガーが分析出力に表示する他の情報を決定するのに役立ちます。This category helps the debugger determine what other information to display in the analysis output.

Followup: dbg
---------

[フォローアップ名] フィールドと [フラグ] フィールドの詳細については、 _ 「"フラグ" フィールドと "triage.ini ファイル" を参照してください。For information about the FOLLOWUP_NAME and the Followup fields, see The Followup Field and the triage.ini File.

他にもさまざまなフィールドが表示されます。There are a variety of other fields that may appear:

  • 制御が無効なアドレスに転送された場合、エラーが発生した _ IP フィールドには無効なアドレスが含まれます。If control was transferred to an invalid address, then the FAULTING_IP field will contain this invalid address. [フォローアップ IP] フィールドの代わりに、[ _ 失敗した _ 命令 _ アドレス] フィールドには、このアドレスから逆アセンブルされたコードが表示されます。ただし、この逆アセンブリは意味がない可能性があります。Instead of the FOLLOWUP_IP field, the FAILED_INSTRUCTION_ADDRESS field will show the disassembled code from this address, although this disassembly will probably be meaningless. この場合、[シンボル _ 名]、[モジュール _ 名]、[イメージ _ 名]、および [デバッグ _ FLR イメージのタイムスタンプ] の _ _ 各フィールドは、この命令の呼び出し元を参照します。In this situation, the SYMBOL_NAME, MODULE_NAME, IMAGE_NAME, and DEBUG_FLR_IMAGE_TIMESTAMP fields will refer to the caller of this instruction.

  • プロセッサが間違って起動した場合は、シングル _ ビット _ エラー、2 _ ビット _ エラー、または _ 無効な _ 制御転送の _ フィールドが表示されることがあります。If the processor misfires, you may see the SINGLE_BIT_ERROR, TWO_BIT_ERROR, or POSSIBLE_INVALID_CONTROL_TRANSFER fields.

  • メモリの破損が発生しているように見える場合は、CHKIMG _ extension フィールドに、調査に使用する ! CHKIMG extension コマンドを指定します。If memory corruption seems to have occurred, the CHKIMG_EXTENSION field will specify the !chkimg extension command that should be used to investigate.

Kernel-Mode! analyze-v の例A Kernel-Mode !analyze -v Example

この例では、デバッガーは、クラッシュしたばかりのコンピューターにアタッチされています。In this example, the debugger is attached to a computer that has just crashed.

kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pagable (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.

画面の最初の要素には、バグチェックコードと、この種類のバグチェックに関する情報が表示されます。The first element of the display shows the bug check code and information about this type of bug check. 表示されるテキストの一部は、この特定のインスタンスに適用されない場合があります。Some of the text displayed may not apply to this specific instance. 各バグチェックの詳細については、「 バグチェックコードリファレンス 」セクションを参照してください。For more details on each bug check, see the Bug Check Code Reference section.

Arguments:
Arg1: 00000004, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: f832035c, address which referenced memory

次に、バグチェックのパラメーターが表示されます。The bug check parameters are displayed next. それぞれに説明が続きます。They are each followed by a description. たとえば、3番目のパラメーターは1であり、その後のコメントは書き込み操作が失敗したことを示しています。For example, the third parameter is 1, and the comment following it explains that this indicates that a write operation failed.

## Debugging Details:


WRITE_ADDRESS:  00000004 Nonpaged pool

CURRENT_IRQL:  2

次のいくつかのフィールドは、クラッシュの性質によって異なります。The next few fields vary depending on the nature of the crash. この場合、書き込み _ アドレスと現在の IRQL フィールドが表示さ _ れます。In this case, we see WRITE_ADDRESS and CURRENT_IRQL fields. これらは、単純にバグチェックパラメーターに示されている情報を書き換えとします。These are simply restating the information shown in the bug check parameters. "非ページプール" というステートメントをバグチェックテキストと比較することによって、"pagable (または完全に無効な) アドレスにアクセスしようとしました" というメッセージが表示され、アドレスが無効であることがわかります。By comparing the statement "Nonpaged pool" to the bug check text that reads "an attempt was made to access a pagable (or completely invalid) address," we can see that the address was invalid. この場合、無効なアドレスは0x00000004 でした。The invalid address in this case was 0x00000004.

FAULTING_IP: 
USBPORT!USBPORT_BadRequestFlush+7c
f832035c 894204           mov     [edx+0x4],eax

[エラーが発生した _ IP] フィールドには、エラー発生時の命令ポインターが表示されます。The FAULTING_IP field shows the instruction pointer at the time of the fault.

DEFAULT_BUCKET_ID:  DRIVER_FAULT

"既定の _ バケット _ ID" フィールドには、このエラーが属するエラーの一般的なカテゴリが表示されます。The DEFAULT_BUCKET_ID field shows the general category of failures that this failure belongs to.

BUGCHECK_STR:  0xD1

_バグチェックのフィールドは、既に説明したバグチェックコードを示しています。The BUGCHECK_STR field shows the bug check code, which we have already seen. 場合によっては、追加のトリアージ情報が追加されます。In some cases additional triage information is appended.

TRAP_FRAME:  f8950dfc -- (.trap fffffffff8950dfc)
.trap fffffffff8950dfc
ErrCode = 00000002
eax=81cc86dc ebx=81cc80e0 ecx=81e55688 edx=00000000 esi=81cc8028 edi=8052cf3c
eip=f832035c esp=f8950e70 ebp=f8950e90 iopl=0         nv up ei pl nz ac po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010216
USBPORT!USBPORT_BadRequestFlush+7c:
f832035c 894204           mov     [edx+0x4],eax     ds:0023:00000004=????????
.trap
Resetting default context

[トラップ _ フレーム] フィールドには、このクラッシュのトラップフレームが表示されます。The TRAP_FRAME field shows the trap frame for this crash. この情報は、[ トラップ (トラップフレームの表示) ] コマンドを使用して表示することもできます。This information can also be viewed by using the .trap (Display Trap Frame) command.

LAST_CONTROL_TRANSFER:  from f83206e0 to f832035c

最後の _ _ [制御転送] フィールドには、スタックの最後の呼び出しが表示されます。The LAST_CONTROL_TRANSFER field shows the last call on the stack. この場合、アドレス0xF83206E0 のコードは、0Xf83206e0 の関数と呼ばれていました。In this case, the code at address 0xF83206E0 called a function at 0xF832035C. [**Ln (最も近いシンボルの一覧表示)** ] コマンドを使用すると、これらのアドレスが格納されているモジュールと機能を確認できます。You can use the ln (List Nearest Symbols) command to determine what module and function these addresses reside in.

STACK_TEXT:  
f8950e90 f83206e0 024c7262 00000000 f8950edc USBPORT!USBPORT_BadRequestFlush+0x7c
f8950eb0 804f5561 81cc8644 81cc8028 6d9a2f30 USBPORT!USBPORT_DM_TimerDpc+0x10c
f8950fb4 804f5644 6e4be98e 00000000 ffdff000 nt!KiTimerListExpire+0xf3
f8950fe0 8052c47c 8053cf20 00000000 00002e42 nt!KiTimerExpiration+0xb0
f8950ff4 8052c16a efdefd44 00000000 00000000 nt!KiRetireDpcList+0x31

スタックテキストフィールドには、エラーが発生した _ コンポーネントのスタックトレースが表示されます。The STACK_TEXT field shows a stack trace of the faulting component.

FOLLOWUP_IP: 
USBPORT!USBPORT_BadRequestFlush+7c
f832035c 894204           mov     [edx+0x4],eax

[フォローアップ _ IP] フィールドには、エラーの原因と考えられる命令の逆アセンブリが表示されます。The FOLLOWUP_IP field shows the disassembly of the instruction that has probably caused the error.

FOLLOWUP_NAME:  usbtri

SYMBOL_NAME:  USBPORT!USBPORT_BadRequestFlush+7c

MODULE_NAME:  USBPORT

IMAGE_NAME:  USBPORT.SYS

DEBUG_FLR_IMAGE_TIMESTAMP:  3b7d868b

シンボル _ 名、モジュール _ 名、イメージ _ 名、および DBG _ FLR イメージのタイムスタンプフィールドには、 _ _ この命令に対応するシンボル、モジュール、イメージ、およびイメージのタイムスタンプ (有効な場合)、またはこの命令の呼び出し元 (存在しない場合) が表示されます。The SYMBOL_NAME, MODULE_NAME, IMAGE_NAME, and DBG_FLR_IMAGE_TIMESTAMP fields show the symbol, module, image, and image timestamp corresponding to this instruction (if it is valid), or to the caller of this instruction (if it is not).

STACK_COMMAND:  .trap fffffffff8950dfc ; kb

Stack _ コマンドフィールドは、スタックテキストを取得するために使用されたコマンドを示して _ います。The STACK_COMMAND field shows the command that was used to obtain the STACK_TEXT. このコマンドを使用すると、このスタックトレースの表示を繰り返したり、関連するスタック情報を取得するように変更したりできます。You can use this command to repeat this stack trace display, or alter it to obtain related stack information.

BUCKET_ID:  0xD1_W_USBPORT!USBPORT_BadRequestFlush+7c

バケット ID フィールドには、 _ 現在のエラーが属するエラーの特定のカテゴリが表示されます。The BUCKET_ID field shows the specific category of failures that the current failure belongs to. このカテゴリは、デバッガーが分析出力に表示する他の情報を決定するのに役立ちます。This category helps the debugger determine what other information to display in the analysis output.

INTERNAL_SOLUTION_TEXT:  https://oca.microsoft.com/resredir.asp?sid=62&State=1

インターネットに接続している場合、デバッガーは、Microsoft によって管理されているクラッシュソリューションのデータベースにアクセスしようとします。If you are connected to the internet, the debugger attempts to access a database of crash solutions maintained by Microsoft. このデータベースには、既知のバグに関する情報を含む膨大な数の Web ページへのリンクが含まれています。This database contains links to a tremendous number of Web pages that have information about known bugs. 問題の一致が見つかった場合、[内部ソリューション] テキストフィールドには、 _ _ 詳細情報にアクセスできる URL が表示されます。If a match is found for your problem, the INTERNAL_SOLUTION_TEXT field will show a URL that you can access for more information.

Followup: usbtri
---------

      This problem has a known fix.
      Please connect to the following URL for details:
      ------------------------------------------------
      https://oca.microsoft.com/resredir.asp?sid=62&State=1

[フォローアップ名] フィールドと [フラグ] フィールドの詳細については、 _ 「"フラグ" フィールドと "triage.ini ファイル" を参照してください。For information about the FOLLOWUP_NAME and the Followup fields, see The Followup Field and the triage.ini File:

他にもさまざまなフィールドが表示されます。There are a variety of other fields that may appear:

  • 制御が無効なアドレスに転送された場合、エラーが発生した _ IP フィールドには無効なアドレスが含まれます。If control was transferred to an invalid address, then the FAULTING_IP field will contain this invalid address. [フォローアップ IP] フィールドの代わりに、[ _ 失敗した _ 命令 _ アドレス] フィールドには、このアドレスから逆アセンブルされたコードが表示されます。ただし、この逆アセンブリは意味がない可能性があります。Instead of the FOLLOWUP_IP field, the FAILED_INSTRUCTION_ADDRESS field will show the disassembled code from this address, although this disassembly will probably be meaningless. この場合、シンボル _ 名、モジュール _ 名、イメージ _ 名、および DBG FLR の _ _ イメージの _ タイムスタンプフィールドは、この命令の呼び出し元を参照します。In this situation, the SYMBOL_NAME, MODULE_NAME, IMAGE_NAME, and DBG_FLR_IMAGE_TIMESTAMP fields will refer to the caller of this instruction.

  • プロセッサが間違って起動した場合は、シングル _ ビット _ エラー、2 _ ビット _ エラー、または _ 無効な _ 制御転送の _ フィールドが表示されることがあります。If the processor misfires, you may see the SINGLE_BIT_ERROR, TWO_BIT_ERROR, or POSSIBLE_INVALID_CONTROL_TRANSFER fields.

  • メモリの破損が発生しているように見える場合は、CHKIMG _ extension フィールドに、調査に使用する ! CHKIMG extension コマンドを指定します。If memory corruption seems to have occurred, the CHKIMG_EXTENSION field will specify the !chkimg extension command that should be used to investigate.

  • デバイスドライバーのコード内でバグチェックが発生した場合、その名前が [バグチェックドライバー] フィールドに表示されることがあり _ ます。If a bug check occurred within the code of a device driver, its name may be displayed in the BUGCHECKING_DRIVER field.

[フラグ] フィールドと triage.ini ファイルThe Followup Field and the triage.ini File

ユーザーモードとカーネルモードのどちらでも、表示の [フォローアップ] フィールドには、現在のスタックフレームの所有者に関する情報が表示されます (これを確認できる場合)。In both user mode and kernel mode, the Followup field in the display will show information about the owner of the current stack frame, if this can be determined. この情報は、次の方法で決定されます。This information is determined in the following manner:

  1. ! Analyze拡張機能を使用すると、デバッガーはスタックの一番上のフレームから開始し、エラーの原因となっているかどうかを判断します。When the !analyze extension is used, the debugger begins with the top frame in the stack and determines whether it is responsible for the error. そうでない場合は、次のフレームが分析されます。If it isn't, the next frame is analyzed. このプロセスは、障害が発生している可能性のあるフレームが見つかるまで続行されます。This process continues until a frame that might be at fault is found.

  2. デバッガーは、このフレーム内のモジュールと関数の所有者を特定しようとします。The debugger attempts to determine the owner of the module and function in this frame. 所有者を特定できる場合、このフレームはエラーが発生していると見なされます。If the owner can be determined, this frame is considered to be at fault.

  3. 所有者を特定できない場合、デバッガーは次のスタックフレームに渡され、その後、所有者が決定される (またはスタックが完全に検査されるまで) まで続きます。If the owner cannot be determined, the debugger passes to the next stack frame, and so on, until the owner is determined (or the stack is completely examined). この検索で所有者が見つかった最初のフレームは、エラーが発生していると見なされます。The first frame whose owner is found in this search is considered to be at fault. 情報が見つからない状態でスタックが使い果たされた場合、[フラグ] フィールドは表示されません。If the stack is exhausted without any information being found, no Followup field is displayed.

  4. エラーが発生したフレームの所有者は、[フォローアップ] フィールドに表示されます。The owner of the frame at fault is displayed in the Followup field. ! Analyze-v が使用されている場合、[フォローアップ _ IP]、[シンボル名]、[ _ モジュール _ 名]、[イメージ _ 名]、および [DBG _ FLR イメージのタイムスタンプ] の _ 各フィールドは、 _ このフレームを参照します。If !analyze -v is used, the FOLLOWUP_IP, SYMBOL_NAME, MODULE_NAME, IMAGE_NAME, and DBG_FLR_IMAGE_TIMESTAMP fields will refer to this frame.

[フォローアップ] フィールドで有用な情報を表示するには、最初にモジュールと関数の所有者の名前を含む Triage.ini ファイルを作成する必要があります。For the Followup field to display useful information, you must first create a Triage.ini file containing the names of the module and function owners.

Triage.ini ファイルは、エラーが発生する可能性のあるすべてのモジュールの所有者を識別する必要があります。The Triage.ini file should identify the owners of all modules that could possibly have errors. 実際の所有者ではなく、情報文字列を使用できますが、この文字列にはスペースを含めることはできません。You can use an informational string instead of an actual owner, but this string cannot contain spaces. モジュールでエラーが発生しないことがわかっている場合は、このモジュールを省略するか、スキップするかどうかを指定できます。If you are certain that a module will not fault, you can omit this module or indicate that it should be skipped. また、個々の関数の所有者を指定して、トリアージプロセスの粒度をさらに細かく指定することもできます。It is also possible to specify owners of individual functions, giving the triage process an even finer granularity.

Triage.ini ファイルの構文の詳細については、「 モジュールと関数の所有者を指定する」を参照してください。For details on the syntax of the Triage.ini file, see Specifying Module and Function Owners.

その他の! 分析手法Additional !analyze Techniques

バケット ID が正しいと思わない場合は、-D パラメーターを指定して、 _ ! analyzeを使用して -D バケットの選択をオーバーライドできます。If you do not believe that the BUCKET_ID is correct, you can override the bucket choice by using !analyze with the -D parameter.

クラッシュまたは例外が発生していない場合、 ! analyze は、ターゲットの現在の状態を示す非常に短いテキストを表示します。If no crash or exception has occurred, !analyze will display a very short text giving the current status of the target. 場合によっては、クラッシュが発生したかのように分析を強制的に実行する必要があります。In certain situations you may want to force the analysis to take place as if a crash had occurred. このタスクを実行するには 、! analyze-f を使用します。Use !analyze -f to accomplish this task.

ユーザーモードでは、例外が発生したが、根底にある問題がハングしたスレッドであると考えられる場合は、現在のスレッドを調査中のスレッドに設定してから、 ! analyze-hang を使用します。In user mode, if an exception has occurred but you believe the underlying problem is a hung thread, set the current thread to the thread you are investigating, and then use !analyze -hang. この拡張機能は、スレッドスタック分析を実行して、スレッドが他のスレッドをブロックしているかどうかを判断します。This extension will perform a thread stack analysis to determine if any threads are blocking other threads.

カーネルモードでは、バグチェックが発生したが、根底にある問題がハングしたスレッドであると考えられる場合は、 ! analyze-hang を使用します。In kernel mode, if a bug check has occurred but you believe the underlying problem is a hung thread, use !analyze -hang. この拡張機能は、システムによって保持されているロックを調査し、DPC キューチェーンをスキャンし、ハングしたスレッドの兆候を表示します。This extension will investigate locks held by the system and scan the DPC queue chain, and will display any indications of hung threads. 問題がカーネルモードのリソースデッドロックであると思われる場合は、ドライバーの検証ツールの デッドロック検出 オプションと共に ! デッドロック拡張機能を使用します。If you believe the problem is a kernel-mode resource deadlock, use the !deadlock extension along with the Deadlock Detection option of Driver Verifier.

既知の問題を自動的に無視することもできます。You can also automatically ignore known issues. これを行うには、最初に既知の問題の書式設定された一覧を含む XML ファイルを作成する必要があります。To do this, you must first create an XML file containing a formatted list of known issues. このファイルを読み込むには、 ! analyze-c-knownの既知のファイル 拡張子を使用します。Use the !analyze -c -loadKnownIssuesFile extension to load this file. その後、例外または中断が発生したときに、 ! analyze-c 拡張機能を使用します。Then when an exception or break occurs, use the !analyze -c extension. 例外が既知の問題の1つと一致した場合、ターゲットは実行を再開します。If the exception matches one of the known issues, the target will resume execution. ターゲットが実行を再開しない場合は、 ! analyze-v を使用して問題の原因を特定できます。If the target does not resume executing, then you can use !analyze -v to determine the cause of the problem. サンプル XML ファイルについては、「 \ \ _ デバッガーのインストールディレクトリ」の「analyze continue サブディレクトリ」を参照してください。A sample XML file can be found in the sdk\samples\analyze_continue subdirectory of the debugger installation directory.