使用VS调试时，被调试进程如何被断下来的。

不是什么新鲜的东西，很多书上写的非常详细了，不过有人问到，简要的扯下这个VS如何断下进程的。

++++++++++++++++++++++++++

当用VS的时候，按下F10后，为什么能够停在程序的入口处呢?

这个问题首先从windows API CreateProcess的Process Creation Flags说起。如果在创建进程的时候加了这个DEBUG_PROCESS这个flag. 那么进程环境块(Process environment block, 简称PEB)中的BeingDebugged设为1. 如果用Windbg的命令!peb来看的话

0:000> !peb
PEB at 7ffd8000
    InheritedAddressSpace:    No
    ReadImageFileExecOptions: No
    BeingDebugged:            Yes <== 这个是yes.

下一步是LdrpInitializeProcess函数被调用来初始化进程的时候，这个函数会去检查BeingDebugged这个位，如果为1的话，就会调用函数ntdll!DbgBreakPoint这个函数。

比如说用windbg来开始调试notepad.exe的话，首先断下来的地方在ntdll!DbgBreakPoint函数里

0:000> kL
ChildEBP RetAddr  
0007fb1c 7c940442 ntdll!DbgBreakPoint
0007fc94 7c9210af ntdll!LdrpInitializeProcess+0xffa
0007fd1c 7c90e457 ntdll!_LdrpInitialize+0x183
00000000 00000000 ntdll!KiUserApcDispatcher+0x7

这个函数非常简单，只有一个int 3指令。

ntdll!DbgBreakPoint:
7c90120e cc              int     3
7c90120f c3              ret

这里是任何debuger第一次断下来进程的地方。无论是windbg还是VS.

在这个时候notepad.exe的binary已经被load到内存里面了，但是还没有开始执行。这个时候VS就可以加载符号文件，并且知道用户写的代码的入口在什么地方。于是在入口处设下一个断点，然后直接恢复进程的执行，而用户并不会察觉到其实VS debuger已经中断过进程一次了，而是直接发现程序停在了main处。

哪么调试器的attach功能，和break当前被调试的进程又是如何实现的呢？程序已经跑起来了，这个时候可能没有被设置任何一个断点。

这个是利用Windows API CreateRemoteThread来实现的。调试器会调用这个函数在目标进程中创建一个线程，这个线程执行的代码如下:

00adffc8 7c951e40 ntdll!DbgBreakPoint
00adfff4 00000000 ntdll!DbgUiRemoteBreakin+0x2d

还是ntdll!DbgBreakPoint这个函数，由于这个函数里面有个int 3指令。CPU执行到了int 3指令的时候就会触发异常处理，最终debuger会处理这个异常，并且把进程中的所有线程挂起。

在windbg中可以看到notepad.exe被断下来以后有2个线程:

0:001> ~*
   0  Id: 4b8c.3dd4 Suspend: 1 Teb: 7ffde000 Unfrozen
      Start: notepad!WinMainCRTStartup (0100739d)  
      Priority: 0  Priority class: 32  Affinity: 3
.  1  Id: 4b8c.4c14 Suspend: 1 Teb: 7ffdd000 Unfrozen
      Start: ntdll!DbgUiRemoteBreakin (7c951e13)  
      Priority: 0  Priority class: 32  Affinity: 3

线程0就是notepad本身的main thread.

线程1就是远程创建的线程。

当然在VS debuger里面不会看到ntdll!DbgBreakPoint这个函数，因为VS比较友好，会自动把当前处理了的线程切换到main thread上面。