wenmo8 发布的文章

下面介绍的知识性信息来自intel IA-32手册(可以在intel的开发手册或者官方网站查到),提示和补充来自学习调试器实现时的总结。

DRx对应任意的一个调试寄存器。LENn对应任意一个长度。Ln对应任意一个局部置位,DR0-DR7可以直接被读写操作(MOV 指令之类的,DRx可以是源操作数也可以是目的操作数)。但是,DRx的访问是需要一定权限的。比如你用MOV操作的话,你需要在实地址模式,系统管理模式(smm)或者在保护模式(CPL设0).如果权限不够,将会在访问DRx的时候尝产生#GP(general-protection)异常。

DRx可以干些什么?

  • 设置发生断点的地址(线性地址)
  • 设置断点的长度(1,2,4个字节,但是执行断点只能是1)
  • 设置在调试异常产生的地址执行的操作
  • 设置断点是否可用
  • 在调试异常产生时,调试条件是否是可用

我们来看看调试寄存器的一些细节信息。下图很重要,后面的介绍都是针对这个图说的。

  • 调试寄存器 DR0-DR3
    这四个寄存器是用来设置 断点地址的。断点的比对在物理地址转换前(异常产生时,还没有将线性地址转换成物理地址)。由于只有0-3四个保存地址的寄存器,所以,硬件断点,在物理上最多只能有4个。
  • 调试寄存器DR4-DR5
    这两个调试寄存器有CR4的DE标记控制。如果DE置位,那么对这两个寄存器的访问会导致#UD异常。如果DE置0,那么他们就被化名为DR6-DR7(你一定会问原来的DR6-DR7怎么办?这个…… 我也不知道。如果你搞明白了,一定记得告诉我)
  • 调试寄存器DR7(控制寄存器)
    DR7是调试控制寄存器。控制方式嘛!继续看:
    1. L0-L3(由第0,2,4,6位控制):对应DR0-DR3,设置断点作用范围,如果被置位,那么将只对当前任务有效。每次异常后,Lx都被清零。
    2. G0-G3(由第1,3,5,7位控制):对应DR0-DR3,如果置位,那么所有的任务都有效。每次异常后不会被清零。以确保对所有任务有效。但是,不知道为什么,我在测试时:
    设置Gn后,不能返回调试异常给调试器(如果你知道为什么,记得告诉我)
    3.
    LE,GE(由第8,9位控制):这个在P6以下系列CPU上不被支持,在升级版的系列里面:如果被置位,那么cpu将会追踪精确的数据断点。LE是局部的,GE是全局的。(到底什么算精确的,我也不清楚,但是,我知道如果设置了这两个,cpu的速度会降低。我在测试中,都没有置位。)
    4. GD(由第13位控制):如果置位,追踪下一条指令是否会访问调试寄存器。如果是,产生异常。在下面的DR6里面,你会知道他还和另外一个标志位有点关系。
    5. R/W0-R/W3:(由第16,17,20,21,24,25,28,29位控制):这个东西的处理有两种情况。
    如果CR4的DE被置位,那么,他们按照下面的规则处理问题:
    00:执行断点
    01:数据写入断点
    10:I/0读写断点
    11:读写断点,读取指令不算
    如果DE置0,那么问题会这样处理:
    00:执行断点
    01:数据写入断点
    10:未定义
    11:数据读写断点,读取指令不算
    6. LEN0-LEN3:(由第18.19.22.23.26.27.30位控制):指定内存操作的大小。
    00:1字节(执行断点只能是1字节长)
    01:2字节
    10:未定义或者是8字节(和cpu的系列有关系)
    11:4字节
  • 调试寄存器DR6(调试状态寄存器)
    这个寄存器主要是在调试异常产生后,报告产生调试异常的相关信息
    1.B0-B3(DR0-DR3):DRx指定的断点在满足DR7指定的条件下,产生异常。那么Bx就置位。但是,有时,即使Ln和Gn置0,也可能产生Bx被置位。这种现象可能这样出现(提示:在p6系列处理器,REP MOVS在不断循环中产生的调试异常需要执行完了才能准确返回给调试进程):DR0的L0,G0都置0(DR0就是一个不能产生异常的断点了),然后在DR0指定的地址是一个REP指令的循环,这样,DR0就可能在这个循环之后的REP指令产生的调试异常中将B0置位
    2.BD:BD需要DR7的GD置位,才有效。BD是在下一条指令要访问到某一个调试寄存器的时候,被置位的。
    3.BS:单步执行模式时,被置位。单步执行是最高权限的调试异常。
    4.BT:在任务切换的时候,被置位。但是必须在被切换去的任务的TSS段里面的T标记被置位的情况下才有效。在控制权被切换过去后,在执行指令前,返回调试异常。但是,需要注意,如果调试程序是一个任务,那么T标记的设置肯定就冲突了。然后,导致了死循环(BT的这些信息都是按照官方资料翻译而来,由于没有实际的操作,肯定会有理解上的出入。如果要深入的话,建议看官方资料).有些调试异常会将B0-B3清零。但是其他的DR6的位是不能被产生异常的进程清零的。每次调试异常返回后,调试进程都会先将DR6清零,再按照情况设置。以免产生不必要的错误。

对齐问题和64位处理器

对齐问题

这个问题是来源于LENn的设置,如果设置4字节,那么必须4字节对齐。例如:我们下4字节的断点,那么DRx需要是A0000/A0004/A0008这样的地址上。I/O地址是零扩展的(这个……也许意味着必须完全对齐)。因为,intel在比对地址时:用LENn的值去覆盖DRx里面保存的地址的低位。你可以想到,不对齐会有什么后果了吧。注意:执行断点只能是1字节。
再用图片解释下(当然,图片来自intel官方资料):

 

在64位处理器下

调试寄存器当然也是64位的。在操作过程中,写入,前面32位被置零。读取:只返回后32位。MOV DRx操作,前32位被忽略。DR6-DR7的高32位被保留。置零。如果置位,会产生#GP异常。8字节的读写断点完全被支持。最后,还是给个图片(64位处理器的布局):

最后需要提醒一个小问题:数据写入断点设置后。是在原数据被修改后,才产生调试异常。所以,返回异常时,原有数据已经被修改。如果想保留原有数据,需要自己提前保存对应地址的数据。

转自:https://blog.csdn.net/whatday/article/details/8621410

微软给我们提供了一些很好的程序,比如资源监视器,可以从这个软件里获取分析windows的自身的一些性能数据,比如CPU、内存、磁盘数据、文件读写、进程线程等,他具体怎么实现呢,今天这天文章就带你去获取其真实的原理。

1.分析

打开windows任务栏管理器,在其性能选项里,可以看到性能监控的一些机器性能图表

 

这个只是一些概要数据,如果要看详细的内容,可以点击左下角的“打开资源监视器”,会自己开启一个进程perfmon.exe的进程,这个进程界面会显示详细的资源信息

 

 

 

 

我们可以看到每个进程打开了什么文件、读写了什么磁盘数据、以及访问了什么网络的IP都有详细的信息,这个进程既没有文件过滤驱动也没有网络驱动他是如何实现去获取这些详细的信息呢,下面我们来具体分析下。

打开这个软件所在的目录,可以看到一些对应的perfmon.exe 、perfnet.dll、perfDisk.dll、perfos.dll、perfpro.dll进程和模块

 

 

 

IDA打开perfmon.exe看看其进程一些函数

 

 

 

 也只是一些UI相关的函数,说明核心功能并不在这里exe里 ,在继续换一个,用IDA打开perdisk.dll这个模块

 

 

 QQ图片20170616162416.png

 

模块里有一些比较明显的函数CollectDiskObjectData、CollectPDiskObjectData、CollectLDiskObjectData等函数,选择一个函数用windbg调试器去下断点

 

 QQ图片20170616162449.png

 

当第一放过运行时,调试器立马就停了下来,看堆栈区域

 

 QQ图片20170616162548.png

 

大概是这样的

 

# RetAddr           : Args to Child                                                           : Call Site
00 00007ffc`2d132060 : ffffffff`feced300 00000000`00000010 00000000`00000014 00000000`00000000 : perfdisk!CollectDiskObjectData
01 00007ffc`2d1316b5 : 00000000`00007f88 00000000`00000000 00000000`00000000 00000000`00000000 : ADVAPI32!QueryExtensibleData+0x540
02 00007ffc`29a92a99 : 0000021e`67749c66 00000000`000602ff 000000fc`368ff728 00007ffc`ffffffff : ADVAPI32!PerfRegQueryValue+0x325
03 00007ffc`29a9204d : ffffffff`80000004 000000fc`368ff7a4 0000021e`6b4904f0 000000fc`368ff820 : KERNELBASE!MapPredefinedHandleInternal+0x8e9
04 00007ffc`25f063ec : ffffffff`80000004 0000021e`6b490490 0000021e`00008000 000000fc`368ff7a4 : KERNELBASE!RegQueryValueExW+0xed
05 00007ffc`25f056ad : 0000021e`6b490490 0000021e`6ad74c10 00000000`00008000 00000000`00000000 : pdh!GetSystemPerfData+0x9c
06 00007ffc`25f054c9 : 01d2e6b6`135f9140 000000fc`368ff8b8 00000000`00000000 01d2e673`053c5140 : pdh!GetQueryPerfData+0xcd
07 00007ffc`01548566 : 00000000`00000000 00000000`00000003 00000000`00000000 00000000`000002b0 : pdh!PdhCollectQueryData+0x59
08 00007ffc`2ad58364 : 0000021e`6adc1b00 00000000`00000000 00000000`00000000 00000000`00000000 : wdc!WdcTraceControl::QueryThread+0x1a6
09 00007ffc`2d2370d1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x14
0a 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21

 

堆栈看该函数被调用是从wdc!WdcTraceControl::QueryThread这个函数过来的,看样子是一个单独的数据线程,是wdc.dll这个模块里的函数,继续用IDA打开wdc这个模块。

 

 QQ图片20170616162649.png

 

QQ图片20170616162701.png

 

 

 

查看WdcTraceControl::QueryThread这个函数实现,确实调用了一些监控实例的Query方法,这里我们可以确认wc.dll这个模块是核心功能所在的模块,现在可以分析下是怎么开启这个线程的,开启前做了哪些工作。

 

 QQ图片20170616162742.png

 

发现只有一处调用,就是WdcTraceControl::Start函数调用了这个函数开启线程

 

 QQ图片20170616162753.png

 

继续往上翻阅WdcTraceControl::Start函数实现

 

 QQ图片20170616162806.png

 

QQ图片20170616162818.png

 

 

 

有一个WdcTraceControl::TraceStart 函数,进入该函数 

 

 QQ图片20170616162927.png

 

QQ图片20170616162938.png

 

QQ图片20170616162949.png

 

QQ图片20170616163000.png

 

 

 

 发现该函数调用OpenTrace、StartTrace、EnableTraceEx、processTrace这些函数,从EnableTraceEx的参数ThreadPoolGuid、PsProvGuid、DiskProvGuid、FileProvGuid、NetProvGuid可以判断这些函数就是核心功能,查看微软的CSDN终于发现了秘密,原来这些函数是 微软事件诊断函数(ETW),其中OpenTrace的里的有一个参数是事件的回掉接收函数,我们看到的WdcTraceControl::CallbackEvent这个函数就是,下个断点,确实断了下来

 

 QQ图片20170616163123.png

 

QQ图片20170616163135.png

 

 

 

就是WdcTraceControl::TraceThread线程中的ProcessTrace函数处理获取了内核日志数据然后调用了设置的回调函数WdcTraceControl::CallbackEvent去处理,为了进一步验证,翻阅该回调函数的实现

 

 QQ图片20170616163224.png

 

可以知道里面处理了各种过来的数据包括网络、磁盘、cpu、内存、线程、进程日志信息,去写个demo实例验证我们的结果。

 

2.代码demo

 

#include "stdafx.h"
#define INITGUID  //Include this #define to use SystemTraceControlGuid in Evntrace.h.
#include <Windows.h>
#include <wmistr.h>
#include <evntrace.h>
#include <evntcons.h>
#include <strsafe.h>
#pragma comment(lib,"Advapi32.lib")
#define LOGFILE_PATH    L"kernellogfile.etl"
#define ETL_FILE        L"G:\\OpenSource\\GitHub\\WindowsSDK7-Samples\\winbase\\Eventing\\EtwConsumer\\Output\\16.pdf.etl"
#define __REAL_TIME_MODE
/* 不同类型的GUID,从MSDN手册中找,固定的 */
DEFINE_GUID ( /* 3d6fa8d0-fe05-11d0-9dda-00c04fd7ba7c */
ProcessGuid,
0x3d6fa8d0,
0xfe05,
0x11d0,
0x9d, 0xda, 0x00, 0xc0, 0x4f, 0xd7, 0xba, 0x7c
);
ULONG WINAPI BufferCallback( __in PEVENT_TRACE_LOGFILE LogFile )
{
printf( "BufferCallback!\n" );
return TRUE;
}
/* 可以调用SetTraceCallback 设置单独事件GUID的回调函数,即使如此,EventCallback仍然会收到所有的事件 */
VOID WINAPI EventRecordCallback( __in PEVENT_RECORD Event )
{
if ( IsEqualGUID( Event->EventHeader.ProviderId, ProcessGuid ) )
{
/* 需要解析数据格式 */
printf( "EventRecordCallback  ProcessGuid!\n" );
}
printf( "EventRecordCallback!\n" );
}
VOID WINAPI EventCallback( PEVENT_TRACE pEvent )
{
printf( "EventCallback!\n" );
}
VOID EventConsumer()
{
TRACEHANDLE hTrace = NULL;
EVENT_TRACE_LOGFILE traceFile;
#ifdef __REAL_TIME_MODE
traceFile.LogFileName = NULL;
traceFile.LoggerName  = KERNEL_LOGGER_NAME;
traceFile.ProcessTraceMode = PROCESS_TRACE_MODE_REAL_TIME | PROCESS_TRACE_MODE_EVENT_RECORD;
#else
traceFile.LogFileName = ETL_FILE;
traceFile.LoggerName = NULL;
traceFile.ProcessTraceMode = PROCESS_TRACE_MODE_EVENT_RECORD;
#endif
traceFile.BufferCallback        = BufferCallback;
traceFile.EventCallback         = EventCallback;
if ( traceFile.ProcessTraceMode & PROCESS_TRACE_MODE_EVENT_RECORD )
traceFile.EventRecordCallback   = EventRecordCallback;
traceFile.Context = NULL;
hTrace = OpenTrace( &traceFile );
if ( hTrace == (TRACEHANDLE)INVALID_HANDLE_VALUE || hTrace == 0x0 )
return ;
ULONG status = ProcessTrace( &hTrace, 1, NULL, NULL );
}
void EventController(void)
{
ULONG status = ERROR_SUCCESS;
TRACEHANDLE SessionHandle = 0;
EVENT_TRACE_PROPERTIES* pSessionProperties = NULL;
ULONG BufferSize = 0;
BufferSize = sizeof(EVENT_TRACE_PROPERTIES) + sizeof(KERNEL_LOGGER_NAME) + sizeof(LOGFILE_PATH) ;
pSessionProperties = (EVENT_TRACE_PROPERTIES*) malloc(BufferSize);    
if (NULL == pSessionProperties)
{
wprintf(L"Unable to allocate %d bytes for properties structure.\n", BufferSize);
goto cleanup;
}
ZeroMemory(pSessionProperties, BufferSize);
pSessionProperties->Wnode.BufferSize    = BufferSize;
pSessionProperties->Wnode.Flags         = WNODE_FLAG_TRACED_GUID;
pSessionProperties->Wnode.ClientContext = 1; //QPC clock resolution
pSessionProperties->Wnode.Guid          = SystemTraceControlGuid; 
pSessionProperties->EnableFlags         = EVENT_TRACE_FLAG_PROCESS;                 // 关注事件
#ifdef __REAL_TIME_MODE
pSessionProperties->LogFileMode         = EVENT_TRACE_REAL_TIME_MODE;               // EVENT_TRACE_USE_PAGED_MEMORY 该标识在win7上会导致失败
#else
pSessionProperties->LogFileMode         = EVENT_TRACE_FILE_MODE_CIRCULAR;
#endif
pSessionProperties->MaximumFileSize     = 5;  // 5 MB
pSessionProperties->LoggerNameOffset    = sizeof(EVENT_TRACE_PROPERTIES);
pSessionProperties->LogFileNameOffset   = sizeof(EVENT_TRACE_PROPERTIES) + sizeof(KERNEL_LOGGER_NAME); 
#ifndef __REAL_TIME_MODE            // 也可在RealTime模式下开启,但是没必要RealTime都记录到文件
StringCbCopy((LPWSTR)((char*)pSessionProperties + pSessionProperties->LogFileNameOffset), sizeof(LOGFILE_PATH), LOGFILE_PATH);
#endif
status = StartTrace((PTRACEHANDLE)&SessionHandle, KERNEL_LOGGER_NAME, pSessionProperties);
if (ERROR_SUCCESS != status)
{
if (ERROR_ALREADY_EXISTS == status)
wprintf(L"The NT Kernel Logger session is already in use.\n");
else
wprintf(L"EnableTrace() failed with %lu\n", status);
goto cleanup;
}
EventConsumer();
wprintf(L"Press any key to end trace session ");
getchar();
cleanup:
if (SessionHandle)
{
status = ControlTrace(SessionHandle, KERNEL_LOGGER_NAME, pSessionProperties, EVENT_TRACE_CONTROL_STOP);
if (ERROR_SUCCESS != status)
wprintf(L"ControlTrace(stop) failed with %lu\n", status);
}
else
{
/* 开启会话后,若不关闭,即使进程退出,依然会保持开启状态,单独关闭可使用如下方式 */
status = ControlTrace(NULL, KERNEL_LOGGER_NAME, pSessionProperties, EVENT_TRACE_CONTROL_STOP);
if (ERROR_SUCCESS != status)
wprintf(L"ControlTrace(stop) failed with %lu\n", status);
}
if (pSessionProperties)
free(pSessionProperties);
}
int _tmain(int argc, _TCHAR* argv[])
{
EventController();
//EventConsumer();
while (true)
{
Sleep(300000);
}
return 0;
}

 

运行后,当有数据来时就会进入我们设置的回调函数

 

 QQ图片20170616163401.png

 

          此处我们大概知道了该软件的实现原理,剩下具体的对数据的内容的解析不再继续赘述,读者可以自行去研究,从这篇文章里我们知道了微软提供了一套内核事件诊断的函数方便我们去分析系统一些的性能,我们不光可以用这些函数去分析诊断系统,我们可以充分利用这些函数去实现一些我们想要的功能,大家可以自行去发挥。

转自:https://bbs.pediy.com/thread-218627.htm

来自Windows调试工具包的所有调试程序都使用相同的引擎dbgeng.dll。它包含一种特殊语言的脚本解释器,我们称之为WinDbg脚本语言以方便使用,我们对WinDbg脚本文件使用WDS文件扩展名。下面是在分析一个脚本时捕获的WinDbg线程的调用堆栈:

0:000> ~1kL 100ChildEBP RetAddr   
037cd084 6dd28cdc dbgeng
!TypedData::ForceU64+0x3037cd0ec 6dcbd08c dbgeng!GetPseudoOrRegVal+0x11c037cd134 6dcbceff dbgeng!MasmEvalExpression::GetTerm+0x12c037cd198 6dcbca23 dbgeng!MasmEvalExpression::GetMterm+0x36f037cd1d4 6dcbc873 dbgeng!MasmEvalExpression::GetAterm+0x13037cd220 6dcbc783 dbgeng!MasmEvalExpression::GetShiftTerm+0x13037cd254 6dcbc523 dbgeng!MasmEvalExpression::GetLterm+0x13037cd2c0 6dcbc443 dbgeng!MasmEvalExpression::GetLRterm+0x13037cd2f4 6dcbc424 dbgeng!MasmEvalExpression::StartExpr+0x13037cd308 6dcbbc2f dbgeng!MasmEvalExpression::GetCommonExpression+0xc4037cd31c 6dccdca3 dbgeng!MasmEvalExpression::Evaluate+0x4f037cd390 6dccd83d dbgeng!EvalExpression::EvalNum+0x63037cd3d0 6dd293cc dbgeng!GetExpression+0x5d037cd458 6dd2a7e2 dbgeng!ScanRegVal+0xfc037cd4ec 6dd17502 dbgeng!ParseRegCmd+0x422037cd52c 6dd194e8 dbgeng!WrapParseRegCmd+0x92037cd608 6dc8ed19 dbgeng!ProcessCommands+0x1278037cd644 6dc962af dbgeng!DotFor+0x1d9037cd658 6dd1872e dbgeng!DotCommand+0x3f037cd738 6dd19b49 dbgeng!ProcessCommands+0x4be037cd77c 6dc5c879 dbgeng!ProcessCommandsAndCatch+0x49037cdc14 6dd19cc3 dbgeng!Execute+0x2b9037cdc64 6dc89db0 dbgeng!ProcessCurBraceBlock+0xa3037cdc74 6dc962af dbgeng!DotBlock+0x10037cdc88 6dd1872e dbgeng!DotCommand+0x3f037cdd68 6dd19b49 dbgeng!ProcessCommands+0x4be037cddac 6dc5c879 dbgeng!ProcessCommandsAndCatch+0x49037ce244 6dd173ca dbgeng!Execute+0x2b9037ce2c4 6dd1863c dbgeng!ParseDollar+0x29a037ce3a0 6dd19b49 dbgeng!ProcessCommands+0x3cc037ce3e4 6dc5c879 dbgeng!ProcessCommandsAndCatch+0x49037ce87c 6dc5cada dbgeng!Execute+0x2b9037ce8ac00318693 dbgeng!DebugClient::ExecuteWide+0x6a037ce954 00318b83 windbg!ProcessCommand+0x143037cf968 0031ae46 windbg!ProcessEngineCommands+0xa3037cf97c 76fa19f1 windbg!EngineLoop+0x366037cf988 77c8d109 kernel32!BaseThreadInitThunk+0xe037cf9c800000000 ntdll!_RtlUserThreadStart+0x23

如果您调试了一段时间的崩溃转储,那么您可能遇到了这样的情况:调试器提供的初始转储上下文对应于在处理初始异常时发生的第二个异常,该异常可能更接近您正在调查的问题中的原始基础问题。
这可能很烦人,因为“.ecxr”命令将指向次要故障异常的位置,而不是原始异常上下文本身。然而,在大多数情况下,原始的、主要的异常上下文仍然在堆栈上;人们只需要知道如何找到它。

有两种方法可以解决这个问题:

  • 对于硬件生成的异常(如访问冲突),可以查找堆栈上的ntdll!KiUserExceptionDispatcher,它以PCONTEXT和PEXCEPTION_RECORD作为参数。
  • 对于软件生成的异常(如C++异常),情况会变得更糟。你可以找在堆栈上调用ntdll!RtlDispatchException,然后从那里获取PCONTEXT参数

如果堆栈展开失败,或者您正在处理其中一个转储,其中多个线程同时出现异常,这可能会有点乏味,这通常是由于崩溃转储写入失控。如果调试器能稍微自动化一下这个过程就好了。幸运的是,用一点蛮力的方法来做到这一点其实并不难。具体地说,只是一个普通的老“哑”内存扫描,以查找大多数上下文记录所共有的内容。这并不完全是一种巧妙的方法,但通常比手动在堆栈中查找要快得多,尤其是在涉及多个线程或多个嵌套异常的情况下。虽然可能会有误报,但通常很明显的一点是,涉及到一个活动异常有什么意义。然而,有时,快速而肮脏的暴力类型解决方案最终真的做到了这一点。
但是,为了基于内存搜索查找上下文记录,我们需要一些公共数据点,这些数据点通常对于所有上下文结构都是相同的,并且最好是连续的(为了便于使用“s”命令,调试器的内存搜索支持)。幸运的是,它以上下文结构的段寄存器的形式存在:

0:000> dt ntdll!_CONTEXT
+0x000 ContextFlags : Uint4B
[…]

+0x08c SegGs : Uint4B
+0x090 SegFs : Uint4B
+0x094 SegEs : Uint4B
+0x098 SegDs : Uint4B

[…]

现在,事实证明,对于给定进程中的所有线程,几乎总是具有相同的段选择器值,不包括异常的和非常不寻常的情况,如VDM进程。(x64上的段选择器值也是如此。)四个非零的32位值(实际上,零填充到32位的16位值)足以在不被误报的情况下合理地完成搜索。下面介绍如何使用臭名昭著的WinDbg调试器脚本(也适用于其他启用DbgEng的程序,如kd):

.foreach ( CxrPtr { s -[w1]d 0 l?ffffffff @gs @fs @es @ds } ) { .cxr CxrPtr – 8c }

这是一个有点冗长的命令,所以让我们把它分解成各个组件。首先,我们有一个“.foreach”构造,根据调试器文档,它遵循以下约定:

.foreach [Options] ( Variable { InCommands } ) { OutCommands }

.foreach命令(实际上是多个版本调试器脚本命令之一,一旦人们习惯使用它)基本上接受由输入命令(in commands)生成的一系列输入字符串,并调用一个命令来处理该输出(OutCommands),输入命令的结果作为变量参数。它很难看,并且基于文本解析进行操作(除其他外,还支持跳过每个X输入;请参阅调试器文档),但它完成了任务。

当你调试一个程序时,你最不想处理的是调试器不能正常工作。当你试图集中精力跟踪一个bug时,总是会因为次要的问题而被忽略,尤其是当调试器的问题导致你失去一个重新编程或者浪费了大量的时间等待调试器完成它,而调试器知道这需要永远做些什么的时候。