看懂了你所要说明的技术问题,但跟不上你的思路
继续学习

不懂驱动，不过我想这个跟驱动关系不大。之所以读0异常是因为SICE在R0级，除非他自己，否则没人接管他的异常。我记得那篇文章里面说，想想运行在R0的程序出现这种情况。。。。，也相当于告诉我们这个道理。

照这种想法，我们平时读0也是应该蓝屏的，不过操作系统给接管了而已。个人看法，不知道对错。

SICE提升一些属性我想未必用api，不过分析SICE的结构值得研究，曾经见过国外一牛人分析出来SICE的断点结构，不知道如何下手。

SICE 4.31断点的结构

作者：Kayaker  

SICE 4.31断点的结构，由于这个结构有“TDJF”串作为标记，所以姑且叫做TDJF：

0000 BREAKPOINT_INFO struc ; (sizeof=0x178)
     0000 ascii_TDJF_1    db 4 dup(?)  ; "TDJF"
     0004 Breakpoint_Type db ?         ; BPINT = 01h
     0004                              ; BPM/BPIO = 03h
     0004                              ; BPX = 05h
     0004                              ; BMSG = 06h            
     0004
     0005 Enabled_Flag    db ?         ; toggled with BE, BD
     0006 DRx_Register    db ?         ; DR3=83h, DR2=82h, DR1=81h, DR0=80h
     0006                              ; used with BPM/BPIO breakpoints
     0006                                    
     0007 Address_1       dd ?         ; Breakpoint address or BPIO port number
     000B Address_2       dd ?         ; unknown usage
     000F Breakpoint_Mode db ?         ; execute = 0
     000F                              ; write = 1
     000F                              ; read = 2
     000F                              ; read/write = 3
     000F                                          
     0010 unknown_dword_1 dd ?
     0014 CodeSegment_CS  dw ?         ; 0008, 001B, etc.
     0016 unknown_03h     db ?         ; seems to be 3 for all BP types
     0017 Address_1_repeat dd ?        ; Duplicate BP address
     001B unknown_word_1  dw ?
     001D unknown_byte_1  db ?
     001E unknown_dword_2 dd ?
     0022 unknown_dword_3 dd ?
     0026 unknown_dword_4 dd ?
     002A unknown_byte_2  db ?
     002B BMSG_hWnd       dd ?         ; Class handle for BMSG breakpoints
     002F unknown_word_2  dw ?
     0031 unknown_byte_3  db ?
     0032 unknown_byte_4  db ?                     
     0032                               ;
     0033 unknown_dword_5 dd ?
     0037 unknown_dword_6 dd ?
     003B unknown_dword_7 dd ?                     
     003B                               ;
     003F unknown_byte_5  db ?
     0040 unknown_byte_6  db ?
     0041 unknown_byte_7  db ?
     0042 unknown_byte_8  db ?                     
     0042                               ;
     0043 unknown_dword_8 dd ?
     0047 unknown_dword_9 dd ?
     004B unknown_dword_10 dd ?
     004F unknown_dword_11 dd ?
     0053 unknown_dword_12 dd ?
     0057 unknown_dword_13 dd ?
     005B unknown_dword_14 dd ?
     005F unknown_dword_15 dd ?
     0063 unused_dword_1  dd ?
     0067 unused_dword_2  dd ?
     006B Length_Module_Name db ?      ; byte length of string that follows
     006C Module_Name_String db 264 dup(?)   ; Name of process (breakpoint context)
     0174 ascii_Tdjf_2    db 4 dup(?)  ; "TDJF"
0178 BREAKPOINT_INFO ends

最初由 nbw 发布
不懂驱动，不过我想这个跟驱动关系不大。之所以读0异常是因为SICE在R0级，除非他自己，否则没人接管他的异常。我记得那篇文章里面说，想想运行在R0的程序出现这种情况。。。。，也相当于告诉我们这个道理。

照这种想法，我们平时读0也是应该蓝屏的，不过操作系统给接管了而已。个人看法，不知道对错。

SICE提升一些属性我想未必用api，不过分析SICE的结构值得研究，曾经见过国外一牛人分析出来SICE的断点结构，不知道如何下手。

是被os接管了的。不过sice没有写错误处理，结果就没有人处理了。

不过玩r0最简单的就是drv了嘛

事实求真..