我做了一些功课，目前得到的信息包括：卡顿的性能问题来自两个方面：1、com线115200bps的连接速率为卡顿做了很大贡献2、windbg与com口通信的协议也影响速率现在我有两个思路：1、通过VMWare虚拟机，看看能不能通过火线1394或者usb来实现双机调试，以此解决卡顿问题2、通过火线（或者usb线）将两台实体机相连，解决问题目前两个思路，都遇到了瓶颈1、VMWare对火线和usb连接的支持，目前没找到相关资料（找到的资料都是泼冷水的<汗>）2、真机实线连接的话，我的pc没有1394口，另外usb线好像很贵，而且不太好买，现在我的内心有点崩溃

我自己用DbgEng.dll导出的api写了一个内核调试器，使用VMWare双机调试的模式，我尝试在某个驱动文件中下断后，可以正常获得断电命中的调试事件。但是，我遇到了两个严重的问题：1、设置断点的速度很慢，比如我设置1万个断点，光断点设置就要20分钟以上。2、断点命中的速度也很慢，从断点命中到反映到调试器，再到断电恢复，每个断点到需要1s左右。在断点数量较多时，这个性能显然不能接受。因为是使用com口115200来连接的，我想问下这些性能问题是因为com的连接虚拟机的方式带来的（我是否可以考虑换真机或者其他连接模式<网络or火线>）还是windows调试引擎的设计就是如此的性能表现。

虚拟机内核调试kd> uf ...

问题定位到了，是被驱动拦截了，这个函数被驱动hook了

我写了个用户态调试器，在断点命中的时候，断点处理函数里面恢复断点，用SetThreadContext把eip减1，总是调用失败，请问下调试器对于被调试进程里面的线程是不是也有权限限制？要是有的话，该怎么解决这个问题？

这种情况是我在实际代码中遇到的情况。一般是switch语句会出现这种代码生成void foo(){ switch(bar) { ... }*}在标*位置下断有几率触发上述问题。硬件断点的数量有限，需求要求设置多个断点。我找到一个方式规避：这种问题一般发生在函数末尾的“}”处，我设置断点的时候，把函数最后一行都屏蔽了。

不好意思张老师，现在才回你。    我构造了一个简单的列子，在HelloWorld.exe:0x412d7d处的反汇编是jmp DWORD PTR [edx*4+0x4136c0]edx的值为0x10 实际上是从0x413700处取地址来跳转的。但是这个位置是有对应源码的，如果在这里下断，就会导致跳转到意料之外的地方（地址中裹夹了一个断点），本来是要跳转到0x412e9b的结果跳到了0x412ecc这个在程序中一般意味着“访问违规”。 请问下张老师，有没有什么好的办法规避掉这种情况。 ...

调试过程中，在特定地址下断后，触发access validation，定位后发现情况如下mov eax, [address_x]jmp eax在address_x位置包含了一个断点，这样跳转后地址肯定不对了，指令就乱序了。我的问题是：有没有什么方法可以识别出这样的行进行规避？补充：我确实是在代码的某一行有效行进行下断的。这行是函数末尾的大括号。

这个问题后面我定位了一下，这里出问题的位置是函数结尾的大括号，我看了反汇编，这个内存位置存储的是一个jmp指令的地址，在这里插入断点之后，自然会出问题。问题的应该是release优化引起的。

哈哈，找到答案了，应该是Cv info结构体里面的age字段，表示版本的vs05生成的是1，vs10生成的是2。大概是这样了。