Windows內核分析索引目錄：https://www.cnblogs.com/onetrainee/p/11675224.html
INT 3 中斷調試處理流程
一、調試器如何下INT 3 斷點
1）首先，調試器使用 ReadProcessMemory，讀取斷點內存地址的字節。
2）之后，調試器再使用 WriteProcessMemory，將指定的內存地址指令寫為0xCC。
3）之后，當程序執行到這里，遇到CC指令，會從IDT表中查03號段描述符，其會定向到Trap03函數。
4）經過一系列操作（下面會介紹），此時調試器就會接收到INT 3中斷，程序暫停，用戶可以用來進行一些處理。
5）恢復時，將1）讀取的字節再重新寫入到CC處，這樣就可以保證程序的正常執行。
二、INT 3 異常指令如何派發到調試器
我們在 一、3) 中，其會經過 Trap03，因此INT3異常信息肯定是在這里發送的。
我們前面學過異常等派發，其檢測到存在三環調試器時會發送到三環調試器，因此其派發也就是在這時進行的。
派發流程大體如下：
三、上面產生的兩個疑問：
1）在 _kiDispatchException 中存在 dec eip，為什么調試器還需要修復 eip
注意：這個是Context.eip--，而三環與零環走的是 TrapFrame 結構。因此即使在這里 Context.eip--，調試器接收調試信息是關於TrapFrame的。
如果調試器沒有處理，則異常處理回重新回到三環，調用SEH異常處理結構，這時Context.eip就起作用了。
因此，調試器手動修復 INT 3 斷點時，必須將eip--，回到程序執行前。
2）為什么INT 3異常時不會走內核調試器
我們假設這種情況，利用windbg調試虛擬機，在此基礎上再虛擬機中開啟OD調試程序，這時你會發現，是OD接收異常，Windbg不會接收異常。
具體情況可以查看KiDispatchException函數，其調用內核調試器的代碼如下
1 if ((KiDebugRoutine != NULL) && 2 ((PsGetCurrentProcess()->DebugPort == NULL && 3 !KdIgnoreUmExceptions) || 4 (KdIsThisAKdTrap(ExceptionRecord, &ContextFrame, UserMode)))) { 5 // 6 // Now dispatch the fault to the kernel debugger. 7 // 8 9 if ((((KiDebugRoutine) (TrapFrame, 10 ExceptionFrame, 11 ExceptionRecord, 12 &ContextFrame, 13 PreviousMode, 14 FALSE)) != FALSE)) { 15 16 goto Handled1; 17 } 18 }
可以查看 _KdIsThisAdktrap函數，當存在三環調試器時，對於INT 3 異常不會走內核調試器。
四、異常處理的整體流程
