WinDGB双机调试

假设某台计算机在运行某个驱动时蓝屏（运行代码在WinDbg教程代码文件夹中）。如下图：这时我们可以通过WinDGB进行双机调试。首先选择两台电系统之间的通信方式，WinDGB支持串行口、1394、USB三种方式。选择好通信方式后，就可以将合适的电缆插到两台系统的相应端口上。然后在主机上启动WinDBG，在其“File（文件）”选择“Kernel Debug(内核调试)”，或者按“Ctrl+K”。如下图：在内核调试对话框中选择要与通信电缆和目标机器一致的类型和参数，然后点击“确定”。WinDBG进入等待壮态，等待来自目标系统的调试数据。如下图所示：连接到目标系统后，第一步是使用 !analyze 扩展命令。该扩展执行大量的自动分析，分析结果在调试器命令窗口中显示。若要数据的全冗长模式显示，还应该使用 -v 选项。这里输入!analyze v命令，如下图所示：输入!analyze v命令后的显示：kd !analyze -v* Bugcheck Analysis *SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)This is a very common bugcheck. Usually the exception address pinpointsthe driver/function that caused the problem. Always note this addressas well as the link date of the driver/image that contains this address.Some common problems are exception code 0x80000003. This means a hardcoded breakpoint or assertion was hit, but this system was booted/NODEBUG. This is not supposed to happen as developers should never havehardcoded breakpoints in retail code, but .If this happens, make sure a debugger gets connected, and thesystem is booted /DEBUG. This will let us see why this breakpoint ishappening.Arguments:Arg1: 80000003, The exception code that was not handledArg2: f8d55578, The address that the exception occurred atArg3: f8afdb90, Exception Record AddressArg4: f8afd88c, Context Record Address/上面给出了相应的四个参数，第二列是代号，第三列是解释。Debugging Details:-* Kernel symbols are WRONG. Please fix symbols to do analysis.* Your debugger is not using the correct symbols * * In order for this command to work properly, your symbol path * must point to .pdb files that have full type information. * * Certain .pdb files (such as the public OS symbols) do not * contain the required information. Contact the group that * provided you with these symbols if you need this command to * work. * * Type referenced: nt!_KPRCB * Your debugger is not using the correct symbols * * In order for this command to work properly, your symbol path * must point to .pdb files that have full type information. * * Certain .pdb files (such as the public OS symbols) do not * contain the required information. Contact the group that * provided you with these symbols if you need this command to * work. * * Type referenced: nt!KPRCB * Your debugger is not using the correct symbols * * In order for this command to work properly, your symbol path * must point to .pdb files that have full type information. * * Certain .pdb files (such as the public OS symbols) do not * contain the required information. Contact the group that * provided you with these symbols if you need this command to * work. * * Type referenced: nt!_KPRCB * Your debugger is not using the correct symbols * * In order for this command to work properly, your symbol path * must point to .pdb files that have full type information. * * Certain .pdb files (such as the public OS symbols) do not * contain the required information. Contact the group that * provided you with these symbols if you need this command to * work. * * Type referenced: nt!KPRCB * Your debugger is not using the correct symbols * * In order for this command to work properly, your symbol path * must point to .pdb files that have full type information. * * Certain .pdb files (such as the public OS symbols) do not * contain the required information. Contact the group that * provided you with these symbols if you need this command to * work. * * Type referenced: nt!_KPRCB * Your debugger is not using the correct symbols * * In order for this command to work properly, your symbol path * must point to .pdb files that have full type information. * * Certain .pdb files (such as the public OS symbols) do not * contain the required information. Contact the group that * provided you with these symbols if you need this command to * work. * * Type referenced: nt!_KPRCB * Your debugger is not using the correct symbols * * In order for this command to work properly, your symbol path * must point to .pdb files that have full type information. * * Certain .pdb files (such as the public OS symbols) do not * contain the required information. Contact the group that * provided you with these symbols if you need this command to * work. * * Type referenced: nt!_KPRCB * Symbols can not be loaded because symbol path is not initialized. * * The Symbol Path can be set by: * using the _NT_SYMBOL_PATH environment variable. * using the -y argument when starting the debugger. * using .sympath and .sympath+ * Symbols can not be loaded because symbol path is not initialized. * * The Symbol Path can be set by: * using the _NT_SYMBOL_PATH environment variable. * using the -y argument when starting the debugger. * using .sympath and .sympath+ *ADDITIONAL_DEBUG_TEXT: Use !findthebuild command to search for the target build information.If the build information is available, run !findthebuild -s ; .reload to set symbol path and load symbols.MODULE_NAME: testa0FAULTING_MODULE: 804d8000 ntDEBUG_FLR_IMAGE_TIMESTAMP: 4b4c5698EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - FAULTING_IP: / FAULTING_IP字段表示出现故障时的指令指针testa0+578f8d55578 cc int 3EXCEPTION_RECORD: f8afdb90 - (.exr 0xfffffffff8afdb90) /EXCEPTION_RECORD字段表示这次菪机的异常记录ExceptionAddress: f8d55578 (testa0+0x00000578) ExceptionCode: 80000003 (Break instruction exception) ExceptionFlags: 00000000NumberParameters: 3 Parameter0: 00000000 Parameter1: 80528d14 Parameter2: 0000001fCONTEXT: f8afd88c - (.cxr 0xfffffffff8afd88c)eax=00000001 ebx=00000000 ecx=80528d14 edx=0000001f esi=e1e5ea1e edi=81cc1758eip=f8d55578 esp=f8afdc58 ebp=f8afdc7c iopl=0 nv up ei ng nz na po nccs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282testa0+0x578:f8d55578 cc int 3Resetting default scopeCUSTOMER_CRASH_COUNT: 1DEFAULT_BUCKET_ID: DRIVER_FAULT /DEFAULT_BUCKET_ID字段表示故障所属类别BUGCHECK_STR: 0x7E / BUGCHECK_STR字段表示异常代码LAST_CONTROL_TRANSFER: from 805777ff to f8d55578 / LAST_CONTROL_TRANSFER字段表示在栈中最后的调用。这里，在地址0x805777ff处的代码调用在0xf8d55578处的一个函数。STACK_TEXT: /STACK_TEXT字段表示出错组件的一个栈跟踪（回溯）。最下面的nt!KiDispatchInterrupt+0x5a2处函数调用nt!PsRemoveCreateThreadNotifyRoutine+0x21e，接着调用了nt!ExQueueWorkItem+0x1b2，再接着调用了nt!NtWriteFile+0x4647，一直到testa0+0x578，发生异常。WARNING: Stack unwind information not available. Following frames may be wrong.f8af5c7c 805777ff 81cd4f38 81ae7000 00000000 testa0+0x578f8af5d4c 8057790f 8000047c 00000001 00000000 nt!NtWriteFile+0x4537f8af5d74 80535c12 8000047c 00000000 821b7640 nt!NtWriteFile+0x4647f8af5dac 805c71ec b29decf4 00000000 00000000 nt!ExQueueWorkItem+0x1b2f8af5ddc 80542de2 80535b12 00000001 00000000 nt!PsRemoveCreateThreadNotifyRoutine+0x21e00000000 00000000 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x5a2FOLLOWUP_IP: / 反汇编发生错误指令的代码testa0+578f8d55578 cc int 3SYMBOL_STACK_INDEX: 0SYMBOL_NAME: testa0+578FOLLOWUP_NAME: MachineOwnerIMAGE_NAME: testa0.sysSTACK_COMMAND: .cxr 0xfffffffff8afd88c ; kb /STACK_COMMAND字段表示用来获取STACK_TEXT的命令BUCKET_ID: WRONG_SYMBOLS / BUCKET_ID字段表示当前故障所属的特定故障类别。这个类别帮助调试器确定在分析输出中所显示的其他信息。Followup: MachineOwner-当 !analyze 确定某指令可能引起错误的时候，就在FOLLOWUP_IP字段中显示它。 SYMBOL_NAME、MODULE_NAME、IMAGE_NAME和DBG_FLR_IMAGE_TIMESTAMP字段表示这个指令相应的符号、模块、映像名字和映像时间戳。1、手动加载符号文件：选择“File(文件)”“Symbol Search Path（符号文件路径）”，在弹出的对话框中选择“Browse（浏览）”，选择好符号文件的路径后点击“OK”。如下图：手动加载符号文件后再运行!analyze v命令出现如下图所示，从图中我们可以看出错误源代码所在位置。2、自动加载符号文件：如果相关符号表在目录没有找到的话，在符号表路径里做如下设置：srv*d:symbolslocal*/download/symbols ，WinDBG会自动在Microsoft的Symbol Servers上下载。如下图：3、观察模块信息：可以使用以下命令来观察模块信息，包括调试符号情况。（1）使用lm命令。lm命令显示指定的已加载模块，输出中包含模块状态和路径。如下图：其中start和end为该模块在进程空间中的起始地址和终止地址，module name是模块名称。（2）使用!lmi扩展命令，!lmi 扩展显示某个模块的详细信息。如下图：kd !lmi testa0Loaded Module Info: testa0 Module: testa0 /模块名称 Base Address: f8cda000 /模块在内存中的基地址 Image Name: testa0.sys Machine Type: 332 (I386) /模块所针对的CUP架构 Time Stamp: 4b4c5698 Tue Jan 12 19:01:44 2010 /时间戳 Size: c80 /文件大小，字节 CheckSum: e1a3 /校验和Characteristics: 10e Debug Data Dirs: Type Size VA Pointer CODEVIEW 53, 9bc, 9bc RSDS - GUID: E9A64B9E-54BD-47A4-8188-5BDB049D4F90 Age: 1, Pdb: E:windbg_teachpendDRIVERobjchk_w2K_x86i386testa0.pdb Image T