windbg怎么过滤字符串

㈠ 如何使用windbg到hook的位置

那么我们首先应该做的是怎么样来解除掉它们，替换我们的执行地址，当然在这里，我们必须要知道这个结构：
typedef struct _SERVICE_DESCRIPTOR_TABLE
{
PVOID ServiceTableBase;
PULONG ServiceCounterTableBase;
ULONG NumberOfService;
ULONG ParamTableBase;
}SERVICE_DESCRIPTOR_TABLE,*PSERVICE_DESCRIPTOR_TABLE; // 由于KeServiceDescriptorTable只有一项,这里就简单点了
他就是SSDT 表了，这张表就类似于 PE 文件中的 IAT ，存储着一系列的函数地址，我们都知道，现在的系统都是基于保护模式的，当我们要访问内核的时候，MS 已经为我们定义好了接口，那么当我们调用哪些接口的时候，哪些接口会在这张表中查找需要的服务的地址函数，
我们在这里可以截获我们要过滤的函数请求，达到我们的目的。。。

这个结构有四个域：
反汇编得到：

HookApi!_SERVICE_DESCRIPTOR_TABLE
+0x000 ServiceTableBase : Ptr32 Void
+0x004 ServiceCounterTableBase : Ptr32 Uint4B
+0x008 NumberOfService : Uint4B
+0x00c ParamTableBase : Uint4B

//我们的替代的函数，是一个裸函数，编译器不会像其他的函数一样处理它。。。
__declspec(naked) NTSTATUS MyApiAddress(PHANDLE phandle,
ACCESS_MASK DesireAddress,
POBJECT_ATTRIBUTES pObjectAttributes,
PCLIENT_ID pClientID)
{
KdPrint(("NtPOpenProcess...Call"));
__asm
{
push 0C4h; //这两个域，是通过我们要HOOK 的 API 定位得到的
push 804daaa8h;
jmp [g_JmpServerAddr];
}
}

kd> u 805c2296
nt!NtOpenProcess:
这里是我们要调用的函数的入口点：
两个参数，遵循 C 的调用方式，手工清栈。。。就得到了
805c2296 68c4000000 push 0C4h //
805c229b 68a8aa4d80 push offset nt!ObWatchHandles+0x25c (804daaa8)
805c22a0 e86b6cf7ff call nt!_SEH_prolog (80538f10)

805c22a5 33f6 xor esi,esi
805c22a7 8975d4 mov dword ptr [ebp-2Ch],esi
805c22aa 33c0 xor eax,eax
805c22ac 8d7dd8 lea edi,[ebp-28h]
805c22af ab stos dword ptr es:[edi]
有两种方法获得我们要HOOK 的地址，可以通过函数，推荐PVOID
MmGetSystemRoutineAddress(
IN PUNICODE_STRING SystemRoutineName
);
比较方便，不用涉及其他的操作，返回的是要查的地址。。。。
不然的话，需要查MS 定义的服务描述表，而且个个平台还不一样，难以做到跨平台。。。

上边就完成了我们的导向工作，只要获取到了需要跳转的地址就 OK 了。。。
extern PSERVICE_DESCRIPTOR_TABLE KeServiceDescriptorTable; // KeServiceDescriptorTable为导出函数

操作之前：
我们需要：
// 去掉内存保护
VOID ClearMemoryProtect()
{
__asm
{
cli;
mov eax, cr0;
and eax, not 10000h;
mov cr0, eax;
}
}

// 跳转到NtOpenProcess函数头＋10的地方，这样在其前面写的JMP都失效了，完成替换
g_JmpServerAddr = (ULONG)NtOpenProcess + 10;

// 回复内存的保护
VOID RecoverMemoryProtect()
{
__asm
{
cli;
mov eax, cr0;
or eax, not 10000h;
mov cr0, eax;
sti;
}
}

*((ULONG*)uAddress) = (ULONG)MyApiAddress; // HOOK SSDT

去除内存的写保护，操作完成自后，回复之。。。。

㈡ 如何过滤windbg的打印信息

在logcat里点选绿色的+，然后在“by Application Name:”里填入com.my.app就OK了。 它还有“by Log Tag”、内“by Log Message”、“by PID”过滤容条件。

㈢ 如何过滤windbg的打印信息

在logcat里点选绿色的+，然后在“by Application Name:”里填入com.my.app就OK了。 它还有“by Log Tag”、“专by Log Message”、“by PID”过滤条属件。

㈣ 如何过滤windbg的打印信息

在logcat里点选绿色的+，然后在“by Application Name:”里填入com.my.app就OK了。回 它还有“答by Log Tag”、“by Log Message”、“by PID”过滤条件。

㈤ Windows内核调试器的WinDBG

WinDBG和用户调试器一点很大不同是内核调试器在一台机器上启动，通过串口调试另一个相联系的以Debug方式启动的系统，这个系统可以是虚拟机上的系统，也可以是另一台机器上的系统（这只是微软推荐和实现的方法，其实象SoftICE这类内核调试器可以实现单机调试）。很多人认为主要功能都是在WinDBG里实现，事实上并不是那么一回事，windows已经把内核调试的机制集成进了内核，WinDBG、kd之类的内核调试器要做的仅仅是通过串行发送特定格式数据包来进行联系，比如中断系统、中断点、显示内存数据等等。然后把收到的数据包经过WinDBG处理显示出来。
在进一步介绍WinDBG之前，先介绍两个函数：KdpTrace、KdpStub，我在《windows异常处理流程》一文里简单提过这两个函数。现在再提一下，当异常发生于内核态下，会调用KiDebugRoutine两次，异常发生于用户态下，会调用KiDebugRoutine一次，而且第一次调用都是刚开始处理异常的时候。
当WinDBG未被加载时KiDebugRoutine为KdpStub，处理也很简单，主要是对由int 0x2d引起的异常如DbgPrint、DbgPrompt、加载卸载SYMBOLS（关于int 0x2d引起的异常将在后面详细介绍）等，把Context.Eip加1，跳过int 0x2d后面跟着的int 0x3指令。
真正实现了WinDBG功能的函数是KdpTrap，它负责处理所有STATUS_BREAKPOINT和STATUS_SINGLE_STEP（单步）异常。STATUS_BREAKPOINT的异常包括int 0x3、DbgPrint、DbgPrompt、加载卸载SYMBOLS。DbgPrint的处理最简单，KdpTrap直接向调试器发含有字符串的包。DbgPrompt因为是要输出并接收字符串，所以先将含有字符串的包发送出去，再陷入循环等待接收来自调试器的含有回复字符串的包。SYMBOLS的加载和卸载通过调用KdpReportSymbolsStateChange，int 0x3断点异常和int 0x1单步异常（这两个异常基本上是内核调试器处理得最多的异常）通过调用KdpReportExceptionStateChange，这两个函数很相似，都是通过调用KdpSendWaitContinue函数。KdpSendWaitContinue可以说是内核调试器功能的大管家，负责各个功能的分派。这个函数向内核调试器发送要发送的信息，比如当前所有寄存器状态，每次单步后我们都可以发现寄存器的信息被更新，就是内核调试器接受它发出的包含最新机器状态的包；还有SYMBOLS的状态，这样加载和卸载了SYMBOLS我们都能在内核调试器里看到相应的反应。然后KdpSendWaitContinue等待从内核调试器发来的包含命令的包，决定下一步该干什么。让我们来看看KdpSendWaitContinue都能干些什么：
case DbgKdReadVirtualMemoryApi:
KdpReadVirtualMemory(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdReadVirtualMemory64Api:
KdpReadVirtualMemory64(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdWriteVirtualMemoryApi:
KdpWriteVirtualMemory(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdWriteVirtualMemory64Api:
KdpWriteVirtualMemory64(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdReadPhysicalMemoryApi:
KdpReadPhysicalMemory(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdWritePhysicalMemoryApi:
KdpWritePhysicalMemory(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdGetContextApi:
KdpGetContext(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdSetContextApi:
KdpSetContext(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdWriteBreakPointApi:
KdpWriteBreakpoint(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdRestoreBreakPointApi:
KdpRestoreBreakpoin(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdReadControlSpaceApi:
KdpReadControlSpace(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdWriteControlSpaceApi:
KdpWriteControlSpace(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdReadIoSpaceApi:
KdpReadIoSpace(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdWriteIoSpaceApi:
KdpWriteIoSpace(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdContinueApi:
if (NT_SUCCESS(ManipulateState.u.Continue.ContinueStatus) != FALSE) {
return ContinueSuccess;
} else {
return ContinueError;
}
break;
case DbgKdContinueApi2:
if (NT_SUCCESS(ManipulateState.u.Continue2.ContinueStatus) != FALSE) {
KdpGetStateChange(&ManipulateState,ContextRecord);
return ContinueSuccess;
} else {
return ContinueError;
}
break;
case DbgKdRebootApi:
KdpReboot();
break;
case :
(&ManipulateState,&MessageData,ContextRecord);
break;
case :
(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdSetSpecialCallApi:
KdSetSpecialCall(&ManipulateState,ContextRecord);
break;
case DbgKdClearSpecialCallsApi:
KdClearSpecialCalls();
break;
case DbgKdSetInternalBreakPointApi:
KdSetInternalBreakpoint(&ManipulateState);
break;
case DbgKdGetInternalBreakPointApi:
KdGetInternalBreakpoint(&ManipulateState);
break;
case DbgKdGetVersionApi:
KdpGetVersion(&ManipulateState);
break;
case DbgKdCauseBugCheckApi:
KdpCauseBugCheck(&ManipulateState);
break;
case DbgKdPageInApi:
KdpNotSupported(&ManipulateState);
break;
case DbgKdWriteBreakPointExApi:
Status = KdpWriteBreakPointEx(&ManipulateState,
&MessageData,
ContextRecord);
if (Status) {
ManipulateState.ApiNumber = DbgKdContinueApi;
ManipulateState.u.Continue.ContinueStatus = Status;
return ContinueError;
}
break;
case DbgKdRestoreBreakPointExApi:
KdpRestoreBreakPointEx(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdSwitchProcessor:
KdPortRestore ();
ContinueStatus = KeSwitchFrozenProcessor(ManipulateState.Processor);
KdPortSave ();
return ContinueStatus;
case DbgKdSearchMemoryApi:
KdpSearchMemory(&ManipulateState,&MessageData,ContextRecord);
break;
读写内存、搜索内存、设置/恢复断点、继续执行、重启等等，WinDBG里的功能是不是都能实现了?呵呵。
每次内核调试器接管系统是通过调用在KiDispatchException里调用KiDebugRoutine(KdpTrace），但我们知道要让系统执行到KiDispatchException必须是系统发生了异常。而内核调试器与被调试系统之间只是通过串口联系，串口只会发生中断，并不会让系统引发异常。那么是怎么让系统产生一个异常呢?答案就在KeUpdateSystemTime里，每当发生时钟中断后在HalpClockInterrupt做了一些底层处理后就会跳转到这个函数来更新系统时间（因为是跳转而不是调用，所以在WinDBG断下来后回溯堆栈是不会发现HalpClockInterrupt的地址的），是系统中调用最频繁的几个函数之一。在KeUpdateSystemTime里会判断KdDebuggerEnable是否为TRUE，若为TRUE则调用KdPollBreakIn判断是否有来自内核调试器的包含中断信息的包，若有则调用DbgBreakPointWithStatus，执行一个int 0x3指令，在异常处理流程进入了KdpTrace后将根据处理不同向内核调试器发包并无限循环等待内核调试的回应。现在能理解为什么在WinDBG里中断系统后堆栈回溯可以依次发现KeUpdateSystemTime->，系统停在了int 0x3指令上（其实int 0x3已经执行过了，只不过Eip被减了1而已），实际已经进入KiDispatchException->KdpTrap，将控制权交给了内核调试器。
系统与调试器交互的方法除了int 0x3外，还有DbgPrint、DbgPrompt、加载和卸载symbols，它们共同通过调用DebugService获得服务。
NTSTATUS DebugService(
ULONG ServiceClass,
PVOID Arg1,
PVOID Arg2
）
{
NTSTATUS Status;
__asm {
mov eax,ServiceClass
mov ecx,Arg1
mov edx,Arg2
int 0x2d
int 0x3
mov Status,eax
}
return Status;
}
ServiceClass可以是BEAKPOINT_PRINT(0x1）、BREAKPOINT_PROMPT(0x2）、BREAKPOINT_LOAD_SYMBOLS(0x3）、BREAKPOINT_UNLOAD_SYMBOLS(0x4）。为什么后面要跟个int 0x3，M$的说法是为了和int 0x3共享代码（我没弄明白啥意思-_-），因为int 0x2d的陷阱处理程序是做些处理后跳到int 0x3的陷阱处理程序中继续处理。但事实上对这个int 0x3指令并没有任何处理，仅仅是把Eip加1跳过它。所以这个int 0x3可以换成任何字节。
int 0x2d和int 0x3生成的异常记录结（EXCEPTION_RECORD)ExceptionRecord.ExceptionCode都是STATUS_BREAKPOINT(0x80000003），不同是int 0x2d产生的异常的ExceptionRecord.NumberParameters>0且ExceptionRecord.ExceptionInformation对应相应的ServiceClass比如BREAKPOINT_PRINT等。事实上，在内核调试器被挂接后，处理DbgPrint等发送字符给内核调试器不再是通过int 0x2d陷阱服务，而是直接发包。用M$的话说，这样更安全，因为不用调用KdEnterDebugger和KdExitDebugger。
最后说一下被调试系统和内核调试器之间的通信。被调试系统和内核调试器之间通过串口发数据包进行通信，Com1的IO端口地址为0x3f8，Com2的IO端口地址为0x2f8。在被调试系统准备要向内核调试器发包之前先会调用KdEnterDebugger暂停其它处理器的运行并获取Com端口自旋锁（当然，这都是对多处理器而言的），并设置端口标志为保存状态。发包结束后调用KdExitDebugger恢复。每个包就象网络上的数据包一样，包含包头和具体内容。包头的格式如下：
typedef struct _KD_PACKET {
ULONG PacketLeader;
USHORT PacketType;
USHORT ByteCount;
ULONG PacketId;
ULONG Checksum;
} KD_PACKET,*PKD_PACKET;
PacketLeader是四个相同字节的标识符标识发来的包，一般的包是0x30303030，控制包是0x69696969，中断被调试系统的包是0x62626262。每次读一个字节，连续读4次来识别出包。中断系统的包很特殊，包里数据只有0x62626262。包标识符后是包的大小、类型、包ID、检测码等，包头后面就是跟具体的数据。这点和网络上传输的包很相似。还有一些相似的地方比如每发一个包给调试器都会收到一个ACK答复包，以确定调试器是否收到。若收到的是一个RESEND包或者很长时间没收到回应，则会再发一次。对于向调试器发送输出字符串、报告SYMBOL情况等的包都是一接收到ACK包就立刻返回，系统恢复执行，系统的表现就是会卡那么短短一下。只有报告状态的包才会等待内核调试器的每个控制包并完成对应功能，直到发来的包包含继续执行的命令为止。无论发包还是收包，都会在包的末尾加一个0xaa，表示结束。
现在我们用几个例子来看看调试流程。
记得我以前问过jiurl为什么WinDBG的单步那么慢（相对softICE），他居然说没觉得慢?*$&$^$^(&(&；（我ft。现在可以理解为什么WinDBG的单步和从操作系统正常执行中断下来为什么那么慢了。单步慢是因为每单步一次除了必要的处理外，还得从串行收发包，怎么能不慢。中断系统慢是因为只有等到时钟中断发生执行到KeUpdateSystemTime后被调试系统才会接受来自WinDBG的中断包。现在我们研究一下为什么在KiDispatchException里不能下断点却可以用单步跟踪KiDispatchException的原因。如果在KiDispatchException中某处下了断点，执行到断点时系统发生异常又重新回到KiDispatchException处，再执行到int 0x3，如此往复造成了死循环，无法不能恢复原来被断点int 0x3所修改的代码。但对于int 0x1，因为它的引起是因为EFLAG寄存中TF位被置位，并且每次都自动被复位，所以系统可以被继续执行而不会死循环。现在我们知道了内部机制，我们就可以调用KdXXX函数实现一个类似WinDBG之类的内核调试器，甚至可以替换KiDebugRoutine(KdpTrap）为自己的函数来自己实现一个功能更强大的调试器，呵呵。

㈥ 如何给字符串下条件断点

SCII字符集字符串设抄置方法：
代码袭:
STRING
[eax]
==
"DDLX_CHAR"
STRING
[eax]
==
"DDLX_char"
//不区分大小写
STRING
[eax]
==
"DDLX"
//不区分文本长度
UNICODE字符集字符串设置方法：
代码:
UNICODE
[eax]
==
"DDLX_WCHAR"
UNICODE
[eax]
==
"DDLX_wchar"
//不区分大小写
UNICODE
[eax]
==
"DDLX"
//不区分文本长度
WinDbg
ASCII字符集字符串断点设置方法：
代码:
//全字符串匹配，区分大小写
bp
0041141d
"r
@$t1
=
eax;
as
/ma
${/v:pzString}
$t1;.if
($scmp(\"${pzString}\",\"DDLX_CHAR\")==0)
{}
.else
{gc}

㈦ WinDbg怎么用

什么是WinDBG? WinDbg是微软开发的免费源码级调试工具。Windbg可以用于Kernel模式调试和用户模式调试，还可以调试Dump文件。由于大部分程序员不需要做Kernel模式调试， 我在这篇文章中不会介绍Kernel模式调试。Kernel模式调试对学习Windows核心极有帮助。如果你对此感兴趣，可以阅读Inside Windows 2000和Windbg所带的帮助文件。这篇文章得主要目的是介绍WINDBG的主要功能以及相关的命令。关于这些命令的详细语法，请参阅帮助文件。对文章中提到的许多命令，WINDBG有相应的菜单选项。如何得到帮助在命令（Command）窗口中输入.hh 命会调出帮助文件令。.hh keyword会显示关于keyword的详细命令。启动DebuggerWindbg可以用于如下三种调试：远程调试：你可以从机器A上调试在机器B上执行的程序。具体步骤如下：
? 在机器B上启动一个调试窗口（Debug Session）。你可以直接在Windbg下运行一个程序或者将Windbg附加（Attach）到一个进程。? 在机器B的Windbg命令窗口上启动一个远程调试接口（remote）：.server npipe:pipe=PIPE_NAMEPIPE_NAME是该接口的名字。? 在机器A上运行：windbg –remote npipe:server=SERVER_NAME,pipe=PIPE_NAMESERVER_NAME是机器B的名字。Dump文件调试：如果在你的客户的机器上出现问题，你可能不能使用远程调试来解决问题。你可以要求你的用户将Windbg附加到出现问题的进程上，然后在命令窗口中输入:
.mp /ma File Name创建一个Dump文件。在得到Dump文件后，使用如下的命令来打开它：windbg –z DUMP_FILE_NAME本地进程调试：你可以在Windbg下直接运行一个程序：
Windbg “path to executable” arguments 也可以将Windbg附加到一个正在运行的程序： Windbg –p “process id” Windbg –pn “process name” 注意有一种非侵入（Noninvasive）模式可以用来检查一个进程的状态并不进程的执行。当然在这种模式下无法控制被调试程序的执行。这种模式也可以用于查看一个已经在Debugger控制下运行的进程。具体命令如下： Windbg –pv –p “process id” Windbg –pv –pn “process name” 调试多个进程和线程如果你想控制一个进程以及它的子进程的执行，在Windbg的命令行上加上-o选项。Windbg中还有一个新的命令.childdbg 可以用来控制子进程的调试。如果你同时调试几个进程，可以使用 | 命令来显示并切换到不同的进程。在同一个进程中可能有多个线程。~命令可以用来显示和切换线程。调试前的必备工作在开始调试前首先要做的工作是设置好符号（Symbols）路径。没有符号，你看到的调用堆栈基本上毫无意义。Microsoft的操作系统符号文件（PDB）是对外公开的。另外请注意在编译你自己的程序选择生成PDB文件的选项。如果设置好符号路径后，调用堆栈看起来还是不对。可以使用lm, !sym noisy, !reload 等命令来验证符号路径是否正确。Windbg也支持源码级的调试。在开始源码调试前，你需要用.srcpath设置源代码路径。如果你是在生成所执行代码的机器上进行调试，符号文件中的源码路径会指向正确的位置，所以不需要设置源代码路径。如果所执行代码是在另一台机器上生成的，你可以将所用的源码拷贝（保持原有的目录结构）的一个可以访问的文件夹（可以是网络路径）并将源代码路径设为该文件夹的路径。注意如果是远程调试，你需要使用.lsrcpath来设置源码路径。静态命令：显示调用堆栈：在连接到一个调试窗口后，首先要知道的就是程序当前的执行情况k* 命令显示当前线程的堆栈。~*kb会显示所有线程的调用堆栈。如果堆栈太长，Windbg只会显示堆栈的一部分。.kframes可以用来设置缺省显示框架数。显示局部变量：接下来要做通常是用dv显示局部变量的信息。CTRL＋ALT＋V可以切换到更详细的显示模式。关于dv要注意的是在优化过的代码中dv的输出极有可能是不准确的。这时后你能做的就是阅读汇编代码来发现你感兴趣的值是否存储在寄存器中或堆栈上。有时后当前的框架（Frame）上可能找不到你想知道的数据。如果该数据是作为参数传到当前的方法中的，可以读一读上一个或几个框架的汇编代码，有可能该数据还在堆栈的某个地址上。静态变量是储存在固定地址中的，所以找出静态变量的值较为容易。.Frame（或者在调用堆栈窗口中双击）可以用来切换当前的框架。注意dv命令显示的是当前框架的内容。你也可在watch窗口中观察局部变量的值。显示类和链表： dt可以显示数据结构。比如dt PEB 会显示操作系统进程结构。在后面跟上一个进程结构的地址会显示该结构的详细信息：dt PEB 7ffdf000。Dl命令可以显示一些特定的链表结构。显示当前线程的错误值：!gle会显示当前线程的上一个错误值和状态值。!error命令可以解码HRESULT。搜索或修改内存：使用s 命令来搜索字节，字或双字，QWORD或字符串。使用e命令来修改内存。计算表达式：？命令可以用来进行计算。关于表达式的格式请参照帮助文档。使用n命令来切换输入数字的进制。显示当前线程，进程和模块信息：!teb显示当前线程的环境信息。最常见的用途是查看当前线程堆栈的起始地址，然后在堆栈中搜索值。!peb显示当前进程的环境信息，比如执行文件的路径等等。lm显示进程中加载的模块信息。显示寄存器的值：r命令可以显示和修改寄存器的值。如果要在表达式中使用寄存器的值，在寄存器名前加@符号（比如@eax）。显示最相近的符号：ln Address。如果你有一个C＋＋对象的指针，可以用来ln来查看该对象类型。 查找符号：x命令可以用来查找全局变量的地址或过程的地址。x命令支持匹配符号。x kernel32!*显示Kernel32.dll中的所有可见变量，数据结构和过程。查看lock：!locks显示各线程的锁资源使用情况。对调试死锁很有用。查看handle：!handle显示句柄信息。如果一段代码导致句柄泄漏，你只需要在代码执行前后使用!handle命令并比较两次输出的区别。有一个命令!htrace对调试与句柄有关的Bug非常有用。在开始调试前输入：!htrace –enable 然后在调试过程中使用!htrace handle_value 来显示所有与该句柄有关的调用堆栈。显示汇编代码：u。程序执行控制命令：设置代码断点：bp/bu/bm 可以用来设置代码断点。你可以指定断点被跳过的次数。假设一段代码KERNEL32!SetLastError在运行很多次后会出错，你可以设置如下断点： bp KERNEL32!SetLastError 0x100.在出错后使用bl 来显示断点信息（注意粗体显示的值）：0 e 77e7a3b0 004f (0100) 0:*** KERNEL32!SetLastError重新启动调试（.restart命令）并设置如下的断点：bp Kernel32!SetLastError 0x100-0x4fDebugger会停在出错前最后一次调用该过程的地方。你可以指定断点被激活时Debugger应当执行的命令串。在该命令串中使用J命令可以用来设置条件断点：bp `mysource.cpp:143` "j (poi(MyVar)”0n20) ''; 'g' "上面的断点只在MyVar的值大于32时被激活(g命令条件断点的用途极为广泛。你可以指定一个断点只在特殊的情况下被激活，比如传入的参数满足一定的条件，调用者是某个特殊的过程，某个全局变量被设为特殊的值等等。设置内存断点：ba可以用来设置内存断点。调试过程中一个常见的问题是跟踪某些数据的变化。如下的断点：ba w4 0x40000000 "kb; g"可以打印出所有修改0x40000000的调用堆栈。控制程序执行：p, pa,t, ta等命令可以用来控制程序的执行。控制异常和事件处理：Debugger的缺省设置是跳过首次异常(first chance expcetion)，在二次异常(second chance exception)时中断程序的执行。sx命令显示Debugger的设置。sxe和sxd可以改变Debugger的设置。 sxe clr可以控制Debugger在托管异常发生时中断程序的执行。常用的Debugger事件有： av 访问异常 eh C++异常 clr 托管异常 ld 模块加载-c 选项可以用来指定在事件发生时执行的调试命令。