Boxcounter 的烂笔头 - All Forums

关于STATUS_INVALID_DEVICE_OBJECT_PARAMETER和STATUS_MOUNT_POINT_NOT_RESOLVED

Sun, 20 May 2012 10:51:16 +0800

boxcounter
2012-05-20 周日

很久之前，我写了篇关于STATUS_INVALID_DEVICE_OBJECT_PARAMETER的blog，里面提到使用STATUS_REPARSE的FsFilter（后简称为R-FsFilter）对上层FsFilter造成的恶劣干扰。

这两天看Alex Carp的文章，发现事情貌似有转机。具体参考他的Reparsing to a Different Volume in Win7 and Win8（需要爬墙）。

我总结一下：
目前的win8提供了一种新的ECP和相应的数据结构，保证在返回STATUS_MOUNT_POINT_NOT_RESOLVED的时候开发者可以获得目标FO的FLT_FILE_NAME_INFORMATION和FLT_INSTANCE。
用我那篇blog的原型就是，当驱动A调用FltCreateFile失败后（Alex的文章里只提到了STATUS_MOUNT_POINT_NOT_RESOLVED，但我猜测对STATUS_INVALID_DEVICE_OBJECT_PARAMETER应该也是适用的，我还没有动手测试，只是看IopCheckTopDeviceHint的实现做出的猜测），可以从ECP中获取到本次打开操作的目标FO的FLT_FILE_NAME_INFORMATION和FLT_INSTANCE，然后再次FltCreateFile就可以了。

说来简单，但实际上影响挺大的，这相当于要求所有的FsFilter开发者在调用FltCreateFile时都处理这种错误。仅仅是因为目标系统里可能会存在一个R-FsFilter。

相信不会有太多的开发者会多写这些代码。
而且这个错误对上层FsFilter的开发者来说根本就不是问题。如果在客户机上出现这种问题，完全可以如此解释：“你看，卸载您安装的这个产品（姑且称为T）的驱动后，我公司的产品就能正常工作了。但是只要一安装它，我公司的产品就出问题了，你看你看，另一个公司的产品也不能工作了。这明显是T的问题，跟我公司的产品没有半毛钱关系。”

悲催的是R-FsFilter开发者，知道问题有解决方案，但是却不能在自己的代码里解决……。

或者，R-FsFilter开发者在开发完之后，再多写一个紧贴着它的上层驱动，专门处理STATUS_MOUNT_POINT_NOT_RESOLVED/STATUS_INVALID_DEVICE_OBJECT_PARAMETER？这要求必须使用支持固定加载层次的minifilter框架，并且MS要足够给面子提供两个相邻的Altitude，不过以我之前申请Altitude的经验，貌似有些难度。

另外推荐Alex-Cap的几篇关于reparse技术的博文。其实他blog的每篇技术文章都推荐仔细阅读，我几乎备份了他所有的博文……

注：由于本人能力有限，行文难免有错，请不吝赐教邮件联系（ns.boxcounter[a]gmail.com，博客里垃圾回复太多了，人工删不过来，所以禁用回复功能了），感谢。

2012-5-4的一些唠叨

Tue, 08 May 2012 17:42:28 +0800

趁着五一假期，把年假请了回家探亲。

老爹修佛，从开始修到如今5年多，时间虽不长，但是很虔诚。最近的四年大部分时间都在当阳玉泉寺修行。目前受的是菩萨戒。

我回家，老爹自然想熏陶熏陶我，于是每天我在家陪他聊天，聊不了多久他就会聊到佛相关的话题上，然后就开始强烈建议我看看一些佛学论坛，是真正的论坛，不是网络BBS。里面是一些修佛居士在里面忏悔自己做过的错事，或者讲述自己的心得等等。一般我会非强烈抗议然后逃之夭夭。有时候实在溜不掉就只好从这些佛学相关视屏里挑点清淡的，比如主题为修佛或者某位法师传记类的连续剧。看得次数最多的是《百年虚云》，讲的是晚清虚云法师一生的，片子是他的弟子释本焕长老监制拍摄的，也就是深圳弘法寺的本焕长老。目前玉泉寺主持也是虚云法师的弟子。

我只看了个开头，从虚云法师出生到他出家修行约莫十年的光景。有一段让我点想法想唠叨。

虚云法师是在娶妻2年后从家中逃离，然后出家。没有事先告知父母，只是妻子偷听得知了这一事情。出家后，父母妻妾四处找寻，多年后终于寻访到他的下落。但是虚云法师坚决的拒绝掉了所有的探访，其妻设计见到了他，也被他坚决请回。他的父亲当时是一名官员，于是使用了一些手段想强行带他走，于是虚云法师只好跑到庙的后山，找个洞继续修行。最后他的父亲年事高、身体差，辞官回家前颤巍巍的爬上后山呼唤他，想见他最后一面。虚云法师心有不忍，但也最终没有见父亲。最后，辞官、有病的父亲回老家后为了治病耗尽了家里所有的财产，连最后一栋老房子也卖了，虚云法师的母亲和妻妾都决定出家。后面的情节我没有再看下去了。

我想唠叨的是，虚云法师这种做法该如何解读？

我问过我老爹，明显我老爹没有纠结过这段情节，只好喃喃回答：“虚云法师是为了度众生”，话外之音应该就是所谓“舍小家为大家”。

但是我的理解是，连自己的生身父母都不在乎的人，他会在乎别人的父母，会在乎众生？或者说，会有多在乎众生？换句话说，“一屋不扫，何以扫天下？”。当年苏东坡和朋友（经查证，是章惇，参见《帝国政界往事》）一起去到一处险景游玩，有一条深涧，朋友抓着树藤荡到对面的石壁上提了类似“XX与XXX到此一游”的字，然后荡回来。苏东坡感叹，如果这个朋友当政，苍生可能要受苦了。苏东坡的解释是，他连自己的命都不在乎，又怎么会在乎别人的命。最后的事实也确实如东坡先生所感叹。

我所了解的各种宗教信仰、思想，都明确的肯定孝道。诸如儒、天主、基督、佛，前三者就不用说了，佛家《地藏经》主要就是讲孝道的。

按我的想法，一个虔诚的信徒，应该在尽完孝道之后，再去修自己的行。退一步说，即便做不到服侍双亲于身前直至双亲离世，也应该做好充足的准备（如几亩薄田，几名家仆等）后，再离开。

电视中（我不清楚现实中是否如此）虚云法师的这种做法最后的结果是这么的凄惨，我不清楚是监制本焕大师有意为之以凸显虚云法师心怀佛祖心怀苍生之胸怀，还是只是想原原本本的呈现出事实。但是就我而言，我想到了建国初期风靡全国的“光荣事迹”：某某为了练好最后一炉钢、割完最后一拢麦，连临终的父母都顾不上看一眼，让亲人抱憾离世。这种做法我觉得是完完全全彻彻底底的混蛋做法，其背后隐藏的是一种畸形的思想推动力。借用迂阔的儒家说法，这有悖人伦。这种做法我能接受的原因底线是：如果不这么做会导致千千万万个生命、家庭受到惨痛的损失。比如：你是一名正在领导卫国战争的高级将领，离岗奔丧可能会导致国破家亡。

也许虚云法师也许真能做到决然拒老父却又慈悲度苍生，但我真心不认为这种做法值得信徒称道。

这个想法就先唠叨到这，目前就这么些想法，以后想到别的了再补充。

还有一个跟佛家相关的问题。

有不少修佛人被问道修佛的原因，或者向别人传道时候，都会说：“修佛能死后入西方极乐世界”。这种说法是不是也是一种利益诱惑？

另外我还见过这样的传道：把原本“信佛，佛祖保佑你”布道成“不信佛，佛祖就惩罚你”，不知道天上的佛祖看到如此信徒，是不是也会有一种淡淡的忧伤于胸中。也许参差不齐的信徒才是佛家宗旨的最大破坏源。

其实原本还有一个话题想说说的，结果写到这里记不起来主题是什么了……以后想起来再侃吧。

注：我并不反对宗教信仰，比如说我其实很支持我父母信佛，老人有精神寄托是件好事，积德行善总是好的。我也不是坚定的科学主义者，世间貌似有不少事情无法用现在的科学来解释。科学与宗教也许只是解释这个世界的不同方法。对于带有所谓“迷信思想”的宗教信仰，我的态度是，不全信，也不完全不信。

一个内核资源泄漏样本

Thu, 05 Apr 2012 14:43:44 +0800

开发过程中，我习惯会一直开着verifier进行测试，绝大部分非逻辑错误都能被揪出来。
这两天测试部的同事反馈说貌似驱动有资源泄漏，我第一反应是“不会吧，有资源泄漏verifer早崩了”。
测试了一下，发现还真是驱动嫌疑最大，于是开启verifer和压力测试工具，跑了一会，停掉驱动。发现没有bsod，一脑子不理解。
看了下驱动停止后，内核内存情况：

Code:

0: kd> !poolused 7

   Sorting by  NonPaged Pool Consumed

  Pool Used:

            NonPaged                    Paged

 Tag    Allocs    Frees     Diff     Used *  Allocs    Frees     Diff     Used

 Proc    12980        1    12979  8618056 *       0        0        0        0    Process objects , Binary: nt!ps

 LSwi        1        0        1  2576384 *       0        0        0        0    initial work context 

 SePa   955604   942626    12978  2247904 *      17       16        1       16    Process audit image names and captured polity structures , Binary: nt!se

 TCPt    47617    47580       37  1423848 *       1        1        0        0    TCP/IP network protocol , Binary: TCP

 SeTd   372125   359104    13021   833344 *  372125   359104    13021  1145088    Security Token dynamic part , Binary: nt!se

 .... 省略若干不相干信息

 SEY6        0        0        0        0 *       1        1        0        0    UNKNOWN pooltag 'SEY6', please update pooltag.txt

 SEYC  1448369  1448369        0        0 *       0        0        0        0    UNKNOWN pooltag 'SEYC', please update pooltag.txt

 SEYB        0        0        0        0 *   47738    47738        0        0    UNKNOWN pooltag 'SEYB', please update pooltag.txt

 SEY5        0        0        0        0 *       1        1        0        0    UNKNOWN pooltag 'SEY5', please update pooltag.txt

 SEYA    46294    46294        0        0 *       0        0        0        0    UNKNOWN pooltag 'SEYA', please update pooltag.txt

 SEY4  1186033  1186033        0        0 *       0        0        0        0    UNKNOWN pooltag 'SEY4', please update pooltag.txt

 SEY3        1        1        0        0 *       1        1        0        0    UNKNOWN pooltag 'SEY3', please update pooltag.txt

 SEY9        0        0        0        0 *   47008    47008        0        0    UNKNOWN pooltag 'SEY9', please update pooltag.txt

 SEY2        0        0        0        0 *       1        1        0        0    UNKNOWN pooltag 'SEY2', please update pooltag.txt

 SEY1        0        0        0        0 *   54507    54507        0        0    UNKNOWN pooltag 'SEY1', please update pooltag.txt

 SEYD  1419958  1419958        0        0 *       0        0        0        0    UNKNOWN pooltag 'SEYD', please update pooltag.txt

 .... 省略若干不相干信息

 TOTAL    79306657 79234060    72597 22806272 38472704 38412253    60451 29841272

其中SEY?就是我的驱动使用的tag，发现没有泄漏，更一头雾水了。
最后瞅到第一行，nnd，'Proc'这个tag明显有问题，基本没释放。
检查了一下代码，发现之前从网上摘的一段获取进程路径的函数，里面的错误结束分支没有释放EPREOCESS和句柄……
赶紧改掉了，这个bug存在了好多年啊，横跨我的几个驱动，之前从osr上摘下来的时候只是稍微调整了一下功能，没有再仔细审查……
警钟警钟~
有从我那篇《驱动中获取进程完整路径名》里拷代码的朋友也赶紧更新吧，对不住大伙~

两点体会：
1. 别偷懒。不是自己写的代码更要仔细检查，哪怕出自osr这种权威级论坛。
2. verifer不是万能的（至少在win2k3之前的版本），别偷懒。
3. 别偷懒。

灵异现象？

Sun, 04 Mar 2012 15:11:58 +0800

前两天遇到一个灵异现象，记录下来。

C代码

Code:

cchFullHeaderLen += strlen("Request-Line: ") +

                        strlen(pSessionData->HttpOpenReq.lpszVerb) +

                        strlen(" ") +

                        strlen(pSessionData->HttpOpenReq.lpszObjectName) +

                        (NULL != pSessionData->HttpOpenReq.lpszVersion) ? (strlen(" ") + strlen(pSessionData->HttpOpenReq.lpszVersion)) : 0 +

                        strlen("\r\n");

调试的过程中发现，pSessionData->HttpOpenReq.lpszVersion为NULL，但是依然会执行“(strlen(" ") + strlen(pSessionData->HttpOpenReq.lpszVersion))”。

确认不是编码错误后，反汇编调试：

Code:

Boxr!MyFunction+0x2b2

6a515742  xor     edx,edx

6a515744  cmp     dword ptr [ecx+23Ch],0

6a51574b  setne   dl

6a51574e  add     esi,edx

6a515750  je      Boxr!MyFunction+0x2ed (6a51577d)

6a515752  push    offset Boxr!std::_Arithmetic_traits::_Rank+0xc88 (6a5fc0f8)

6a515757  call    Boxr!strlen (6a5b5bd0)

6a51575c  add     esp,4

其中ecx+23Ch就是pSessionData->HttpOpenReq.lpszVersion，查看如下：
0:005> dd ecx+23c
0a27b18c 00000000

确认pSessionData->HttpOpenReq.lpszVersion确实为NULL。
理论上6a515750处的跳转会执行的，但是没有。单步跟踪：

Quote:0:005> p
eax=00000014 ebx=00cc000c ecx=0a27af50 edx=00000000 esi=00000027 edi=0485d5ec
eip=6a515744 esp=0485d518 ebp=0485d5f8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
Boxr!MyFunction+0x2b4:
6a515744 cmp dword ptr [ecx+23Ch],0 ds:0023:0a27b18c=00000000

0:005> p
eax=00000014 ebx=00cc000c ecx=0a27af50 edx=00000000 esi=00000027 edi=0485d5ec
eip=6a51574b esp=0485d518 ebp=0485d5f8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
Boxr!MyFunction+0x2bb:
6a51574b setne dl

0:005> r zf
zf=1

0:005> p
eax=00000014 ebx=00cc000c ecx=0a27af50 edx=00000000 esi=00000027 edi=0485d5ec
eip=6a51574e esp=0485d518 ebp=0485d5f8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
Boxr!MyFunction+0x2be:
6a51574e add esi,edx

0:005> r zf
zf=1

0:005> p
eax=00000014 ebx=00cc000c ecx=0a27af50 edx=00000000 esi=00000027 edi=0485d5ec
eip=6a515750 esp=0485d518 ebp=0485d5f8 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
Boxr!MyFunction+0x2c0:
6a515750 je Boxr!MyFunction+0x2ed (6a51577d) [br=0]

0:005> r zf
zf=0

可以看出，原本是准备要跳转的，但是
6a51574e add esi,edx
这条指令改变了zf寄存器，于是没有跳转。

那这条指令是干什么的呢？怎么会有这么一条指令？
最开始怀疑是编译器优化出问题了。
于是准备以发现编译器优化错误为主体写一篇BLOG。

但是在整理本文的过程中，仔细分析了一遍汇编代码，发现，丫是个低级错误 —— 运算符优先级错误……
实际上，C代码真正的执行逻辑是这样的：

cchFullHeaderLen +=
(strlen("Request-Line: ") + strlen(pSessionData->HttpOpenReq.lpszVerb) + strlen(" ") + strlen(pSessionData->HttpOpenReq.lpszObjectName) + (NULL != pSessionData->HttpOpenReq.lpszVersion) )
?
(strlen(" ") + strlen(pSessionData->HttpOpenReq.lpszVersion))
:
( 0 + strlen("\r\n") );

我的编码风格PPT又多了一条素材……

日记之2012-2-22

Wed, 22 Feb 2012 22:16:54 +0800

今天是个好日子，值得写点什么。

早上mrcool同学Q上找我，说好久没看我更新BLOG了，写点吧。说话的语气让我不由得联想到了《记念刘和珍君》里的片段：

Quote: ……，遇见程君，前来问我道，“先生可曾为刘和珍写了一点什么没有？”我说“没有”。她就正告我，“先生还是写一点罢；刘和珍生前就很爱看先生的文章。”

虽然情节差十万八千里，但是当时的断句确实让我想起了这段~

最近生活比较平淡，这也让觉得“快乐要建立在别人的痛苦之上”这句话有时候还挺靠谱的：自从mrcool闪了之后，身边就很少发生什么惨事值得为之高兴了。于是大伙只好经常翻出“当年mrcool掉进下水道”，“当年mrcool……”等陈年记忆回味回味，聊以助兴。

生活中总要有些比较貳的人才好玩，mrcool不在了，我把目光锁定在了媳妇身上~
我： “黑旋风”是谁？
媳妇：张飞。
我： - -| 是李逵，要多读点书，你就是吃了没文化的亏所以才这么容易被我骗到手 ……

隔了些日子，
我： “黑旋风”是谁？
媳妇：李逵~
我：你再想想？
媳妇： ~ 张飞。

又过了些日子，
我： “黑旋风”是谁？
媳妇：李逵！
我：你再想想？
媳妇：就是李逵！你别想再糊弄我！

最近几个月，自己有了点改变，起因是几个月前给自己订的一个小任务。

大概是去年10月份，决定多花点时间练习下英语，就给自己下了个任务：每天看英文资讯，比如BBC新闻。

最开始的那些天是一天一篇长篇新闻，大概需要20分钟，不少生词。于是找了个小本，把遇到的生词都记下来。这个习惯坚持到了现在，4个月了，昨晚统计了一下，本子上记了400个单词。平均100个生词/月，3~4个/天，算下来速率不快，但是累积下来的成果还是挺丰硕的。现在看BBC上的新闻（通常看亚洲区新闻，特别是中国相关的）比较轻松了，有时候通篇下来都遇不到生词。

曾经在某个帖子里看一个旅美华人谈及学英语的时候提到常用单词约莫有2K~3K个。这样算下来。再坚持个1、2年也就能达到这个基本水准线了。不过这种学习方式仅适合我这样不急着考英语等级的人。

另外，NBA.COM和英文原著的书也是挺好的学习素材。至于学习的方法，很笨很简单 —— 翻来覆去的背。我一般是在上班的路上背，反正闲着也是闲着。隔两天就从头背一遍。另外，感觉这种记单词的方法比抱着本单词册子背要高效一些，至少背的时候能大概想起这个单词是在什么内容什么场景下出现的。目前这个400个单词记得都挺熟的，不管是英译汉还是汉译英。

貌似是11月的时候，也就是坚持了一个月后，看着小本子（当时一页最多只能记10个单词，而我习惯加上日期和空行，所以一页一般就6、7个单词。现在换大本了，一页通常能记13个单词）上有点厚度的单词表，还是蛮有成就感的。不由得感叹坚持的力量真强大。

于是又给自己增加了点任务：锻炼身体。

最开始是每天晚上回家后做仰卧起坐、哑铃锻炼等等。坚持了两个星期，感觉太花时间了，几组轮下来，一个小时就过去了。于是开始精简，去掉哑铃项目，改成4*50仰卧起坐+4*10仰卧抬腿（健身房里学的一种动作的简化版，没学名，姑且这么叫吧），后来增加到4*70+4*20，一直坚持到现在。效果挺好的，现在周末打球的时候跳投稳定性好多了。

上周起又增加了一个哑铃项目，锻炼肩膀。晚上的时间是不够了，改到早上起床后做。目前才开始不到半个月，效果有待观察。

此外还有一个值得庆祝一下的小成就，从去年貌似4月开始一直坚持早起到现在。一般是7点起床，去年下半年因为媳妇上早自习的原因，坚持了半年的6点起床。起床后到出门上班，大概有2个小时的时间，有时候拿来读书，有时候做分析。基本上都花在学习上了。

这几件事给我的警示很深刻。看起来小小的、不起眼的付出，坚持一段时间，回来再看，会发现收获颇丰。

也让我转变了一些态度，更愿意埋头多做一些灰土土朴实实的工作，慢慢积累。比如打篮球，高中时候喜欢艾佛森，于是就练有视觉效果的控球，练大幅度的晃动。在大学里的时候靠着突破和抽风式的投篮还是能混混的。后来慢慢发现，球场上最NB的还是无解的中投和扎实的控球。现在周末都会老老实实的在楼下的破球场练几个小时的基本功，比如中投，基础控球，上场了之后更多的进行无球跑动穿插，而不再是站着等球。感觉还是有些长进的。

总之，一句话：积硅步以至千里积小流以成江海。

继续坚持下去，过段时间回头再看本文，也许会有更深刻的感触。

2012-2-22

TEB KPCR GS in x64

Wed, 08 Feb 2012 09:01:51 +0800

在x86中，如果折腾TEB或者KPCR，可能需要处理fs:[0x???]这样的地址，在x86中，咱们可以通过dg命令来手动查看：
kd> dg @fs
P Si Gr Pr Lo
Sel Base Limit Type l ze an es ng Flags
---- -------- -------- ---------- - -- -- -- -- --------
0030 ffdff000 00001fff Data RW Ac 0 Bg Pg P Nl 00000c93

ffdff000+0x???就是要找的地址了。
当然，也可以从GDTR开始从头完全手动找，不过要麻烦一些。

到了x64，TEB和KPCR都改由gs来索引了，上述dg或者GDTR方法就不灵了。
1: kd> dg @gs
P Si Gr Pr Lo
Sel Base Limit Type l ze an es ng Flags
---- ----------------- ----------------- ---------- - -- -- -- -- --------
002B 00000000`00000000 00000000`ffffffff Data RW Ac 3 Bg Pg P Nl 00000cf3
Base为0是因为flat模式。
那么x64中我们如何手动查看gs:[0x???]呢？

首先需要说明的是，在x64中，gs的base内容已经挪到MSR(Model-Specific Registers) (boxcounter: 可参考注1)，需要使用如下方法：
1: kd> rdmsr 0xC0000101
msr[c0000101] = fffff880`009f2000
此时gs:[0x???]指示的地址是fffff880`009f2000+0x???
其中0xC0000101就是gs的地址，每个MSR寄存器都有一个地址(boxcounter: 可参考注2)。
再来校验一下：
1: kd> !pcr
KPCR for Processor 1 at fffff880009f2000:
...[省略余下无关输出内容]

注：
1. 出自《AMD64 Architecture Programmer's Manual Volume 2 [System Programming]》的“2.2.3 Segmentation”的“The FS and GS descriptor base-address fields are expanded to 64 bits and used in effective-address
calculations. The 64 bits of base address are mapped to model-specific registers (MSRs), and can .only be loaded using the WRMSR instruction.”
2. 出自《Intel® 64 and IA-32 Architectures Software Developer's Manual [Volume 3B - System Programming Guide, Part 2]》中的“Appendix B Model-Specific Registers (MSRs)”的“Table B-2. IA-32 Architectural MSRs (Contd.)”

参考资料：
1. AMD64 Architecture Programmer's Manual
2. Intel® 64 and IA-32 Architectures Software Developer's Manual

加强版的OsrNTStatusToString

Wed, 01 Feb 2012 10:47:05 +0800

之前一直用osr的OsrNTStatusToString来显示NTSTATUS的字符串形式，很省事。但是有个缺陷，osr应该是基于比较早的ntddk来整理的，不全，比如minifilter专用的NTSTATUS。
于是花了一点时间用最新的wdk整理了一份，可以比较完美替换osr的那份。需要的童鞋请自取。（整理的方法比较简单，主要用到vim和正则表达式）
目前只在最新的wdk上测试过，如果有BUG请告知我，谢谢。

StatusStr.7z (Size: 24.3 KB / Downloads: 348)

无锁数组

Sun, 15 Jan 2012 15:05:08 +0800

项目里有一个地方可能要去掉用于链表的锁，但是又得保证读写互斥。于是琢磨了一个土办法：
（琢磨时的目标是用于异步发送日志，即多个日志存储者，一个发送者，接收者在另一个进程不用管它）

Code:

#define N 200

PVOID g_Buffer[N] = {0};

UINT  g_uSaveIndex = 0;

VOID 

    Save(

        PVOID pLog

    )

{

    UINT uMySaveIndex = 0;

    PVOID pOldLog = NULL;

    //

    // 获取目前可以操作的数组下标

    //

    uMySaveIndex = InterlockedIncrement(&g_uSaveIndex) % N;

    //

    // 存储日志

    //

    pOldLog = InterlockedExchangePointer(g_Buffer[uMySaveIndex], pLog);

    if (NULL != pOldLog)

    {

        //

        //     这个数组单元有老日志，释放这条老日志。

        //     （这条老日志距离本条日志中间已经有2000条日志了，

        // 这么久都没有发送出去，说明日志存储速度可能远大于发送速度，

        // 只能抛弃一部分日志了。

        //     如果不希望抛弃任何日志，那可以考虑使用链表，而不是用数组。

        //

    }

    return;

}

VOID 

    Send(

        VOID

    )

{

    static UINT uSendIndex = 0;

    PVOID pLogToSend = NULL;

    pLogToSend = InterlockedExchangePointer(g_Buffer[uSendIndex++ % N], NULL);

    //

    // 发送并清理日志

    // ...

    //

    return;

}

求垃圾回复拦截插件

Sun, 15 Jan 2012 09:32:30 +0800

最近我的blog每天只能都有垃圾右键，人工删不过来，验证码什么的早就加上了。求适用于mybb论坛的自动拦截垃圾回复的插件……

程序猿的字体

Mon, 26 Dec 2011 19:22:56 +0800

作为一名光荣的程序猿，我对字体的挑剔程度一点也不亚于对编辑器的挑剔程度。

之前一直用consolas字体编码。这个字体英文看着很舒服，但是貌似是没有中文部分的，中文使用的是宋体。虽然宋体使用范围很广，很多人都偏爱。但是我却不咋喜欢，感觉字体怪怪的。中文我更倾向于雅黑字体。

自然也就希望能兼得两者所长，之前用emacs的时候可以设置，中文用雅黑英文用consolas，但是后来习惯不了emacs的各种问题（比如翻页刷新效率，启动慢，ecb自动补全慢等等），于是又捡起vim。vim不支持同时使用两种字体，于是只好囧囧的用纯consolas。

朋友推荐混合字体，我也关注了一下，网上大部分的consolas+雅黑的混合字体都有瑕疵，比如下图所示：

  有瑕疵的混合字体.jpg (Size: 4.18 KB / Downloads: 55)
明显看得出其中字体变形了。

后来cntrump给了个新的consolas+雅黑的混合字体，用了段时间，效果挺好，所以推荐下，也在这里备个份，以后自己也好找。
效果图：

  完美的混合字体.jpg (Size: 20.25 KB / Downloads: 71)

字体：

  MSYHMONO.7z (Size: 6.84 MB / Downloads: 55)

检讨书

Sun, 20 Nov 2011 20:18:58 +0800

今天打球发脾气了，很大的火气，在这里记一笔，反省，也给自己敲一棒，希望能起到警钟的作用。
爱憎过于分明是我的一个很严重的性格缺陷，但是没办法，我就这臭脾气，虽然一直提醒自己要克制，要慢慢淡化这种情绪，但是效果甚微。
我对行为、个性猥琐无赖的人相当排斥，我有自我分析过，最后的结论是小时候看了太多的小说，武侠的历史的，影响太深，欣赏耿直正派的侠义，但并不仇恨个性反派，却对中间那类猥琐阴险的角色恨之入骨。这种情绪逐步渗入到我的思维判断方式和性格。最后演变成现在这个样子。
我知道我的这个性格很不好，人生百态，胸怀应当宽广，能纳百川。

还有我的破脾气，平常都还好，但有时候会突然一下就爆掉。mrcool和大纯都跟我说过。
我想改，努力地改。

以前，这个时候，mrcool 就会很欢乐的在我耳边嗡嗡：“莫生气，人生就像一场戏，因为有缘来相聚……”，一脸贱相。

另外，感谢……赐予我一个愿意包容我这种臭脾气的老婆。也感谢有朋友，愿意直白的告诉我我的缺点，因为有你们这些垫脚石，我才能更清楚的读懂自己，完善自己，爬得更高，尿得更远。谢谢。

读资治通鉴 2011-11-17

Thu, 17 Nov 2011 07:30:42 +0800

Quote:皇太子柔仁好儒，见上所用多文法吏，以刑绳下，常侍燕从容言：“陛下持刑太深，宜用儒生。”帝作色曰：“汉家自有制度，本以霸王道杂之；奈何纯任德教，用周政乎！且俗儒不过时宜，好是古非今，使人眩于名实，不知所守，何足委任！”乃叹曰：“乱我家者太子也！”

这段评价真精辟。汉宣帝是个明白人啊，挑头“遵儒”的汉武帝更是个明白人。可法儒并重，但不可纯儒。历史已经证明了这一点。

SEH分析笔记（X64篇）

Fri, 04 Nov 2011 18:52:24 +0800

SEH分析笔记（X64篇）
v1.0.0
boxcounter

历史：
v1.0.0, 2011-11-4：最初版本。

[不介意转载，但请注明出处 www.boxcounter.com
附件里有本文的原始稿，一样的内容，更好的高亮和排版。
本文的部分代码可能会因为论坛的自动换行变得很乱，需要的朋友手动复制到自己的代码编辑器就可以正常显示了]

在之前的《SEH分析笔记（X86篇）》中，我借助 wrk1.2 介绍了 x86 下 windows 系统内核中的 SEH 实现。这次我们来看看 x64 位 windows 系统内核中 SEH 的实现。
本文需要大家熟悉 x64 位系统的一些特性，比如调用约定、Prolog 和 Epilog。可以通过这几篇文章熟悉一下:
Overview of x64 Calling Conventions, MSDN
The history of calling conventions, part 5: amd64 , The Old New Thing
Everything You Need To Know To Start Programming 64-Bit Windows Systems, Matt Pietrek

首先回顾一下前一篇文章。
在 x86 windows 中，函数通过以下几个步骤来参与 SEH ：
1. 在自身的栈空间中分配并初始化一个 EXCEPTION_REGISTRATION(_RECORD) 结构体。
2. 将该 EXCEPTION_REGISTRATION(_RECORD) 挂入当前线程的异常链表。

当某函数触发异常时，系统首先会通过调用 KiDispatchException 来给内核调试器一个机会，如果内核调试器没有处理该异常，则该机会被转给 RtlDispatchException，这个函数就开始分发该异常。分发过程为：
从当前线程的异常链表头开始遍历，对于每一个 SEH 注册信息（即 EXCEPTION_REGISTRATION(_RECORD)），调用其 Handler。根据 Handler 的返回值做相应的后续处理：
1. 返回 ExceptionContinueExecution，表示 Handler 已经修复了异常触发点，从异常触发点继续执行。
2. 返回 ExceptionContinueSearch，表示该 Handler 没有处理该异常，继续遍历异常链表。
3. Handler 没有修复异常触发点，但是却能处理该异常（某个 __except 过滤代码返回 EXCEPTION_EXECUTE_HANDLER）。这种情况下，处理完该异常后就从异常解决代码（__except 代码块）继续执行，Handler 不会返回。
以上是简略的 x86 SEH 流程，其中省略了很多细节，比如展开、错误处理、ExceptionNestedException 和 ExceptionCollidedUnwind 等等。

之所以在这里重温这个流程，是因为 x64 中 SEH 的流程总体思路也是如此，只是细节上做了一些修改。但这并不表示熟悉 x86 SEH 就能很轻松的掌握 x64 SEH。

本文分为四个部分：“异常注册”、“异常分发”、“展开、解决”和“ExceptionNestedException 和 ExceptionCollidedUnwind”。依然以 MSC 的增强版为分析对象。分析环境为：WDK 7600.16385.1，内置的 cl 的版本是15.00.30729.207，link 的版本是9.00.30729.207，测试虚拟机系统为 amd64 WinXP + wrk1.2。

在讲述之前，需要先定义几个名词，以简化后续的讲述。

RVA —— 熟悉 PE 格式的朋友都懂的，表示某个绝对地址相对于所在模块的基地址的偏移。
EXCEPT_POINT —— 异常触发点。
EXCEPT_FILTER —— __except 小括号内的异常过滤代码。
EXCEPT_HANDLER —— __except 大括号内的异常解决代码。
FINALLY_HANDLER —— __finally 大括号内的代码。

以下面的伪码为例，

Code:

    1  __try

    2  {

    3      __try

    4      {

    5           *((ULONG*)NULL) = 0; 

    6      }

    7      __except((STATUS_INVALID_PARAMETER == GetExceptionCode()) ? EXCEPTION_CONTINUE_SEARCH : EXCEPTION_EXECUTE_HANDLER)

    8      {

    9          ...

    10     }

    11 }

    12 __finally

    13 {

    14     ...

    15 {

EXCEPT_POINT 指的是行5中的代码。
EXCEPT_FILTER 指的是行7中的“(STATUS_INVALID_PARAMETER == GetExceptionCode()) ? EXCEPTION_CONTINUE_SEARCH : EXCEPTION_EXECUTE_HANDLER”。
EXCEPT_HANDLER 指的是行8到行10中所有的代码。
FINALLY_HANDLER 指的是行13到行15中所有的代码。

一、异常注册

在 x64 windows 中，异常注册信息发生了巨大的改变。x86 中异常注册信息是在函数执行过程中在栈中分配并初始化的。x64 中变成这样：
异常注册信息不再是动态创建，而是编译过程中生成，链接时写入 PE+ 头中的 ExceptionDirectory（参考 winnt.h 中 IMAGE_RUNTIME_FUNCTION_ENTRY 的定义）。ExceptionDirectory 里包含几乎所有函数的栈操作、异常处理等信息。

来看看新异常注册信息的数据结构：

Code:

    typedef struct _RUNTIME_FUNCTION {

        ULONG BeginAddress;

        ULONG EndAddress;

        ULONG UnwindData;

    } RUNTIME_FUNCTION, *PRUNTIME_FUNCTION;

    typedef enum _UNWIND_OP_CODES {

        UWOP_PUSH_NONVOL = 0,

        UWOP_ALLOC_LARGE,       // 1

        UWOP_ALLOC_SMALL,       // 2

        UWOP_SET_FPREG,         // 3

        UWOP_SAVE_NONVOL,       // 4

        UWOP_SAVE_NONVOL_FAR,   // 5

        UWOP_SPARE_CODE1,       // 6

        UWOP_SPARE_CODE2,       // 7

        UWOP_SAVE_XMM128,       // 8

        UWOP_SAVE_XMM128_FAR,   // 9

        UWOP_PUSH_MACHFRAME     // 10

    } UNWIND_OP_CODES, *PUNWIND_OP_CODES;

    typedef union _UNWIND_CODE {

        struct {

            UCHAR CodeOffset;

            UCHAR UnwindOp : 4;

            UCHAR OpInfo : 4;

        };

        USHORT FrameOffset;

    } UNWIND_CODE, *PUNWIND_CODE;

    #define UNW_FLAG_NHANDLER 0x0

    #define UNW_FLAG_EHANDLER 0x1

    #define UNW_FLAG_UHANDLER 0x2

    #define UNW_FLAG_CHAININFO 0x4

    typedef struct _UNWIND_INFO {

        UCHAR Version : 3;

        UCHAR Flags : 5;

        UCHAR SizeOfProlog;

        UCHAR CountOfCodes;

        UCHAR FrameRegister : 4;

        UCHAR FrameOffset : 4;

        UNWIND_CODE UnwindCode[1];

    //

    // The unwind codes are followed by an optional DWORD aligned field that

    // contains the exception handler address or a function table entry if

    // chained unwind information is specified. If an exception handler address

    // is specified, then it is followed by the language specified exception

    // handler data.

    //

    //  union {

    //      struct {

    //          ULONG ExceptionHandler;

    //          ULONG ExceptionData[];

    //      };

    //

    //      RUNTIME_FUNCTION FunctionEntry;

    //  };

    //

    } UNWIND_INFO, *PUNWIND_INFO;

    typedef struct _SCOPE_TABLE {

        ULONG Count;

        struct

        {

            ULONG BeginAddress;

            ULONG EndAddress;

            ULONG HandlerAddress;

            ULONG JumpTarget;

        } ScopeRecord[1];

    } SCOPE_TABLE, *PSCOPE_TABLE;

x64 中，MSC 为几乎所有的函数都登记了完备的信息，用来在展开过程中完整的回滚函数所做的栈、寄存器操作。登记的信息包括：
函数是否使用了 SEH、
函数使用的是什么组合的 SEH（__try/__except？__try/__finally？）、
函数申请了多少栈空间、
函数保存了哪些寄存器、
函数是否建立了栈帧，
等等，
同时也记录了这些操作的顺序（以保证回滚的时候不会乱套）。

这些信息就存储在 UNWIND_INFO 之中。
UNWIND_INFO 相当于 x86 下的 EXCEPTION_REGISTRATION。它的成员分别是：
Version —— 结构体的版本。
Flags —— 标志位，可以有这么几种取值：
UNW_FLAG_NHANDLER (0x0): 表示既没有 EXCEPT_FILTER 也没有 EXCEPT_HANDLER。
UNW_FLAG_EHANDLER (0x1): 表示该函数有 EXCEPT_FILTER & EXCEPT_HANDLER。
UNW_FLAG_UHANDLER (0x2): 表示该函数有 FINALLY_HANDLER。
UNW_FLAG_CHAININFO (0x4): 表示该函数有多个 UNWIND_INFO，它们串接在一起（所谓的 chain）。
SizeOfProlog —— 表示该函数的 Prolog 指令的大小，单位是 byte。
CountOfCodes —— 表示当前 UNWIND_INFO 包含多少个 UNWIND_CODE 结构。
FrameRegister —— 如果函数建立了栈帧，它表示栈帧的索引（相对于 CONTEXT::RAX 的偏移，详情参考 RtlVirtualUnwind 源码）。否则该成员的值为0。
FrameOffset —— 表示 FrameRegister 距离函数最初栈顶（刚进入函数，还没有执行任何指令时的栈顶）的偏移，单位也是 byte。
UnwindCode —— 是一个 UNWIND_CODE 类型的数组。元素数量由 CountOfCodes 决定。
需要说明几点：
1. 如果 Flags 设置了 UNW_FLAG_EHANDLER 或 UNW_FLAG_UHANDLER，那么在最后一个 UNWIND_CODE 之后存放着 ExceptionHandler（相当于 x86 EXCEPTION_REGISTRATION::handler）和 ExceptionData（相当于 x86 EXCEPTION_REGISTRATION::scopetable）。
2. UnwindCode 数组详细记录了函数修改栈、保存非易失性寄存器的指令。
3. MSDN 中有 UNWIND_INFO 和 UNWIND_CODE 的详细说明，推荐阅读。

那 UNWIND_INFO 是如何与其描述的函数关联起来的呢？答案是：通过一个 RUNTIME_FUNCTION 结构体。
RUNTIME_FUNCTION::BeginAddress 同 RUNTIME_FUNCTION::EndAddress 一起以 RVA 形式描述了函数的范围。
RUNTIME_FUNCTION::UnwindData 就是 UNWIND_INFO 了，它也是一个 RVA 值。

PE+ 中的 ExceptionDirectory 中存放着所有函数的 RUNTIME_FUNCTION，按 RUNTIME_FUNCTION::BeginAddress 升序排列。一旦触发异常，系统可以通过 EXCEPT_POINT 的 RVA 在 ExceptionDirectory 中二分查找到 RUNTIME_FUNCTION，进而找到 UNWIND_INFO。

前面有提到，MSC 为几乎所有的函数都登记了完毕的信息，那是不是有一些特殊函数没有登记信息呢？
是的。x64 新增了一个概念，叫做“叶函数”。熟悉数据结构的朋友可能第一时间就联想到“叶节点”。没错，“叶函数”的含义跟“叶节点”很类似，叶函数不会有子函数，也就是说它不会再调用任何函数。另外 x64 对这个概念额外加了一些要求：不修改栈指针（比如分配栈空间）、没有使用 SEH。总结下来就是：既不调用函数、又没有修改栈指针，也没有使用 SEH 的函数就叫做“叶函数”。
叶函数可以没有登记信息，原因很简单，它根本就没信息需要登记~

还有一个 SCOPE_TABLE 结构，熟悉 x86 SEH 的朋友应该很眼熟 :-)，它等同于 x86 SEH 中的 REGISTRATIOIN_RECORD::scopetable 的类型。其成员有：
Count —— 表示 ScopeRecord 数组的大小。
ScopeRecord —— 等同于 x86 中的 scopetable_entry 成员。其中，
BeginAddress 和 EndAddress 表示某个 __try 保护域的范围。
HandlerAddress 和 JumpTarget 表示 EXCEPTION_FILTER、EXCEPT_HANDLER 和 FINALLY_HANDLER。具体对应情况为：
对于 __try/__except 组合，HandlerAddress 代表 EXCEPT_FILTER，JumpTarget 代表 EXCEPT_HANDLER。
对于 __try/__finally 组合，HandlerAddress 代表 FINALLY_HANDLER，JumpTarget 等于 0。
这四个域通常都是 RVA，但当 EXCEPT_FILTER 简单地返回或等于 EXCEPTION_EXECUTE_HANDLER 时，HandlerAddress 可能直接等于 EXCEPTION_EXECUTE_HANDLER，而不再是一个 RVA。

我们可以通过 windbg 中的 .fnent 命令来查看某个函数的异常注册信息。比如，

1 kd> .fnent passThrough!SehTest
2 Debugger function entry 00000000`00778210 for:
3 d:\workspace\code\mycode\r0\passthrough\passthrough.c(51)
4 (fffffadf`f140f020) PassThrough!SehTest | (fffffadf`f140f0c0) PassThrough!Caller2
5 Exact matches:
6 PassThrough!SehTest (void)
7
8 BeginAddress = 00000000`00001020
9 EndAddress = 00000000`000010b2
10 UnwindInfoAddress = 00000000`00002668
11
12 Unwind info at fffffadf`f1410668, 10 bytes
13 version 1, flags 1, prolog 4, codes 1
14 handler routine: PassThrough!_C_specific_handler (fffffadf`f140f4ce), data 3
15 00: offs 4, unwind op 2, op info 4 UWOP_ALLOC_SMALL.

行8到行10描述的是 RUNTIME_FUNCTION。
行12到行15描述的是 UNWIND_INFO。

对于叶函数，输出是这样的，

kd> .fnent passthrough!LeafTest
No function entry for fffffadf`f240c080

到这里，异常注册就讲完了，我们认识了相关的数据结构和定位方法。下面我们进入异常分发流程。

二、异常分发

x64 异常分发过程使用的仍然是 KiDispatchException、RtlDispatchException、RtlpExecuteHandlerForException 等函数。

其中，KiDispatchException 中有关内核异常部分的代码完全没有变化，这里我偷懒直接拷贝《SEH分析笔记（X86篇）》中的部分描述，

原型：

Code:

    VOID

    KiDispatchException (

        IN PEXCEPTION_RECORD ExceptionRecord,

        IN PKEXCEPTION_FRAME ExceptionFrame,

        IN PKTRAP_FRAME TrapFrame,

        IN KPROCESSOR_MODE PreviousMode,

        IN BOOLEAN FirstChance

        );

对于内核异常，它的处理步骤如下：
如果 FirstChance 为 TRUE，那么,
1. 首先将该异常传达给内核调试器（KD），如果 KD 处理了该异常，那么函数返回。
2. KD 没有处理，调用 RtlDispatchException 进行异常分发。如果分发成功，RtlDispatchExcetpion 返回 TRUE，或者根本不返回。
3. RtlDispatchException 分发失败，那么再给 KD 一次处理机会，如果还是没有处理，那么 BUGCHECK。
如果 FirstChance 为 FALSE，那么将该异常传达给 KD，如果 KD 没有处理，那么 BUGCHECK。
它的源码实现位于 $WRK-v1.2\base\ntos\ke\amd64\exceptn.c:430。

RtlDispatchException 发生了一些改变。
从之前描述的异常注册信息的数据结构可以发现，x64 中已经不存在异常注册链这个概念了（虽然 _NT_TIB 结构体中还保留了 ExceptionList 域）。那 x64 中 RtlDispatchException 是如何遍历异常注册信息的呢？前面虽然有提到如何通过 EXCEPT_POINT 找到 UNWIND_INFO 结构，但是假如这个 UNWIND_INFO 没有处理该异常，如何继续遍历呢？

在解答这个问题之前，我们先来认识一个新函数和相关的数据结构，

Code:

    #define UNWIND_HISTORY_TABLE_SIZE 12

    typedef struct _UNWIND_HISTORY_TABLE_ENTRY {

            ULONG64 ImageBase;

            PRUNTIME_FUNCTION FunctionEntry;

    } UNWIND_HISTORY_TABLE_ENTRY, *PUNWIND_HISTORY_TABLE_ENTRY;

    #define UNWIND_HISTORY_TABLE_NONE 0

    #define UNWIND_HISTORY_TABLE_GLOBAL 1

    #define UNWIND_HISTORY_TABLE_LOCAL 2

    typedef struct _UNWIND_HISTORY_TABLE {

            ULONG Count;

            UCHAR Search;

            ULONG64 LowAddress;

            ULONG64 HighAddress;

            UNWIND_HISTORY_TABLE_ENTRY Entry[UNWIND_HISTORY_TABLE_SIZE];

    } UNWIND_HISTORY_TABLE, *PUNWIND_HISTORY_TABLE;

    PRUNTIME_FUNCTION

    RtlLookupFunctionEntry (

        IN ULONG64 ControlPc,

        OUT PULONG64 ImageBase,

        IN OUT PUNWIND_HISTORY_TABLE HistoryTable OPTIONAL

        );

RtlLookupFunctionEntry 的功能是查找指定地址所在函数的 RUNTIME_FUNCTION 和所在模块的基地址。它的参数分为为，
ControlPc —— 需要查找的指令地址，
ImageBase —— 返回的模块基地址，
HistoryTable —— 用于加速查找。

工作流程：
RtlLookupFunctionEntry 在搜索的过程会根据是否传入 HistoryTable 而采取不同的搜索方法：
如果传入 HistoryTable，则根据 HistoryTable->Search 表示的搜索方式在表中进行搜索：
如果搜索方式为 UNWIND_HISTORY_TABLE_NONE，那么不在 HistoryTable 中进行搜索。
如果搜索方式为 UNWIND_HISTORY_TABLE_GLOBAL，则首先在全局表 RtlpUnwindHistoryTable 开始搜索，如果搜索到，则结束搜索，函数返回。否则再在 HistoryTable 中搜索。
如果搜索方式为 UNWIND_HISTORY_TABLE_LOCAL，那么在 HistoryTable 中搜索。
如果上述过程中没有搜索到需要的结果，那么找到模块基地址，从模块的 PE+ 头结构中解析出 RUNTIME_FUNCTION。如果搜索方式为 UNWIND_HISTORY_TABLE_NONE，还会将解决加入到 HistoryTable。

之前的描述中 RtlDispatchException 定位 EXCEPT_POINT 所对应的 RUNTIME_FUNCTION 就是通过调用 RtlLookupFunctionEntry 实现的。

回到刚才的问题，如何推动遍历呢？为了解决这个问题，x64 又引进了一个新函数。现在我们有请 x64 SEH 核心成员 RtlVirtualUnwind 登场~

先来看看它的原型：

Code:

    PEXCEPTION_ROUTINE

    RtlVirtualUnwind (

        IN ULONG HandlerType,

        IN ULONG64 ImageBase,

        IN ULONG64 ControlPc,

        IN PRUNTIME_FUNCTION FunctionEntry,

        IN OUT PCONTEXT ContextRecord,

        OUT PVOID *HandlerData,

        OUT PULONG64 EstablisherFrame,

        IN OUT PKNONVOLATILE_CONTEXT_POINTERS ContextPointers OPTIONAL

        );

它的主要功能是：
根据传入的 ControlPc 和 ContextRecord 等参数虚拟（模拟）展开该函数，并返回该函数的一些信息，比如 HandlerData（SCOPE_TABLE）、EstablisherFrame（rsp 或栈帧）。
流程是：
1. 通过 FunctionEntry 和 ImageBase 找到 UNWIND_INFO。根据 UNWIND_INFO 中记录的信息，查找 EstablisherFrame（即栈帧或者 rsp）。
2. 根据 ControlPc 分如下两种情况展开：
a. ControlPc >= EpilogOffset，即 ControlPc 在 Epilog 之中。那么把剩余的 Epilog 指令模拟执行完毕即可。
所谓模拟是指，如果下一条 EpiLog 指令是“sub rsp, 0x32”，那么将 ContextRecord->rsp 减去0x32。并不是真正执行 sub 指令。
b. ControlPc < EpilogOffset，那么把 Prolog 反向模拟回滚一遍即可。
所谓反向回滚是指，如果 Prolog 的指令是
mov [RSP + 8], RCX
push R15
push R14
push R13
那么反向回滚就是
pop ContextRecord->R13 （实际上是从 ContextRecord->Rsp 指向的内存中取出值存入 ContextRecord->R13，然后 ContextRecord->Rsp 加上8。并不是真正执行 pop）
pop ContextRecord->R14
pop ContextRecord->R15
mov ContextRecord->RCX, [ContextRecord->RSP+8]
然后把 ContextRecord->Rip 修改为 ControlPc 所在函数的返回地址，即父函数中的某一处 call 的下一条指令。
这样，ContextRecord 就被恢复成父函数在调用 ControlPc 所在函数之后的状态了。
3. 如果 HandlerType 包含 UNW_FLAG_EHANDLER 或 UNW_FLAG_UHANDLER，那么将 UNWIND_INFO::ExceptionData 赋给传出参数 HandlerData，并返回 UNWIND_INFO::ExceptionRoutine。
对于 MSC 编译器生成的模块，UNWIND_INFO::ExceptionRoutine 一般指向 nt!__C_specific_handler。UNWIND_INFO::ExceptionData 指向 ControlPc 所在函数的 SCOPE_TABLE。
RtlVirtualUnwind 的实现源码位于 $WRK-v1.2\base\ntos\rtl\amd64\exdsptch.c:1202。

RtlVirtualUnwind 返回后，RtlDispatchException 就可以根据 ContextRecord->Rip 找到父函数对应的 RUNTIME_FUNCTION，进而找到 UNWIND_INFO。就这样推动整个遍历过程。

这是一般情况，对于没有 UNWIND_INFO 的叶函数呢？
对于叶函数，RtlLookupFunctionEntry 返回 NULL，于是 RtlDispatchException 知道这是个叶函数，就找到该叶函数的父函数，从父函数继续遍历。也就是完全无视叶函数，因为叶函数对整个异常处理过程没有任何影响。

RtlDispatchException 调用 UNWIND_INFO::ExceptionHandler 依然是通过 RtlpExecuteHandlerForException，其函数原型没有变化：

Code:

    EXCEPTION_DISPOSITION

    RtlpExecuteHandlerForException (

        IN PEXCEPTION_RECORD ExceptionRecord,

        IN PVOID EstablisherFrame,

        IN OUT PCONTEXT ContextRecord,

        IN OUT PVOID DispatcherContext

        );

该函数的实现源码位于 $\WRK-v1.2\base\ntos\rtl\amd64\xcptmisc.asm:84。
RtlpExecuteHandlerForException 的逻辑较 x86 版本没什么大变化，内部注册了一个异常处理函数 RtlpExceptionHandler。RtlpExceptionHandler 相当于 x86 中的 nt!ExecuteHandler2，其内部会返回 ExceptionNestedException 或 ExceptionContinueSearch。它的实现源码位于 $\WRK-v1.2\base\ntos\rtl\amd64\xcptmisc.asm:26。

需要一提的是，最后一个参数 DispatchContext 的类型是 DISPATCHER_CONTEXT，相对于 x86 版本，它扩充了很多，

Code:

    typedef struct _DISPATCHER_CONTEXT {

        ULONG64 ControlPc;

        ULONG64 ImageBase;

        PRUNTIME_FUNCTION FunctionEntry;

        ULONG64 EstablisherFrame;

        ULONG64 TargetIp;

        PCONTEXT ContextRecord;

        PEXCEPTION_ROUTINE LanguageHandler;

        PVOID HandlerData;

        PUNWIND_HISTORY_TABLE HistoryTable;

        ULONG ScopeIndex;

        ULONG Fill0;

    } DISPATCHER_CONTEXT, *PDISPATCHER_CONTEXT;

成员分别为：
ControlPc —— 异常触发点。
ImagePase —— ControlPc 所在模块的基地址。
FunctionEntry —— ControlPc 所在函数的 RUNTIME_FUNCTION。
EstablisherFrame —— ControlPc 所在函数的栈帧（如果建立了栈帧）或 RSP。
TargetIp —— 解决异常的 EXCEPT_HANDLER 地址，该成员只在展开的过程中被使用。RtlpExecuteHandlerForException 没有使用它。
ContextRecord —— 供展开过程中使用，只有当展开过程中触发新异常（返回 ExceptionCollidedUnwind）时，才会被 RtlDispatchException 真正的使用到（参考 RtlDispatchException 处理 ExceptionCollidedUnwind 的代码）。
LanguageHandler —— ControlPc 所在函数的 UNWIND_INFO::ExceptionRoutine。
HandlerData —— ControlPc 所在函数的 UNWIND_INFO::ExceptionData。
ScopeIndex —— UNWIND_INFO::ExceptionData 中 SCOPE_TABLE::ScopeRecord 的索引，通常设置为0（注：请不要与 x86 中运行时不断改变的 EXCEPTION_REGISTRATION::trylevel 相混淆，ScopeIndex 不会在在函数执行过程中改变）
Fill0 —— 未用。

再看一下它的 .fnent 输出，

1 kd> .fnent nt!RtlpExecuteHandlerForException
2 Debugger function entry 00000000`01458210 for:
3 (fffff800`008bd950) nt!RtlpExecuteHandlerForException | (fffff800`008bd970) nt!RtlpUnwindHandler
4 Exact matches:
5 nt!RtlpExecuteHandlerForException (void)
6
7 BeginAddress = 00000000`000bd950
8 EndAddress = 00000000`000bd963
9 UnwindInfoAddress = 00000000`000dfeb8
10
11 Unwind info at fffff800`008dfeb8, 10 bytes
12 version 1, flags 3, prolog 4, codes 1
13 handler routine: nt!RtlpExceptionHandler (fffff800`008bd920), data 0
14 00: offs 4, unwind op 2, op info 4 UWOP_ALLOC_SMALL.

行12中显示 flags 等于3，即 UNW_FLAG_EHANDLER (0x1) | UNW_FLAG_UHANDLER (0x2)，说明行13中显示的异常处理函数 nt!RtlpExceptionHandler 既负责解决异常，也负责展开。

RtlpExecuteHandlerForException 会调用 DISPATCHER_CONTEXT::LanguageHandler。对于 MSC 编译得到的模块，它是 nt!__C_specific_handler，我们来看看这个函数，

原型：

Code:

    EXCEPTION_DISPOSITION 

    __C_specific_handler (

        IN PEXCEPTION_RECORD pExceptionRecord,

        IN PVOID pEstablisherFrame,

        IN OUT PCONTEXT pContext,

        IN OUT PVOID pDispatcherContext

        );

反汇编码：

Code:

kd> uf nt!__C_specific_handler

               nt!__C_specific_handler:

               fffff800`008a42d0 mov     qword ptr [rsp+10h],rdx ; 在栈上保存 pEstablisherFrame

               fffff800`008a42d5 mov     rax,rsp

               fffff800`008a42d8 sub     rsp,88h

               fffff800`008a42df mov     qword ptr [rax-8],rbx

               fffff800`008a42e3 mov     qword ptr [rax-10h],rbp

               fffff800`008a42e7 mov     rbp,qword ptr [r9]      ; rbp = pDispatcherContext->ControlPc

               fffff800`008a42ea mov     qword ptr [rax-18h],rsi

               fffff800`008a42ee mov     qword ptr [rax-20h],rdi

               fffff800`008a42f2 mov     qword ptr [rax-28h],r12

               fffff800`008a42f6 mov     r12,qword ptr [r9+38h]  ; r12 = pDispatcherContext->HandlerData

               fffff800`008a42fa mov     qword ptr [rax-30h],r13

               fffff800`008a42fe mov     qword ptr [rax-38h],r14

               fffff800`008a4302 mov     r14,qword ptr [r9+8]    ; r14 = pDispatcherContext->ImageBase

               fffff800`008a4306 mov     qword ptr [rax-40h],r15

               fffff800`008a430a mov     r13,r9                  ; r13 = pDispatcherContext

               fffff800`008a430d sub     rbp,r14                 ; l_OffsetInFunc = pDispatcherContext->ControlPc - pDispatcherContext->ImageBase

               fffff800`008a4310 test    byte ptr [rcx+4],66h    ; pExceptionRecord->ExceptionFlags, EXCEPTION_UNWIND (0x66)

               fffff800`008a4314 mov     rsi,rdx                 ; rsi = pEstablisherFrame

               fffff800`008a4317 mov     r15,rcx                 ; r15 = pExceptionRecord

<              fffff800`008a431a jne     nt!__C_specific_handler+0xf5 (fffff800`008a43c5)

:              

:              -------------------------------------------------------------------

:              nt!__C_specific_handler+0x50:

:              fffff800`008a4320 movsxd  rdi,dword ptr [r9+48h]  ; l_ScopeIndex (rdi) = pDispatcherContext->ScopeIndex

:              fffff800`008a4324 mov     qword ptr [rax-58h],rcx ; [rax-58h] = pExceptionRecord，供给 GetExceptionCode(Information) 使用

:              fffff800`008a4328 mov     qword ptr [rax-50h],r8  ; [rax-50h] = pContext，供给 GetExceptionCode(Information) 使用

:              fffff800`008a432c cmp     edi,dword ptr [r12]     ; cmp l_ScopeIndex, pDispatcherContext->HandlerData->Count

:              fffff800`008a4330 mov     rax,rdi                 ; rax = l_ScopeIndex

:<             fffff800`008a4333 jae     nt!__C_specific_handler+0x166 (fffff800`008a4436)

::             

::             nt!__C_specific_handler+0x69:

::             fffff800`008a4339 add     rax,rax             ; 这里 *2，下面紧接着 *8，目的是跳过指定数目的 ScopeRecord（大小为16字节）

::             fffff800`008a433c lea     rbx,[r12+rax*8+0Ch] ; rbx = &(pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].HandlerAddress)

::             

::             nt!__C_specific_handler+0x71:

::             ; 检查 ControlPc 处于哪个 __try 保护域，之步骤一

::      >      fffff800`008a4341 mov     eax,dword ptr [rbx-8] ; eax = pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].BeginAddress

::      :      fffff800`008a4344 cmp     rbp,rax               ; cmp l_OffsetInFunc, pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].BeginAddress

::<     :      fffff800`008a4347 jb      nt!__C_specific_handler+0xdd (fffff800`008a43ad)

:::     :      

:::     :      nt!__C_specific_handler+0x79:

:::     :      ; 检查 ControlPc 处于哪个 __try 保护域，之步骤二

:::     :      fffff800`008a4349 mov     eax,dword ptr [rbx-4] ; eax = pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].EndAddress

:::     :      fffff800`008a434c cmp     rbp,rax               ; cmp l_OffsetInFunc, pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].EndAddress

:::<    :      fffff800`008a434f jae     nt!__C_specific_handler+0xdd (fffff800`008a43ad)

::::    :      

::::    :      nt!__C_specific_handler+0x81:

::::    :      ; 判断是否是 __try/__finally（JumpTarget 为 NULL）。如果是，那么跳转到下一个 ScopeRecord 继续遍历。

::::    :      fffff800`008a4351 cmp     dword ptr [rbx+4],0 ; cmp pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].JumpTarget, NULL

::::<   :      fffff800`008a4355 je      nt!__C_specific_handler+0xdd (fffff800`008a43ad)

:::::   :      

:::::   :      nt!__C_specific_handler+0x87:

:::::   :      ; 到这里，已经找到与异常地址最匹配的 __try/__except

:::::   :      fffff800`008a4357 mov     eax,dword ptr [rbx] ; eax = pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].HandlerAddress

:::::   :      fffff800`008a4359 cmp     eax,1               ; cmp pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].HandlerAddress, EXCEPTION_EXECUTE_HANDLER (0x1)

:::::<  :      fffff800`008a435c je      nt!__C_specific_handler+0xa3 (fffff800`008a4373) ; 如果返回 EXCEPTION_EXECUTE_HANDLER 则跳转

::::::  :      

::::::  :      nt!__C_specific_handler+0x8e:

::::::  :      ; 是 __try/__except，且过滤域并不是 EXCEPTION_EXECUTE_HANDLER，执行 HandlerAddress 

::::::  :      ; （注：HandlerAddress 指向的函数仍有可能会返回 EXCEPTION_EXECUTE_HANDLER） 

::::::  :      fffff800`008a435e lea     rcx,[rsp+30h]

::::::  :      fffff800`008a4363 add     rax,r14 ; rax = pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].HandlerAddress + pDispatcherContext->ImageBase

::::::  :      fffff800`008a4366 mov     rdx,rsi ; rdx = pEstablisherFrame

::::::  :      fffff800`008a4369 call    rax     ; 调用 EXCEPT_FILTER

::::::  :      fffff800`008a436b test    eax,eax

::::::< :      fffff800`008a436d js      nt!__C_specific_handler+0xee (fffff800`008a43be) ; 返回 EXCEPTION_CONTINUE_EXECUTION (-1) 则跳转

::::::: :      

::::::: :      nt!__C_specific_handler+0x9f:

::::::: :      fffff800`008a436f test    eax,eax

:::::::<:      fffff800`008a4371 jle     nt!__C_specific_handler+0xdd (fffff800`008a43ad) ; 返回 EXCEPTION_CONTINUE_SEARCH (0) 则跳转

:::::::::      

:::::::::      nt!__C_specific_handler+0xa3:

:::::::::      ; 返回的是 EXCEPTION_EXECUTE_HANDLER

:::::>:::      fffff800`008a4373 mov     ecx,dword ptr [rbx+4] ; ecx = pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].JumpTarget

::::: :::      fffff800`008a4376 mov     r8d,1

::::: :::      fffff800`008a437c mov     rdx,rsi ; rdx = pEstablisherFrame

::::: :::      fffff800`008a437f add     rcx,r14 ; rcx = pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].JumpTarget + pDispatcherContext->ImageBase

::::: :::      fffff800`008a4382 call    nt!_NLG_Notify (fffff800`008b1460)

::::: :::      fffff800`008a4387 mov     rax,qword ptr [r13+40h] ; rax = pDispatcherContext->HistoryTable

::::: :::      fffff800`008a438b mov     edx,dword ptr [rbx+4]   ; edx = pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].JumpTarget

::::: :::      fffff800`008a438e movsxd  r9,dword ptr [r15]      ; r9 = pExceptionRecord->ExceptionCode

::::: :::      fffff800`008a4391 mov     qword ptr [rsp+28h],rax ; _ARG_6 = pDispatcherContext->HistoryTable

::::: :::      fffff800`008a4396 mov     rax,qword ptr [r13+28h] ; rax = pDispatcherContext->ContextRecord

::::: :::      fffff800`008a439a add     rdx,r14 ; rdx = pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].JumpTarget + pDispatcherContext->ImageBase

::::: :::      fffff800`008a439d mov     r8,r15  ; r8 = pExceptionRecord

::::: :::      fffff800`008a43a0 mov     rcx,rsi ; rcx = pEstablisherFrame

::::: :::      fffff800`008a43a3 mov     qword ptr [rsp+20h],rax ; _ARG_5 = pDispatcherContext->ContextRecord

::::: :::      fffff800`008a43a8 call    nt!RtlUnwindEx (fffff800`00891e80) ; 这里不会返回

::::: :::      ; RtlUnwindEx(pEstablisherFrame, 

::::: :::      ;             pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].JumpTarget + pDispatcherContext->ImageBase

::::: :::      ;             pExceptionRecord,

::::: :::      ;             pExceptionRecord->ExceptionCode

::::: :::      ;             pDispatcherContext->ContextRecord,

::::: :::      ;             pDispatcherContext->HistoryTable)

::::: :::      

::::: :::      nt!__C_specific_handler+0xdd:

::>>> :>:      fffff800`008a43ad inc     edi     ; l_ScopeIndex += 1

::    : :      fffff800`008a43af add     rbx,10h ; 调整到下一个 ScopeRecord::HandlerAddress

::    : :      fffff800`008a43b3 cmp     edi,dword ptr [r12] ; cmp l_ScopeIndex, pDispatcherContext->HandlerData->Count

::    : <      fffff800`008a43b7 jb      nt!__C_specific_handler+0x71 (fffff800`008a4341)

::    :        

::    :        nt!__C_specific_handler+0xe9:

::    :        ; pDispatcherContext->HandlerData 遍历完毕

::<   :        fffff800`008a43b9 jmp     nt!__C_specific_handler+0x166 (fffff800`008a4436)

:::   :        

:::   :        nt!__C_specific_handler+0xee:

:::   >        fffff800`008a43be xor     eax,eax ; eax = ExceptionContinueExecution

:::<           fffff800`008a43c0 jmp     nt!__C_specific_handler+0x16b (fffff800`008a443b)

::::           

::::           -------------------------------------------------------------------------------------

::::           nt!__C_specific_handler+0xf5:

::::           ; 设置了 EXCEPTION_UNWIND，当前是展开过程

>:::           fffff800`008a43c5 movsxd  rdi,dword ptr [r9+48h] ; l_ScopeIndex (rdi) = pDispatcherContext->ScopeIndex

 :::           fffff800`008a43c9 mov     rsi,qword ptr [r9+20h] ; rsi = pDispatcherContext->TargetIp

 :::           fffff800`008a43cd sub     rsi,r14                ; rsi = pDispatcherContext->TargetIp - pDispatcherContext->ImageBase

 :::           fffff800`008a43d0 cmp     edi,dword ptr [r12]    ; cmp l_ScopeIndex, pDispatcherContext->HandlerData->Count

 :::           fffff800`008a43d4 mov     rax,rdi                ; rax = l_ScopeIndex

 :::<          fffff800`008a43d7 jae     nt!__C_specific_handler+0x166 (fffff800`008a4436)

 ::::          

 ::::          nt!__C_specific_handler+0x109:

 ::::          fffff800`008a43d9 add     rax,rax ; 

 ::::          fffff800`008a43dc lea     rbx,[r12+rax*8+8] ; rbx = &(pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].EndAddress)

 ::::          

 ::::          nt!__C_specific_handler+0x111:

 ::::          ; 检查 ControlPc 处于哪个 __try 保护域，之步骤一

 ::::        > fffff800`008a43e1 mov     eax,dword ptr [rbx-4] ; eax = pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].BeginAddress

 ::::        : fffff800`008a43e4 cmp     rbp,rax ; cmp l_OffsetInFunc, pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].BeginAddress

 ::::<       : fffff800`008a43e7 jb      nt!__C_specific_handler+0x15a (fffff800`008a442a)

 :::::       : 

 :::::       : nt!__C_specific_handler+0x119:

 :::::       : ; 检查 ControlPc 处于哪个 __try 保护域，之步骤二

 :::::       : fffff800`008a43e9 mov     ecx,dword ptr [rbx] ; ecx = pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].EndAddress

 :::::       : fffff800`008a43eb cmp     rbp,rcx ; cmp l_OffsetInFunc, pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].EndAddress

 :::::<      : fffff800`008a43ee jae     nt!__C_specific_handler+0x15a (fffff800`008a442a)

 ::::::      : 

 ::::::      : nt!__C_specific_handler+0x120:

 ::::::      : ; 到这里，已经找到与异常地址匹配的最内层（如果有多层） __try/__except

 ::::::      : fffff800`008a43f0 cmp     rsi,rax ; cmp pDispatcherContext->TargetIp - pDispatcherContext->ImageBase, pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].BeginAddress

 ::::::<     : fffff800`008a43f3 jb      nt!__C_specific_handler+0x131 (fffff800`008a4401)

 :::::::     : 

 :::::::     : nt!__C_specific_handler+0x125:

 :::::::     : fffff800`008a43f5 cmp     rsi,rcx ; cmp pDispatcherContext->TargetIp - pDispatcherContext->ImageBase, pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].EndAddress

 :::::::<    : fffff800`008a43f8 ja      nt!__C_specific_handler+0x131 (fffff800`008a4401)

 ::::::::    : 

 ::::::::    : nt!__C_specific_handler+0x12a:

 ::::::::    : ; 如果标记了 EXCEPTION_TARGET_UNWIND，说明是最后一个需要局部展开的函数。但是该次局部展开只展开到 EXCEPT_HANDLER（不包含 EXCEPT_HANDLER），所以需要判断 TargetIp

 ::::::::    : fffff800`008a43fa test    byte ptr [r15+4],20h ; test pExceptionRecord->ExceptionFlags, EXCEPTION_TARGET_UNWIND (0x20)

 ::::::::<   : fffff800`008a43ff jne     nt!__C_specific_handler+0x166 (fffff800`008a4436)

 :::::::::   : 

 :::::::::   : nt!__C_specific_handler+0x131:

 ::::::>>:   : fffff800`008a4401 mov     eax,dword ptr [rbx+8] ; eax = pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].JumpTarget

 ::::::  :   : fffff800`008a4404 test    eax,eax ; 判断 pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].JumpTarget 是否为 NULL，即是否是 __try/__finally

 ::::::  :<  : fffff800`008a4406 je      nt!__C_specific_handler+0x13f (fffff800`008a440f) ; 如果是 __try/__finally 则跳转

 ::::::  ::  : 

 ::::::  ::  : nt!__C_specific_handler+0x138:

 ::::::  ::  : fffff800`008a4408 cmp     rsi,rax ; cmp pDispatcherContext->TargetIp, pDispatcherContext->HandlerData->ScopeRecord[l_ScopeIndex].JumpTarget

 ::::::  ::< : fffff800`008a440b je      nt!__C_specific_handler+0x166 (fffff800`008a4436)

 ::::::  ::: : 

 ::::::  ::: : nt!__C_specific_handler+0x13d:

 ::::::  :::<: fffff800`008a440d jmp     nt!__C_specific_handler+0x15a (fffff800`008a442a)

 ::::::  ::::: 

 ::::::  ::::: nt!__C_specific_handler+0x13f:

 ::::::  ::::: ; 注意这里是先修改 pDispatcherContext->ScopeIndex，然后调用 EXCEPT_HANDLER。这样如果 EXCEPT_HANDLER 触发异常，后续展开就会跳过这个 EXCEPT_HANDLER。

 ::::::  :>::: fffff800`008a440f mov     rdx,qword ptr [rsp+98h]

 ::::::  : ::: fffff800`008a4417 lea     eax,[rdi+1]             ; eax = l_ScopeIndex + 1

 ::::::  : ::: fffff800`008a441a mov     cl,1

 ::::::  : ::: fffff800`008a441c mov     dword ptr [r13+48h],eax ; pDispatcherContext->ScopeIndex = eax

 ::::::  : ::: fffff800`008a4420 mov     r8d,dword ptr [rbx+4]   ; r8d = pDispatcherContext->HandlerData->ScopeRecord[i].HandlerAddress

 ::::::  : ::: fffff800`008a4424 add     r8,r14                  ; r8 = pDispatcherContext->HandlerData->ScopeRecord[i].HandlerAddress + pDispatcherContext->ImageBase

 ::::::  : ::: fffff800`008a4427 call    r8                      ; 调用 __finally 处理块，会返回（注：对于 __try/__finally，HandlerAddress 保存的是 __finally 代码块的 RVA）

 ::::::  : ::: 

 ::::::  : ::: nt!__C_specific_handler+0x15a:

 ::::>>  : :>: fffff800`008a442a inc     edi                 ; l_ScopeIndex += 1

 ::::    : : : fffff800`008a442c add     rbx,10h             ; 调整到下一个 ScopeRecord::HandlerAddress

 ::::    : : : fffff800`008a4430 cmp     edi,dword ptr [r12] ; cmp l_ScopeIndex, pDispatcherContext->HandlerData->Count

 ::::    : : < fffff800`008a4434 jb      nt!__C_specific_handler+0x111 (fffff800`008a43e1)

 ::::    : :   

 ::::    : :   nt!__C_specific_handler+0x166:

 >>:>    > >   fffff800`008a4436 mov     eax,1 ; eax = ExceptionContinueSearch (0n1)

   :           

   :           nt!__C_specific_handler+0x16b:

   >           fffff800`008a443b mov     r15,qword ptr [rsp+48h]

               fffff800`008a4440 mov     r14,qword ptr [rsp+50h]

               fffff800`008a4445 mov     r13,qword ptr [rsp+58h]

               fffff800`008a444a mov     r12,qword ptr [rsp+60h]

               fffff800`008a444f mov     rdi,qword ptr [rsp+68h]

               fffff800`008a4454 mov     rsi,qword ptr [rsp+70h]

               fffff800`008a4459 mov     rbp,qword ptr [rsp+78h]

               fffff800`008a445e mov     rbx,qword ptr [rsp+80h]

               fffff800`008a4466 add     rsp,88h

               fffff800`008a446d ret

nt!__C_specific_handler 相当于 x86 中的 nt!_except_handler3。从上面的反汇编代码也可以看出它的逻辑跟 nt!_except_handler3 基本上一致。
函数代码不长。主要分为两个大分支，一个分支处理异常，一个分支处理展开（我用横线分隔开了）。

异常解决的代码负责遍历 SCOPE_TABLE，依次调用 SCOPE_TABLE::ScopeRecord.HandlerAddress 代表的 EXCEPT_FILTER，并针对返回值做出相应的处理：
1. 返回 EXCEPTION_CONTINUE_EXECUTION，说明异常已经被 EXCEPT_FILTER 修复。返回 ExceptionContinueExecution。
2. 返回 EXCEPTION_CONTINUE_SEARCH，继续遍历下一个 ScopeRecord。
3. 返回 EXCEPTION_EXECUTE_HANDLER，说明当前 ScopeRecord.JumpTarget 代表的 EXCEPT_HANDLER 可以处理该异常。那么调用 RtlUnwindEx 进行展开。

熟悉 x86 的朋友可能会疑惑：在 x86 中 nt!_except_handler3 先进行全局展开，然后对本函数自身进行不完全的局部展开，最后执行 EXCEPT_HANDLER。而在 nt!__C_specific_handler 中却找不到执行 EXCEPT_HANDLER 的指令，这是怎么回事？
实际上，x64 对这个流程做了一些调整，EXCEPT_HANDLER 不是由 nt!__C_specific_handler 直接调用，而是作为参数传给 RtlUnwindEx，RtlUnwindEx 处理完展开之后才执行 EXCEPT_HANDLER。后续我们在讲展开的时候会看到具体的方法。

__C_specific_handler 的展开分支，是对 SCOPE_TABLE 进行展开，逻辑很简单，不多讲了。

更详细的信息，请参考上面反汇编代码中我附的注释。

另外还需要说一下 SCOPE_TABLE。
在 x86 中，遍历 scopetable 时是通过运行时动态改变的 EXCEPTION_REGISTRATION::trylevel 来确定应该首先遍历哪一个 scopetable_entry。而 x64 中没有等同于 trylevel 的数据，有的朋友可能会说“SCOPE_TABLE 中不是有每个 __try 保护域的范围 RVA 吗？通过范围不就可以确定在哪个 __try 中触发了异常吗？”。
我们可以先试试这种方法，以下面这段伪码为例，

Code:

    1 VOID SehTest()

    2 {

    3     __try // 1

    4     {

    5     }

    6     __except()

    7     {

    8     }

    9 

    10    __try // 2

    11    {

    12        __try // 3

    13        {

    14            ...

    15        }

    16        __except()

    17        {

    18        }

    19    }

    20    __except()

    21    {

    22    }

    23

    24    __try // 4

    25    {

    26    }

    27    __finally()

    28    {

    29    }

    30}

上述伪码中总共有4个 __try，按照 x86 中的方法，SCOPE_TABLE 的内容应该是顺序排列的，像这样：

SCOPE_TABLE::Count 等于4，
SCOPE_TABLE::ScopeRecord[0] 表示行3开始的 __try/__except，
SCOPE_TABLE::ScopeRecord[1] 表示行10开始的 __try/__except，
SCOPE_TABLE::ScopeRecord[2] 表示行12开始的 __try/__except，
SCOPE_TABLE::ScopeRecord[3] 表示行24开始的 __try/__finally。

假设行14处触发了异常，遍历过程应该是这样，
首先检查 ScopeRecord[0]，发现其范围不包含 EXCEPT_POINT，继续下一个，
开始检查 ScopeRecord[1]，范围匹配了。

那是不是该把异常交给 ScopeRecord[1] 处理呢？
不是！从伪码中可以很明显的看出，行14触发的异常应该首先由行12开始的 __try/__except，即 ScopeRecord[1] 处理。

可见这种方法是行不通的。
MSC 通过调整 SCOPE_TABLE::ScopeRecord 的排列顺序来解决这个问题：

SCOPE_TABLE::Count 等于4，
SCOPE_TABLE::ScopeRecord[0] 表示行3开始的 __try/__except，
SCOPE_TABLE::ScopeRecord[1] 表示行12开始的 __try/__except，
SCOPE_TABLE::ScopeRecord[2] 表示行10开始的 __try/__except，
SCOPE_TABLE::ScopeRecord[3] 表示行24开始的 __try/__finally。

即对于嵌套的 __try/__except/__finally，ScopeRecord 的排列顺序是，最内层的 __try 排在前面，其次是次内层的，依次排到最外层。
这样就能正确的遍历 SCOPE_TABLE 了。

再用伪码完整的展示一下 SCOPE_TABLE 的布置，

SCOPE_TABLE::Count = 4。

SCOPE_TABLE::ScopeRecord[0].BeginAddress = RVA_L4; （行4的 RVA） // 第一个 __try
SCOPE_TABLE::ScopeRecord[0].EndAddress = RVA_L5;
SCOPE_TABLE::ScopeRecord[0].HandlerAddress = RVA_L6_EXCEPT_FILTER; （行6 __except 过滤代码首地址的 RVA）
SCOPE_TABLE::ScopeRecord[0].JumpTarget = RVA_L7;

SCOPE_TABLE::ScopeRecord[1].BeginAddress = RVA_L13; // 第三个 __try
SCOPE_TABLE::ScopeRecord[1].EndAddress = RVA_L15;
SCOPE_TABLE::ScopeRecord[1].HandlerAddress = RVA_L16_EXCEPT_FILTER;
SCOPE_TABLE::ScopeRecord[1].JumpTarget = RVA_L7;

SCOPE_TABLE::ScopeRecord[2].BeginAddress = RVA_L11; // 第二个 __try
SCOPE_TABLE::ScopeRecord[2].EndAddress = RVA_L19;
SCOPE_TABLE::ScopeRecord[2].HandlerAddress = RVA_L20_EXCEPT_FILTER;
SCOPE_TABLE::ScopeRecord[2].JumpTarget = RVA_L21;

SCOPE_TABLE::ScopeRecord[3].BeginAddress = RVA_L25; // 第四个 __try
SCOPE_TABLE::ScopeRecord[3].EndAddress = RVA_L26;
SCOPE_TABLE::ScopeRecord[3].HandlerAddress = RVA_L28;
SCOPE_TABLE::ScopeRecord[3].JumpTarget = 0;

我们再模拟一下 nt!__C_specific_handler 是如何遍历 SCOPE_TABLE 的：
1. 首先通过传入参数中的 pDispatcherContext->ControlPc 和 pDispatcherContext->ImageBase 计算出异常触发点的 RVA（简称 E_RVA）。参见 fffff800`008a430d 处的指令。
2. 通过 pDispatcherContext->ScopeIndex 确认是否需要遍历。如果需要遍历，则从它指定的 ScopeRecord 开始遍历。pDispatcherContext->ScopeIndex 一般都为0，只有返回 ExceptionCollidedUnwind 时，RtlDispatchException 才可能将它设置为其他值。
3. 通过比较 E_RVA 和 ScopeRecord[?].BeginAddress、ScopeRecord[?].EndAddress 来找到正确的处理函数，
首先 ScopeRecord[0] 范围不匹配，遍历下一个，
然后 ScopeRecord[1]，发现范围匹配，并且是 __try/__except 组合。于是调用 ScopeRecord[1].HandlerAddress，假设它返回的是 EXCEPTION_CONTINUE_SEARCH，那么继续遍历下一个，
这次是 ScopeRecord[2]，发现范围匹配，并且是 __try/__except 组合。于是调用 ScopeRecord[2].HandlerAddress，假设它返回的是 EXCEPTION_EXECUTE_HANDLER，那么说明找到了解决方案。
4. 调用 RtlUnwindEx，把 ScopeRecord[2].JumpTarget 对应的绝对地址作为 TargetIp 参数传给它。RtlUnwindEx 全局展开完毕后执行 TargetIp。

到这里，异常分发就大致讲述完毕。接下来是关于展开和解决的内容。

三、展开、解决

x64 中展开使用的函数有 RtlVirtualUnwind、RtlUnwindEx 和 RtlpExecuteHandlerForUnwind。其中 RtlVirtualUnwind 已经讲了，我们来看看余下的两个。

首先是 RtlUnwindEx，原型如下：

Code:

    VOID

    RtlUnwindEx (

        IN PVOID TargetFrame OPTIONAL,

        IN PVOID TargetIp OPTIONAL,

        IN PEXCEPTION_RECORD ExceptionRecord OPTIONAL,

        IN PVOID ReturnValue,

        IN PCONTEXT OriginalContext,

        IN PUNWIND_HISTORY_TABLE HistoryTable OPTIONAL

        );

参数分别是：
TargetFrame —— 目标帧，即最后一个需要展开的帧。
TargetIp —— 前面有讲过，它就是 ScopeRecord[?].JumpTarget 代表的地址，即 EXCEPT_HANDLER。
ExceptionRecord —— 异常信息。
ReturnValue —— 传递给 TargetIp 的返回值，分析过程中没发现它有什么用处。
OriginalContext —— 虽然被声明为 IN，但是实际上 RtlUnwindEx 并没有使用它内部的数据，
HistoryTable —— 用于加速查找 RUNTIME_FUNCTION。

主要功能是：
从自身开始展开，到 TargetFrame 停止。然后跳转到 TargetIp 继续执行。
流程：
1. 申请一个类型为 CONTEXT 的局部变量 l_Context，调用 RtlCaptureContext 将当前自身的环境复制到 l_Context。
2. 通过 RtlVirtualUnwind 对 l_Context 进行模拟展开，推动遍历。对每个遍历到的 UNWIND_INFO，检查 UNWIND_INFO::Flags 是否包含 UNW_FLAG_UHANDLER。如果包含，则调用 UNWIND_INFO::ExceptionHandler 进行局部展开。否则继续遍历下一个。
循环本步骤，直到展开到 TargetFrame，即到达解决异常的 EXCEPT_HANDLER 所在的函数（简称为 ExceptionHandlerFunc）了。
3. 这时 l_Context 内已经是从 RtlUnwindEx 完整展开到 EXCEPT_HANDLER 的环境了。即此时 l_Context 已经是 ExceptionHandlerFunc 的执行环境了。
调用 RtlRestoreContext，用 l_Context 替换当前线程的执行环境，于是就跳转到 EXCEPT_HANDLER 继续执行。
这样就完美的从触发异常的环境跳到了新的环境中。

这个过程有点类似这种手法：
1. 将某台机器的系统 ghost 到一个 bak.gho 文件。
2. 把 bak.gho 恢复到一台临时机器，然后对这台临时机器做一些调整。调整完毕后制作一个临时机器的 bak_mod.gho。
3. 将 bak_mod.gho 恢复到原来那台机器。

这个流程很重要，我手绘了一副图帮助理解，

伪码：

Code:

    __try

    {

        ExRaiseStatus(STATUS_INVALID_PARAMETER);

    }

    __except(EXCEPTION_EXECUTE_HANDLER)

    {

    }

图：
1. 异常解决流程，从 EXCEPT_POINT 到 RtlUnwindEx，途中已经找到能够解决该异常的 EXCEPT_HANDLER 了（以参数 TargetIp 表示），当前线程状态为 ThreadContext

Code:

+---------------------------------------+

| ......                                |

| RtlRaiseStatus                    |调 |

| RtlDispatchException              |用 |-> ThreadContext &

| RtlpExecuteHandlerForException    |方 |   TargetIp = ExceptionHandler

| __C_specific_handler              |向 |

| RtlUnwindEx                       v   |

|                                       |

+---------------------------------------+

2. RtlUnwindEx 将当前自身状态复制到 ThreadContext_Copy 中

Code:

+---------------------------------------+                                     +---------------------------------------+

| ......                                |                                     | ......                                |

| RtlRaiseStatus                    |调 |                                     | RtlRaiseStatus                    |调 |

| RtlDispatchException              |用 |-> ThreadContext &                   | RtlDispatchException              |用 |-> ThreadContext_Copy &

| RtlpExecuteHandlerForException    |方 |   TargetIp = ExceptionHandler       | RtlpExecuteHandlerForException    |方 |   TargetIp = ExceptionHandler

| __C_specific_handler              |向 |                                     | __C_specific_handler              |向 |

| RtlUnwindEx                       v   |                                     | RtlUnwindEx                       v   |

|                                       |                                     |                                       |

+---------------------------------------+                                     +---------------------------------------+

3. 用 ThreadContext_Copy 进行展开，一直展开到异常触发点停止。

Code:

+---------------------------------------+                                     +---------------------------------------+

| .....                                 |                                     | ......                                |

| RtlRaiseStatus                    |调 |                                     | RtlRaiseStatus                    ^展 |

| RtlDispatchException              |用 |-> ThreadContext                     | RtlDispatchException              |开 |-> ThreadContext_Copy &

| RtlpExecuteHandlerForException    |方 |   TargetIp = ExceptionHandler       | RtlpExecuteHandlerForException    |方 |   TargetIp = ExceptionHandler

| __C_specific_handler              |向 |                                     | __C_specific_handler              |向 |

| RtlUnwindEx                       v   |                                     | RtlUnwindEx                       |   |

|                                       |                                     |                                       |

+---------------------------------------+                                     +---------------------------------------+

4. 将 ThreadContext_Copy.Rip 设置为 TargetIp，以 ThreadContext_Copy 为参数调用 RtlpRestoreContext。跳转到 TargetIp 继续执行。

Code:

+---------------------------------------+

| ......                                |

| EXCEPT_HANDLER                        |-> ThreadContext (ThreadContext.Rip = TargetIp)

|                                       |

+---------------------------------------+

这样就完成了展开和执行 EXCEPT_HANDLER 的工作。

RtlpExecuteHandlerForUnwind 没有什么改变，原型依旧：

Code:

    EXCEPTION_DISPOSITION

    RtlpExecuteHandlerForUnwind (

        IN PEXCEPTION_RECORD ExceptionRecord,

        IN PVOID EstablisherFrame,

        IN OUT PCONTEXT ContextRecord,

        IN OUT PVOID DispatcherContext

        );

它会注册一个异常处理函数 RtlpUnwindHandle，当触发新异常时 RtlpUnwindHandler 会返回 ExceptionCollidedUnwind。关于 ExceptionCollidedUnwind，我们后面还会详细讲述。
RtlpExecuteHandlerForUnwind 的实现源码位于 $\WRK-v1.2\base\ntos\rtl\amd64\xcptmisc.asm:199。
RtlpUnwindHandle 的实现源码位于 $\WRK-v1.2\base\ntos\rtl\amd64\xcptmisc.asm:136。

到这里，我们讲完了展开的逻辑。接下来我们要讲述两个比较特殊的返回值： ExceptionNestedException 和 ExceptionCollidedUnwind。

四、ExceptionNestedException 和 ExceptionCollidedUnwind

之所以专门讲述这两个返回值，是因为在分析过程中，我感觉常规情况的 SEH 流程理解起来并不困难，难理解的是这两种不一般的情况。它们不一般之处在于：在处理异常的过程中又触发了新的异常。
先来讲一下这两个返回值的含义：
ExceptionNestedException —— 在异常分发过程中触发新的异常，比如执行 EXCEPT_FILTER 时触发异常。
ExceptionCollidedUnwind —— 在展开过程中触发新的异常，比如执行 FINALLY_HANDLER 时触发异常。

首先来讲讲 ExceptionNestedException，以如下伪码为例：

Code:

    1  VOID SehTest()

    2  {

    3      __try

    4      {

    5          ExRaiseStatus();

    6      }

    7      __except(ExRaiseStatus(), EXCEPTION_CONTINUE_SEARCH) // EXCEPT_FILTER_1

    8      { // EXCEPT_HANDLER_1

    9      }

    10 }

    11 

    12 VOID Caller()

    13 {

    14     __try

    15     {

    16         SehTest();

    17     }

    18     __except(EXCEPTION_EXECUTE_HANDLER) // EXCEPT_FILTER_2

    19     { // EXCEPT_HANDLER_2

    20     }

    21 }

上述代码会两次触发异常，第一次是行5的 ExRaiseStatus，第二次是行7的 ExRaiseStatus。为了方便区分，我将它们分别标记为 EXCEPT_POINT#1、EXCEPT_POINT#2。
我们来看一下这两个异常的处理流程：

1. ExRaiseStatus#1 会创建保存 EXCEPT_POINT#1 触发时的状态 Context#1，并构建一个 EXCEPTION_RECORD，然后将他们作为参数来调用 RtlDispatchException#1。（注：这种方式的的触发点是 ExRaiseStatus 内部，而非 SehTest 的第5行。即Context#1 记录的异常触发点是 ExRaiseStatus#1 内部）

2. RtlDispatchException#1 根据 Context#1 首先找到 EXCEPT_POINT#1 所在函数 ExRaiseStatus#1 的 UNWIND_INFO，发现其 UNWIND_INFO::Flags 为 UNW_FLAG_NHANDLER，于是继续遍历。

3. RtlDispatchException#1 遍历到 SehTest，发现其 UNWIND_INFO::Flags 为 UNW_FLAG_EHANDLER，于是调用其 UNWIND_INFO::ExceptionHandler，即 __C_specific_handler$2。__C_specific_handler$2 遍历 SehTest 的 SCOPE_TABLE，发现唯一的一个 ScopeRecord。于是执行 ScopeRecord[0].HandlerAddress，即行7的 SehTest::EXCEPT_FILTER_1#1。此时的调用栈如下（竖线后的内容为函数的 UNWIND_INFO::Flags 和 UNWIND_INFO::ExceptionHandler，其中 Flags 缩写为 E、U、N）：

Code:

        (1)  Caller                                 | E  & __C_specific_handler$1

        (2)  SehTest                                | E  & __C_specific_handler$2

        (3)  ExRaiseStatus#1                        | N

        (4)  RtlDispatchException#1                 | N

        (5)  RtlpExecuteHandlerForException#1       | EU & RtlpExceptionHandler$5

        (6)  __C_specific_handler$2                 | N

        (7)  EXCEPT_FILTER_1#1                      | N

4. EXCEPT_FILTER#1 触发 EXCEPT_POINT#2。同步骤1类似，ExRaiseStatus 会调用 RtlDispatchException#2，这个过程中同样会创建保存 EXCEPT_POINT#2 的状态，我们称之为 Context#2。

5. RtlDispatchException#2 根据 Context#2 找到了 EXCEPT_POINT#2 所在函数 ExRaiseStatus#2，发现其 UNWIND_INFO::Flags 为 UNW_FLAG_NHANDLER，于是继续遍历。

6. RtlDispatchException#2 遍历到 EXCEPT_FILTER_1#1，发现其 UNWIND_INFO::Flags 为 UNW_FLAG_NHANDLER，于是继续遍历。（注：EXCEPT_FILTER 虽然代码形式上从属于 SehTest 函数，但实际上它是一个单独的函数，有自己的 UNWIND_INFO，跟 SEH 的 UNWIND_INFO 并不是同一个）

7. RtlDispatchException#2 遍历到 __C_specific_handler$2、RltpExecuteHandlerForException#1、RtlDispatchException#1、ExRaiseStatus#1，这些函数要么被标记为 UNW_FLAG_NHANDLER，要么 UNWIND_INFO::ExceptionHandler 返回 ExcetpionNestedException，结果都是继续遍历，所以不再一一讲述。继续遍历下一个。

8. RtlDispatchException#2 遍历到 SehTest，发现其 UNWIND_INFO::Flags 为 UNW_FLAG_EHANDLER，于是调用其 UNWIND_INFO::ExceptionRoutine，即 __C_specific_handler$2，发现范围匹配，于是调用 EXCEPT_FILTER_1#1，于是又触发异常，这次是 #3 异常。此时的调用栈如下：

Code:

        (1)  Caller                                 | E  & __C_specific_handler$1

        (2)  SehTest                                | E  & __C_specific_handler$2

        (3)  ExRaiseStatus#1                        | N

        (4)  RtlDispatchException#1                 | N

        (5)  RtlpExecuteHandlerForException#1       | EU & RtlpExceptionHandler$5

        (6)  __C_specific_handler$2                 | N

        (7)  EXCEPT_FILTER_1#1                      | N

        (8)  ExRaiseStatus#2                        | N

        (9)  RtlDispatchException#2                 | N

        (10) RtlpExecuteHandlerForException#2       | EU & RtlpExceptionHandler$10

        (11) __C_specific_handler$2                 | N

        (12) EXCEPT_FILTER_1#2                      | N

        (13) ExRaiseStatus#3                        | N

9. #3 异常的处理流程同 #2 的处理流程类似，也会再遍历到 __C_specific_handler$2，也会再调用 EXCEPT_FILTER_1，于是会触发 #4 异常、#5 异常等等。最终内核栈溢出，BSOD。

以上就是 ExceptionNestedException 的产生以及处理的流程。过程中还有一些细节操作，为了描述简洁，我没有在上述过程中一一讲述。

再来看看 ExceptionCollidedUnwind。它比 ExceptionNestedException 更复杂一些，我们以如下伪码为例，

Code:

    1  VOID SehTest()

    2  {

    3      __try

    4      {

    5          ExRaiseStatus();

    6      }

    7      __finally

    8      { // FINALLY_HANDLER_1

    9          ExRaiseStatus();

    10     }

    11 }

    12 

    13 VOID Caller()

    14 {

    15     __try

    16     {

    17         SehTest();

    18     }

    19     __except(EXCEPTION_EXECUTE_HANDLER) // EXCEPT_FILTER_2

    20     { // EXCEPT_HANDLER_2

    21     }

    22 }

伪码中也有两处触发异常的地方，第一次在行5，第二次在行9。也分别标记为 EXCEPT_POINT#1 和 EXCEPT_POINT#2。处理流程：

1. ExRaiseStatus#1 创建保存 EXCEPT_POINT#1 的状态 Context#1，并构建一个 EXCEPTION_RECORD，然后将他们作为参数来调用 RtlDispatchException#1。

2. RtlDispatchException#1 根据 Context#1 开始遍历：
首先遍历到 EXCEPT_POINT#1 所在函数 ExRaiseStatus，发现其 UNWIND_INFO::Flags 为 UNW_FLAG_NHANDLER，于是遍历下一个。
然后遍历到 SehTest，发现其 UNWIND_INFO::Flags 为 UNW_FLAG_UHANDLER，于是继续遍历下一个。
然后遍历到 Caller，发现其 UNWIND_INFO::Flags 为 UNW_FLAG_EHANDLER，于是调用其 UNWIND_INFO::ExceptionRoutine 即 __C_specific_handler。__C_specific_handler 发现可以处理该异常，于是以 EXCEPT_HANDLER_2 为 TargetIp 参数调用 RtlUnwindEx。

3. RtlUnwindEx 从自身开始展开，展开到 SehTest，执行 FINALLY_HANDLER_1 时触发新异常。此时调用栈为：

Code:

    (1)  Caller                              | E  & __C_specific_handler$1

       (2)  SehTest                             | U  & __C_specific_handler$2

       (3)  ExRaiseStatus#1                     | N

       (4)  RtlDispatchException#1              | N

       (5)  RtlpExecuteHandlerForException#1    | EU & RtlpExceptionHandler$5

       (6)  __C_specific_handler$1              | N

       (7)  RtlUnwindEx#1                       | N

       (8)  RtlpExecuteHandlerForUnwind#1       | EU & RtlpUnwindHandler$8

       (9)  __C_specific_handler$2              | N

       (10) FINALLY_HANDLER_1                   | N

       (11) ExRaiseStatus#2                     | N

需要说明的是，调用栈(7) RtlUnwindEx 创建并初始化了一个 DISPATCHER_CONTEXT 变量（后续称之为 pDispatcherContextForUnwind），并作为参数传递给调用栈(8) RltpExecuteHandlerForUnwind，后者在调用(9) __C_specific_handler$2 之前将 pDispatcherContextForUnwind 保存在自己的栈中。此时 pDispatcherContextForUnwind 的内容表示的是调用栈(2) SehTest 的情况。后续步骤会用到这个 pDispatcherContextForUnwind。

4. (11) ExRaiseStatus#2 将 EXCEPT_POINT#2 触发时的状态保存到 Context#2，然后调用 RtlDispatchException#2 进行 EXCEPT_POINT#2 的分发。

5. RtlDispatchException#2 根据 Context#2 开始遍历，
首先遍历到 EXCEPT_POINT#2 所在函数 ExRaiseStatus#2，发现其 UNWIND_INFO::Flags 为 UNW_FLAG_NHANDLER，于是遍历下一个。
然后遍历到 FINALLY_HANDLER_1（同前面提到的 EXCEPT_FILTER 一样，FINALLY_HANDLER 实际上也是一个单独的函数，有自己的 RUNTIME_FUNCTION 和 UNWIND_INFO），发现其 UNWIND_INFO::Flags 为 UNW_FLAG_NHANDLER，于是遍历下一个。
然后遍历到(9) __C_specific_handler$2，发现其 UNWIND_INFO::Flags 为 UNW_FLAG_NHANDLER，于是继续遍历。
然后遍历到(8) RtlpExecuteHandlerForUnwind#1，发现其 UNWIND_INFO::Flags 包含 UNW_FLAG_EHANDLER。于是调用其 UNWIND_INFO::ExceptionRoutine 即 RtlpUnwindHandler$8。RtlpUnwindHandler$8 会取出步骤3中所提到的 pDispatcherContextForUnwind，将其内容拷贝到自己的传出参数（参考 RtlpUnwindHandler 的函数原型）pDispatcherContext 中，然后返回 ExceptionCollidedUnwind。

6. RtlDispatchException#2 收到 ExceptionCollidedUnwind 后，从传回来的 pDispatchContext 中取出诸如 ControlPc、EstablisherFrame 等值（如步骤3所说，此时这些值反应的是(2) SehTest 的状态），用这些值来继续遍历。
首先遍历到(2) SehTest，调用 RtlpExecuteHandlerForException#2，进而调用 __C_specific_handler$2，但是发现 pDispatcherContext->ScopeIndex（步骤(9)中在调用(10) FINALLY_HANDLER_1 之前+1了，参考 __C_specific_handler 反汇编码）等于 pDispatcherContext->HandlerData->Count。于是继续遍历。
然后遍历到(1) Caller，调用 RtlpExecuteHandlerForException#2，进而调用 __C_specific_handler$1，发现它可以处理 #2 异常，于是以 EXCEPT_HANDLER#2 为 TargetIp 参数调用 RtlUnwindEx。此时调用栈如下：

Code:

    (1)  Caller                              | E  & __C_specific_handler$1

       (2)  SehTest                             | U  & __C_specific_handler$2，但没有 EXCEPT_HANDLER

       (3)  ExRaiseStatus#1                     | N

       (4)  RtlDispatchException#1              | N

       (5)  RtlpExecuteHandlerForException#1    | EU & RtlpExceptionHandler$6

       (6)  __C_specific_handler$1              | N

       (7)  RtlUnwindEx#1                       | N

       (8)  RtlpExecuteHandlerForUnwind#1       | EU & RtlpUnwindHandler$8

       (9)  __C_specific_handler$2              | N

       (10) FINALLY_HANDLER#1                   | N

       (11) ExRaiseStatus#2                     | N

       (12) RtlDispatchException#2              | N

       (13) RtlpExecuteHandlerForException#2    | EU & RtlpExceptionHandler

       (14) __C_specific_handler$1              | N

       (15) RtlUnwindEx                         | N

7. (17) RtlUnwindEx 展开完毕后，通过 RtlRestoreContext 跳转到 EXCEPT_HANDLER#2 继续执行。

在上述过程中，我们可以发现，遍历过程中 RtlDispatchException 等系统函数被频繁遍历到。于是就有了前面提到的全局展开历史表 RtlpUnwindHistoryTable，这个表中存放着 RtlDispatchException、RtlUnwindEx 等函数的 RUNTIME_FUNCTION 和 ImageBase 信息，这样就不用每次都去解析 PE+ 中的 ExceptionDirectory，实现了加速。

到这里，我们就讲完了 x64 SEH 的实现。可以发现，x64 和 x86 的 SEH 思想或者说框架是一样的：
1. RtlDispatchException 和 RtlUnwindEx 都对异常注册信息进行遍历。前者是为了分发异常而遍历，后者是为了展开而遍历。
2. MSC 提供的异常处理函数按照“异常解决”和“展开”两个分支，对 SCOPE_TABLE/scopetable 进行遍历。前者是为了找到 EXCEPT_FILTER & EXCEPT_HANDLER，后者是为了找到 FINALLY_HANDLER。
3. RtlDispatchException 和 RtlUnwindEx 借助 MSC 提供的异常处理函数这个桥梁，配合处理异常。
主要的改变有两点：
1. RtlDispatchException 和 RtlUnwindEx 通过调用 RtlVirtualUnwind 推动遍历。
2. 所有的非叶函数都参与到 SEH，尽管大部分的函数都没有使用到 SEH。

以上我们主要讲述的是 x64 SEH 的内部实现。对于使用者，也有一个好消息，我们来看看，

C 代码：

Code:

    VOID SehTest()

    {

        __try

        {

            __try

            {

                ExRaiseStatus(STATUS_INVALID_PARAMETER);

                DbgPrint("%u [%s] __try \n", __LINE__, __FILE__);

            }

            __except((STATUS_INVALID_PARAMETER == GetExceptionCode()) ? EXCEPTION_CONTINUE_SEARCH : EXCEPTION_EXECUTE_HANDLER)

            {

                DbgPrint("%u [%s] __except \n", __LINE__, __FILE__);

            }

        }

        __finally

            DbgPrint("%u [%s] __finally \n", __LINE__, __FILE__);

        }

    }

反汇编码：

Code:

    kd> uf passthrough!SehTest

    PassThrough!SehTest:

    fffffadf`f1100020 sub     rsp,38h

    fffffadf`f1100024 mov     ecx,0C000000Dh

    fffffadf`f1100029 call    qword ptr [PassThrough!_imp_ExRaiseStatus (fffffadf`f1101050)]

    fffffadf`f110002f lea     r8,[PassThrough! ?? ::FNODOBFM::`string' (fffffadf`f1100500)]

    fffffadf`f1100036 mov     edx,39h

    fffffadf`f110003b lea     rcx,[PassThrough! ?? ::FNODOBFM::`string' (fffffadf`f1100540)]

    fffffadf`f1100042 call    PassThrough!DbgPrint (fffffadf`f11004a6)

    fffffadf`f1100047 jmp     PassThrough!SehTest+0x42 (fffffadf`f1100062)

    PassThrough!SehTest+0x42:

    fffffadf`f1100062 lea     r8,[PassThrough! ?? ::FNODOBFM::`string' (fffffadf`f1100500)]

    fffffadf`f1100069 mov     edx,42h

    fffffadf`f110006e lea     rcx,[PassThrough! ?? ::FNODOBFM::`string' (fffffadf`f1100570)]

    fffffadf`f1100075 call    PassThrough!DbgPrint (fffffadf`f11004a6)

    fffffadf`f110007a add     rsp,38h

    fffffadf`f110007e ret

我们发现 SehTest 内部完全没有任何 SEH 的踪迹，不像 x86 那样会有创建、销毁 EXCEPTION_REGISTRATION_RECORD 和调整 EXCEPTION_REGISTRATION_RECORD::trylevel 等操作。
这样的好处就是使用者无需再担心性能损耗，可以放心大胆的使用 SEH 机制了。

附录一

为了方便自己分析，我写了一个简单的 windbg 扩展，提供了几个 x64 seh 常用功能：

Code:

    !boxr.unwindinfo    module-name    unwindinfo_addr

    功能：

        用于查询指定 UNWIND_INFO 结构的详细信息。

    参数说明：

        module-name —— 待查询的 UNWIND_INFO 结构对应函数的模块名

        unwindinfo_addr —— UNWIND_INFO 结构的绝对地址

Code:

    !boxr.rtfn    option    module    runtimefunction_addr

    功能：

        用于查询指定 RUNTIME_FUNCTION 结构的详细信息。（rtfn 表示 RunTime_FunctioN）

    参数说明：

        option —— 参数选项，目前支持两种：

            /a 表示 module 参数为模块基地址

            /n 表示 module 参数为模块名称

        module —— RUNTIME_FUNCTION 结构对应函数所在的模块，具体形式根据 option 而定。

        runtimefunction_addr —— 需要查询的 RUNTIME_FUNCTION 结构体的绝对地址。支持 @rax 操作方式，但不支持复杂的组合，比如 @rax+8。

使用的方法是：用 .extpath+ 命令将 boxr.dll 所在的目录添加到 windbg 的搜索路径中，然后就可以使用了。需要卸载时就 .unload。

简单说明一下这两个命令。

比如我们要查看下面这个函数的 UNWIND_INFO 信息：

Code:

    VOID SehTest()

    {

        __try

        {

            DbgPrint("%u [%s] __try \n", __LINE__, __FILE__);

        }

        __except(EXCEPTION_EXECUTE_HANDLER)

        {

            DbgPrint("%u [%s] __except \n", __LINE__, __FILE__);

        }

        __try

        {

            __try

            {

                __try

                {

                    CollidedUnwind();

                }

                __except(EXCEPTION_EXECUTE_HANDLER)

                {

                    DbgPrint("%u [%s] __except \n", __LINE__, __FILE__);

                }

            }

            __except(EXCEPTION_EXECUTE_HANDLER)

            {

                DbgPrint("%u [%s] __except \n", __LINE__, __FILE__);

            }

        }

        __finally

        {

            DbgPrint("%u [%s] __finally \n", __LINE__, __FILE__);

        }

        __try

        {

            DbgPrint("%u [%s] __try \n", __LINE__, __FILE__);

            __try

            {

                DbgPrint("%u [%s] __try \n", __LINE__, __FILE__);

            }

            __finally

            {

                DbgPrint("%u [%s] __finally \n", __LINE__, __FILE__);

            }

        }

        __except(EXCEPTION_EXECUTE_HANDLER)

        {

            DbgPrint("%u [%s] __except \n", __LINE__, __FILE__);

        }

        return;

    }

操作步骤：
1. 使用 .fnent 命令获得 SehTest 的基本信息，

Code:

        kd> .fnent passthrough!SehTest

        Debugger function entry 00000000`00758210 for:

        (fffffadf`f135d080)   PassThrough!SehTest   |  (fffffadf`f135d180)   PassThrough!LeafTest

        Exact matches:

            PassThrough!SehTest (void)

        BeginAddress      = 00000000`00001080

        EndAddress        = 00000000`00001175

        UnwindInfoAddress = 00000000`000026b8

        Unwind info at fffffadf`f135e6b8, 10 bytes

          version 1, flags 3, prolog 4, codes 1

          handler routine: PassThrough!_C_specific_handler (fffffadf`f135d5de), data 6

          00: offs 4, unwind op 2, op info 4    UWOP_ALLOC_SMALL.

2. 使用 !boxr.unwindinfo 查询详细信息，

Code:

        kd> !boxr.unwindinfo passthrough fffffadf`f135e6b8

        _UNWIND_INFO for fffffadff135e6b8 

        Flags:

            EU

        ExceptionRoutine:

            PassThrough!_C_specific_handler (fffffadf`f135d5de)

        ScopeTable:

            Count: 6

            ScopeRecord[0]      (fffffadff135e6c8)

                BeginAddress: 

                    PassThrough!SehTest+0x4 (fffffadf`f135d084)

                EndAddress: 

                    PassThrough!SehTest+0x1e (fffffadf`f135d09e)

                HandlerAddress: 

                    PassThrough!SehTest$filt$0 (fffffadf`f135d8a0)

                JumpTarget: 

                    PassThrough!SehTest+0x1e (fffffadf`f135d09e)

            [省略中间3个 ScopeRecord 成员]

            ScopeRecord[5]      (fffffadff135e718)

                BeginAddress: 

                    PassThrough!SehTest+0x8b (fffffadf`f135d10b)

                EndAddress: 

                    PassThrough!SehTest+0xd7 (fffffadf`f135d157)

                HandlerAddress: 

                    PassThrough!SehTest$filt$5 (fffffadf`f135d960)

                JumpTarget: 

                    PassThrough!SehTest+0xd7 (fffffadf`f135d157)

!boxr.rtfn 的用法也类似，比如：

Code:

        kd> !box.rtfn /n passThrough @rax

        _RUNTIME_FUNCTION for fffffadff1113000 

        BeginAddress:

            PassThrough!CollidedUnwind (fffffadf`f1110020)

        EndAddress:

            PassThrough!CollidedUnwind+0x38 (fffffadf`f1110058)

        UnwindData:

            fffffadff1111688

        _UNWIND_INFO for fffffadff1111688 

        Flags:

            U

        ExceptionRoutine:

            PassThrough!_C_specific_handler (fffffadf`f11104ee)

        ScopeTable:

            Count: 1

            ScopeRecord[0]      (fffffadff1111698)

                BeginAddress: 

                    PassThrough!CollidedUnwind+0x4 (fffffadf`f1110024)

                EndAddress: 

                    PassThrough!CollidedUnwind+0x10 (fffffadf`f1110030)

                HandlerAddress: 

                    PassThrough!CollidedUnwind$fin$0 (fffffadf`f1110750)

                JumpTarget: 

                    0

需要说明的是，我写这个扩展的目的仅仅是为了分析 x64 SEH 过程中能轻松的查看相关数据结构的详细信息，所以并没有在这个扩展上花很多时间。其代码是从 MS 例子代码的基础上增加了我需要的功能。应该有一些 BUG，但是对我来说不重要，已经满足我的需要了。源码也放在附件里，方便分析的朋友根据自己的需要进行修改。
另外有一个疑问：我编译的 x64 wrk1.2 内核无法对 .c代码进行源码调试，对 .asm 代码倒是可以，这是为什么？我看了一下编译选项，没看出什么猫腻。有经验的朋友分享一下吧，感谢 :-)

附录二 RtlUnwindEx 的反汇编代码和注释

由于无法源码调试，只好把它反汇编出来加上注释……

Code:

VOID

             RtlUnwindEx (

/* rcx    */     IN PVOID pEstablisherFrame OPTIONAL,

/* rdx    */     IN PVOID pJumpTargetIp OPTIONAL,

/* r8     */     IN PEXCEPTION_RECORD pExceptionRecord OPTIONAL,

/* r9     */     IN PVOID ReturnValue,

/* rsp+28 */     IN PCONTEXT pOriginalContext,

/* rsp+30 */     IN PUNWIND_HISTORY_TABLE pHistoryTable OPTIONAL

                 );

             kd> uf nt!RtlUnwindEx

             nt!RtlUnwindEx:

             fffff800`00891e70 mov     qword ptr [rsp+20h],r9

             fffff800`00891e75 mov     qword ptr [rsp+18h],r8

             fffff800`00891e7a mov     qword ptr [rsp+10h],rdx

             fffff800`00891e7f mov     rax,rsp

             fffff800`00891e82 sub     rsp,678h

             fffff800`00891e89 mov     qword ptr [rax-8],rbx

             fffff800`00891e8d mov     qword ptr [rax-10h],rbp

             fffff800`00891e91 mov     qword ptr [rax-18h],rsi

             fffff800`00891e95 mov     rsi,qword ptr [rsp+6A0h] ; rsi = pOriginalContext

             fffff800`00891e9d mov     qword ptr [rax-20h],rdi

             fffff800`00891ea1 mov     qword ptr [rax-28h],r12

             fffff800`00891ea5 mov     qword ptr [rax-40h],r15

             fffff800`00891ea9 mov     rbp,rcx

             fffff800`00891eac mov     r15,rdx

             fffff800`00891eaf lea     rdx,[rsp+40h] ; rsp+40 为 l_HighLimit

             fffff800`00891eb4 lea     rcx,[rsp+50h] ; rsp+50 为 l_LowLimit

             fffff800`00891eb9 mov     rbx,r8

             fffff800`00891ebc mov     rdi,rsi

             fffff800`00891ebf lea     r12,[rax-518h] ; r12 = &l_Context

             fffff800`00891ec6 call    nt!RtlpGetStackLimits (fffff800`00890da0)

             fffff800`00891ecb mov     rcx,rsi

             fffff800`00891ece call    nt!RtlCaptureContext (fffff800`008bd150)

             fffff800`00891ed3 mov     rax,qword ptr [rsp+6A8h] ; rax = pHistoryTable

             fffff800`00891edb test    rax,rax

<            fffff800`00891ede je      nt!RtlUnwindEx+0x74 (fffff800`00891ee4)

.            

.            nt!RtlUnwindEx+0x70:

.            fffff800`00891ee0 mov     byte ptr [rax+4],1 ; pHistoryTable->Search = UNWIND_HISTORY_TABLE_GLOBAL

.            

.            nt!RtlUnwindEx+0x74:

>            fffff800`00891ee4 xor     ecx,ecx

             fffff800`00891ee6 test    rbx,rbx ; 判断 pExceptionRecord 是否为 NULL

<            fffff800`00891ee9 jne     nt!RtlUnwindEx+0xbc (fffff800`00891f2c)

.            

.            nt!RtlUnwindEx+0x7b:

.            ; pExceptionRecord 等于 NULL

.            fffff800`00891eeb mov     rax,qword ptr [rsi+0F8h]  ; rax = pOriginalContext->Rip

.            fffff800`00891ef2 lea     rbx,[rsp+0C0h]            ; rbx = &l_ExceptionRecord

.            fffff800`00891efa mov     dword ptr [rsp+0C0h],0C0000027h ; l_ExceptionRecord.ExceptionCode = STATUS_UNWIND (0xC0000027)

.            fffff800`00891f05 mov     qword ptr [rsp+0D0h],rax  ; l_ExceptionRecord.ExceptionAddress = pOriginalContext->Rip

.            fffff800`00891f0d mov     rax,qword ptr [rsp+6A8h]  ; rax = pHistoryTable

.            fffff800`00891f15 mov     qword ptr [rsp+690h],rbx  ; [r8-home] = &l_ExceptionRecord ????

.            fffff800`00891f1d mov     qword ptr [rsp+0C8h],rcx  ; l_ExceptionRecord.ExceptionRecord = NULL

.            fffff800`00891f25 mov     dword ptr [rsp+0D8h],ecx  ; l_ExceptionRecord.NumberParameters = 0

.            

.            nt!RtlUnwindEx+0xbc:

>            fffff800`00891f2c mov     rbx,qword ptr [rsp+680h]  ; rbx = &[rcx-home]

             fffff800`00891f34 mov     esi,2 ; l_ExceptionFlags(esi) = EXCEPTION_UNWINDING (2)

             fffff800`00891f39 mov     ecx,6 ; ecx = EXCEPTION_EXIT_UNWIND (6)

             fffff800`00891f3e test    rbp,rbp ; 判断 pEstablisherFrame 是否为 NULL

             fffff800`00891f41 mov     qword ptr [rsp+648h],r13 ; 保存 r13 

             fffff800`00891f49 mov     qword ptr [rsp+640h],r14 ; 保存 r14

             fffff800`00891f51 cmove   esi,ecx ; if (NULL == pEstablisherFrame) { l_ExceptionFlags = EXCEPTION_EXIT_UNWIND (6) }

             fffff800`00891f54 xchg    ax,ax

             fffff800`00891f58 xchg    ax,ax

             fffff800`00891f5c xchg    ax,ax

             nt!RtlUnwindEx+0xf0:

           > fffff800`00891f60 mov     r13,qword ptr [rdi+0F8h] ; r13 = pOriginalContext->Rip

           . fffff800`00891f67 lea     rdx,[rsp+60h] ; rdx = &l_pImageBase

           . fffff800`00891f6c mov     r8,rax        ; r8 = pHistoryTable

           . fffff800`00891f6f mov     rcx,r13

           . fffff800`00891f72 mov     qword ptr [rsp+68h],r13

           . fffff800`00891f77 call    nt!RtlLookupFunctionEntry (fffff800`00890e60)

           .                   ; l_pFunctionEntry = RtlLookupFunctionEntry(pOriginalContext->Rip, 

           .                   ;                                           &l_pImageBase,

           .                   ;                                           pHistoryTable)

           . fffff800`00891f7c test    rax,rax ; 判断 l_pFunctionEntry (eax) 是否为 NULL

           . fffff800`00891f7f mov     r14,rax ; r14 = l_pFunctionEntry

<          . fffff800`00891f82 je      nt!RtlUnwindEx+0x3ab (fffff800`0089221b)

.          . 

.          . nt!RtlUnwindEx+0x118:

.          . fffff800`00891f88 mov     rdx,rdi ; rdx = pOriginalContext

.          . fffff800`00891f8b mov     rcx,r12 ; rcx = &l_Context

.          . fffff800`00891f8e call    nt!RtlpCopyContext (fffff800`00891080)

.          .                   ; RtlpCopyContext(&l_Context, pOriginalContext)

.          . fffff800`00891f93 mov     rdx,qword ptr [rsp+60h] ; rdx = l_pImageBase

.          . fffff800`00891f98 mov     qword ptr [rsp+38h],0   ; _ARG_8 = 0

.          . fffff800`00891fa1 lea     rax,[rsp+680h]          ; rax = &[rcx-home]，这里被用作局部变量 l_pEstablisherFrame 空间

.          . fffff800`00891fa9 mov     r9,r14                  ; r9 = l_pFunctionEntry

.          . fffff800`00891fac mov     r8,r13                  ; r8 = pOriginalContext->Rip

.          . fffff800`00891faf mov     qword ptr [rsp+30h],rax ; _ARG7 = &l_pEstablisherFrame

.          . fffff800`00891fb4 lea     rax,[rsp+58h]           ; rax = &l_pHandlerData

.          . fffff800`00891fb9 mov     ecx,2                   ; ecx = UNW_FLAG_UHANDLER (2)

.          . fffff800`00891fbe mov     qword ptr [rsp+28h],rax ; _ARG_6 = &l_pHandlerData

.          . fffff800`00891fc3 mov     qword ptr [rsp+20h],r12 ; _ARG_5 = &l_Context

.          . fffff800`00891fc8 call    nt!RtlVirtualUnwind (fffff800`00891380)

.          .                   ; l_pExceptionRoutine = RtlVirtualUnwind(UNW_FLAG_UHANDLER,

.          .                   ;                                        l_pImageBase,

.          .                   ;                                        pOriginalContext->Rip,

.          .                   ;                                        l_pFunctionEntry,

.          .                   ;                                        &l_Context,

.          .                   ;                                        &l_pHandlerData,

.          .                   ;                                        &l_pEstablisherFrame,

.          .                   ;                                        NULL);

.          . fffff800`00891fcd mov     rbx,qword ptr [rsp+680h] ; rbx = l_pEstablisherFrame

.          . fffff800`00891fd5 mov     rcx,rax                  ; rcx = l_pExceptionRoutine

.          . fffff800`00891fd8 mov     qword ptr [rsp+48h],rax

.          . fffff800`00891fdd test    bl,7                     ; 检查 l_pEstablisherFrame 是否对齐

.<         . fffff800`00891fe0 jne     nt!RtlUnwindEx+0x431 (fffff800`008922a1)

..         . 

..         . nt!RtlUnwindEx+0x176:

..         . fffff800`00891fe6 cmp     rbx,qword ptr [rsp+50h]  ; cmp l_pEstablisherFrame, l_LowLimit

..<        . fffff800`00891feb jb      nt!RtlUnwindEx+0x184 (fffff800`00891ff4)

...        . 

...        . nt!RtlUnwindEx+0x17d:

...        . fffff800`00891fed cmp     rbx,qword ptr [rsp+40h]  ; cmp l_pEstablisherFrame, l_HighLimit

...<       . fffff800`00891ff2 jb      nt!RtlUnwindEx+0x1d3 (fffff800`00892043)

....       . 

....       . nt!RtlUnwindEx+0x184:

....       . ; 检查 l_pEstablisherFrame 是否合法

..>.       . fffff800`00891ff4 mov     cl,byte ptr gs:[20DEh]   ; cl = _KPCR->DpcRoutineActive

.. .       . fffff800`00891ffc test    cl,cl                    ; 判断当前是否在执行 DPC

.< .       . fffff800`00891ffe jne     nt!RtlUnwindEx+0x431 (fffff800`008922a1) ; 如果是在执行 DPC 则失败？??

.. .       . 

.. .       . nt!RtlUnwindEx+0x194:

.. .       . fffff800`00892004 mov     rcx,qword ptr [rsp+40h] ; rcx = l_HighLimit

.. .       . fffff800`00892009 mov     rax,qword ptr [rcx-28h] ; rax = l_KernelStackCtrl->Previous.StackBase

.. .       . fffff800`0089200d test    rax,rax                 ; 判断 l_KernelStackCtrl->Previous.StackBase 是否为 NULL

.< .       . fffff800`00892010 je      nt!RtlUnwindEx+0x431 (fffff800`008922a1)

.. .       . 

.. .       . nt!RtlUnwindEx+0x1a6:

.. .       . fffff800`00892016 mov     rdx,qword ptr [rcx-20h]  ; rdx = l_KernelStackCtrl->Previous.StackLimit

.. .       . fffff800`0089201a mov     rbx,qword ptr [rsp+680h] ; rbx = l_pEstablisherFrame

.. .       . fffff800`00892022 cmp     rbx,rdx                  ; cmp l_pEstablisherFrame, l_KernelStackCtrl->Previous.StackLimit

.< .       . fffff800`00892025 jb      nt!RtlUnwindEx+0x431 (fffff800`008922a1)

.. .       . 

.. .       . nt!RtlUnwindEx+0x1bb:

.. .       . fffff800`0089202b cmp     rbx,rax ; cmp l_pEstablisherFrame, l_KernelStackCtrl->Previous.StackBase

.< .       . fffff800`0089202e jae     nt!RtlUnwindEx+0x431 (fffff800`008922a1)

.. .       . 

.. .       . nt!RtlUnwindEx+0x1c4:

.. .       . fffff800`00892034 mov     rcx,qword ptr [rsp+48h] ; rcx = l_pExceptionRoutine

.. .       . fffff800`00892039 mov     qword ptr [rsp+50h],rdx ; l_LowLimit = l_KernelStackCtrl->Previous.StackLimit

.. .       . fffff800`0089203e mov     qword ptr [rsp+40h],rax ; l_HighLimit = l_KernelStackCtrl->Previous.StackBase

.. .       . 

.. .       . nt!RtlUnwindEx+0x1d3:

.. >       . fffff800`00892043 test    rbp,rbp ; 判断 pEstablisherFrame 是否为 NULL

.. <       . fffff800`00892046 je      nt!RtlUnwindEx+0x1e1 (fffff800`00892051)

.. .       . 

.. .       . nt!RtlUnwindEx+0x1d8:

.. .       . fffff800`00892048 cmp     rbp,rbx ; cmp pEstablisherFrame, l_pEstablisherFrame

.< .       . fffff800`0089204b jb      nt!RtlUnwindEx+0x431 (fffff800`008922a1)

.. .       . 

.. .       . nt!RtlUnwindEx+0x1e1:

.. >       . fffff800`00892051 test    rcx,rcx ; 判断 l_pExceptionRoutine 是否为 NULL

..  <      . fffff800`00892054 je      nt!RtlUnwindEx+0x39b (fffff800`0089220b)

..  .      . 

..  .      . nt!RtlUnwindEx+0x1ea:

..  .      . fffff800`0089205a mov     r13,qword ptr [rsp+58h] ; r13 = l_pHandlerData

..  .      . fffff800`0089205f mov     qword ptr [rsp+90h],r15 ; [rsp+90] = pJumpTargetIp

..  .      . fffff800`00892067 xor     r15d,r15d

..  .      . fffff800`0089206a xchg    ax,ax

..  .      . fffff800`0089206d xchg    ax,ax

..  .      . 

..  .      . nt!RtlUnwindEx+0x200:

..  .    > . fffff800`00892070 cmp     rbp,rbx ; cmp pEstablisherFrame, l_pEstablisherFrame

..  .<   . . fffff800`00892073 jne     nt!RtlUnwindEx+0x208 (fffff800`00892078)

..  ..   . . 

..  ..   . . nt!RtlUnwindEx+0x205:

..  ..   . . fffff800`00892075 or      esi,20h ; l_ExceptionFlags |= EXCEPTION_TARGET_UNWIND (0x20)

..  ..   . . 

..  ..   . . nt!RtlUnwindEx+0x208:

..  .>   . . fffff800`00892078 mov     r10,qword ptr [rsp+690h] ; r10 = &l_ExceptionRecord

..  .    . . fffff800`00892080 mov     rax,qword ptr [rsp+698h] ; rax = ReturnValue

..  .    . . fffff800`00892088 mov     qword ptr [rsp+0A0h],rcx ; l_DispatcherContext.LanguageHandler = l_pExceptionRoutine

..  .    . . fffff800`00892090 mov     dword ptr [r10+4],esi    ; l_ExceptionRecord.ExceptionFlags = l_ExceptionFlags

..  .    . . fffff800`00892094 mov     qword ptr [rdi+78h],rax  ; pOriginalContext->Rax = ReturnValue

..  .    . . fffff800`00892098 mov     rax,qword ptr [rsp+68h]  ; rax = pOriginalContext->Rip

..  .    . . fffff800`0089209d mov     qword ptr [rsp+70h],rax  ; l_DispatcherContext.ControlPc = pOriginalContext->Rip

..  .    . . fffff800`008920a2 mov     rax,qword ptr [rsp+60h]  ; rax = l_pImageBase

..  .    . . fffff800`008920a7 lea     r9,[rsp+70h]             ; r9 = &l_DispatcherContext

..  .    . . fffff800`008920ac mov     qword ptr [rsp+78h],rax  ; l_DispatcherContext.ImageBase = l_pImageBase

..  .    . . fffff800`008920b1 mov     rax,qword ptr [rsp+6A8h] ; rax = pHistoryTable

..  .    . . fffff800`008920b9 mov     r8,rdi                   ; r8 = pOriginalContext

..  .    . . fffff800`008920bc mov     rdx,rbx                  ; rdx = l_pEstablisherFrame

..  .    . . fffff800`008920bf mov     rcx,r10                  ; rcx = &l_ExceptionRecord

..  .    . . fffff800`008920c2 mov     qword ptr [rsp+80h],r14   ; l_DispatcherContext.FunctionEntry = l_pFunctionEntry

..  .    . . fffff800`008920ca mov     qword ptr [rsp+0B0h],rax  ; l_DispatcherContext.HistoryTable = pHistoryTable

..  .    . . fffff800`008920d2 mov     qword ptr [rsp+88h],rbx   ; l_DispatcherContext.EstablisherFrame = l_pEstablisherFrame

..  .    . . fffff800`008920da mov     qword ptr [rsp+98h],rdi   ; l_DispatcherContext.ContextRecord = pOriginalContext

..  .    . . fffff800`008920e2 mov     qword ptr [rsp+0A8h],r13  ; l_DispatcherContext.HandlerData = l_pHandlerData

..  .    . . fffff800`008920ea mov     dword ptr [rsp+0B8h],r15d ; l_DispatcherContext.ScopeIndex = 0

..  .    . . fffff800`008920f2 and     esi,0FFFFFF9Fh            ; l_ExceptionFlags &= ~(EXCEPTION_TARGET_UNWIND|EXCEPTION_COLLIDED_UNWIND)

..  .    . . fffff800`008920f5 call    nt!RtlpExecuteHandlerForUnwind (fffff800`008bd9d0)

..  .    . .                   ; RtlpExecuteHandlerForUnwind(&l_ExceptionRecord,

..  .    . .                   ;                             l_pEstablisherFrame,

..  .    . .                   ;                             pOriginalContext,

..  .    . .                   ;                             &l_DispatcherContext);

..  .    . . fffff800`008920fa dec     eax

..  .<   . . fffff800`008920fc je      nt!RtlUnwindEx+0x368 (fffff800`008921d8) ; 如果返回 ExceptionContinueSearch 则跳转

..  ..   . . 

..  ..   . . nt!RtlUnwindEx+0x292:

..  ..   . . fffff800`00892102 cmp     eax,2 ; cmp eax, ExceptionCollidedUnwind (3 - 1)

..  ..<  . . fffff800`00892105 jne     nt!RtlUnwindEx+0x426 (fffff800`00892296)

..  ...  . . 

..  ...  . . nt!RtlUnwindEx+0x29b:

..  ...  . . ; ExceptionCollidedUnwind 的情况

..  ...  . . fffff800`0089210b mov     r8,qword ptr [rsp+70h]   ; r8 = l_DispatcherContext.ControlPc

..  ...  . . fffff800`00892110 mov     r10,qword ptr [rsp+78h]  ; r10 = l_DispatcherContext.ImageBase

..  ...  . . fffff800`00892115 mov     rdx,qword ptr [rsp+98h]  ; rdx = l_DispatcherContext.ContextRecord

..  ...  . . fffff800`0089211d mov     rcx,qword ptr [rsp+6A0h] ; rcx = pOriginalContext

..  ...  . . fffff800`00892125 mov     r14,qword ptr [rsp+80h]  ; r14 = l_DispatcherContext.FunctionEntry

..  ...  . . fffff800`0089212d mov     qword ptr [rsp+68h],r8

..  ...  . . fffff800`00892132 mov     qword ptr [rsp+60h],r10

..  ...  . . fffff800`00892137 call    nt!RtlpCopyContext (fffff800`00891080)

..  ...  . . ;                 RtlpCopyContext(pOriginalContext, l_DispatcherContext.ContextRecord);

..  ...  . . fffff800`0089213c mov     rdx,rcx        ; rdx = pOriginalContext

..  ...  . . fffff800`0089213f mov     rdi,rcx        ; rdi = pOriginalContext

..  ...  . . fffff800`00892142 lea     rcx,[rsp+160h] ; rcx = &l_Context

..  ...  . . fffff800`0089214a lea     r12,[rsp+160h] ; r12 = &l_Context

..  ...  . . fffff800`00892152 call    nt!RtlpCopyContext (fffff800`00891080)

..  ...  . . ;                 RtlpCopyContext(&l_Context, pOriginalContext);

..  ...  . . fffff800`00892157 mov     qword ptr [rsp+38h],0   ; _ARG_8 = NULL

..  ...  . . fffff800`00892160 lea     rax,[rsp+680h]          ; rax = &l_pEstablisherFrame

..  ...  . . fffff800`00892168 mov     qword ptr [rsp+30h],rax ; _ARG_7 = &l_pEstablisherFrame

..  ...  . . fffff800`0089216d lea     rax,[rsp+58h]           ; rax = &l_pHandlerData

..  ...  . . fffff800`00892172 mov     r9,r14                  ; r9 = l_DispatcherContext.FunctionEntry

..  ...  . . fffff800`00892175 mov     qword ptr [rsp+28h],rax ; _ARG_6 = &l_pHandlerData

..  ...  . . fffff800`0089217a lea     rax,[rsp+160h]          ; rax = &l_Context

..  ...  . . fffff800`00892182 mov     rdx,r10                 ; rdx = l_DispatcherContext.ImageBase

..  ...  . . fffff800`00892185 xor     ecx,ecx                 ; ecx = UNW_FLAG_NHANDLER (0)

..  ...  . . fffff800`00892187 mov     qword ptr [rsp+20h],rax ; _ARG_5 = &l_Context

..  ...  . . fffff800`0089218c call    nt!RtlVirtualUnwind (fffff800`00891380)

..  ...  . .                   ; RtlVirtualUnwind(UNW_FLAG_NHANDLER,

..  ...  . .                   ;                  l_DispatcherContext.ImageBase,

..  ...  . .                   ;                  l_DispatcherContext.ControlPc,

..  ...  . .                   ;                  l_DispatcherContext.FunctionEntry,

..  ...  . .                   ;                  &l_Context,

..  ...  . .                   ;                  &l_pHandlerData,

..  ...  . .                   ;                  &l_pEstablisherFrame,

..  ...  . .                   ;                  NULL);

..  ...  . . fffff800`00892191 mov     rbx,qword ptr [rsp+88h]   ; rbx = l_DispatcherContext.EstablisherFrame

..  ...  . . fffff800`00892199 mov     rcx,qword ptr [rsp+0A0h]  ; rcx = l_DispatcherContext.LanguageHandler

..  ...  . . fffff800`008921a1 mov     r13,qword ptr [rsp+0A8h]  ; r13 = l_DispatcherContext.HandlerData

..  ...  . . fffff800`008921a9 mov     rax,qword ptr [rsp+0B0h]  ; rax = l_DispatcherContext.HistoryTable

..  ...  . . fffff800`008921b1 mov     r15d,dword ptr [rsp+0B8h] ; r15d = l_DispatcherContext.ScopeIndex

..  ...  . . fffff800`008921b9 mov     qword ptr [rsp+680h],rbx  ; l_pEstablisherFrame = l_DispatcherContext.EstablisherFrame

..  ...  . . fffff800`008921c1 mov     qword ptr [rsp+48h],rcx   ; l_pExceptionRoutine = l_DispatcherContext.LanguageHandler

..  ...  . . fffff800`008921c6 mov     qword ptr [rsp+58h],r13   ; l_pHandlerData = l_DispatcherContext.HandlerData

..  ...  . . fffff800`008921cb mov     qword ptr [rsp+6A8h],rax  ; pHistoryTable = l_DispatcherContext.HistoryTable

..  ...  . . fffff800`008921d3 or      esi,40h                   ; l_ExceptionFlags |= EXCEPTION_COLLIDED_UNWIND (40)

..  ...< . . fffff800`008921d6 jmp     nt!RtlUnwindEx+0x382 (fffff800`008921f2)

..  .... . . 

..  .... . . nt!RtlUnwindEx+0x368:

..  .>.. . . fffff800`008921d8 cmp     rbx,rbp ; cmp l_DispatcherContext.EstablisherFrame, pEstablisherFrame

..  . ..<. . fffff800`008921db je      nt!RtlUnwindEx+0x37d (fffff800`008921ed)

..  . .... . 

..  . .... . nt!RtlUnwindEx+0x36d:

..  . .... . fffff800`008921dd mov     rcx,qword ptr [rsp+48h] ; rcx = l_pExceptionRoutine

..  . .... . fffff800`008921e2 mov     rax,rdi                 ; rax = pOriginalContext

..  . .... . fffff800`008921e5 mov     rdi,r12                 ; rdi = &l_Context

..  . .... . fffff800`008921e8 mov     r12,rax                 ; r12 = pOriginalContext

..  . .v.. . fffff800`008921eb jmp     nt!RtlUnwindEx+0x382 (fffff800`008921f2)

..  . .... . 

..  . .... . nt!RtlUnwindEx+0x37d:

..  . ..>. . fffff800`008921ed mov     rcx,qword ptr [rsp+48h] ; rcx = l_pExceptionRoutine

..  . .. . . 

..  . .. . . nt!RtlUnwindEx+0x382:

..  . .> . . fffff800`008921f2 test    sil,40h  ; test sil, EXCEPTION_COLLIDED_UNWIND (40)

..  . .  < . fffff800`008921f6 jne     nt!RtlUnwindEx+0x200 (fffff800`00892070)

..  . .    . 

..  . .    . nt!RtlUnwindEx+0x38c:

..  . .    . fffff800`008921fc mov     r13,qword ptr [rsp+68h]  ; r13 = pOriginalContext->Rip

..  . .    . fffff800`00892201 mov     r15,qword ptr [rsp+688h] ; r15 = pJumpTargetIp

..  . .<   . fffff800`00892209 jmp     nt!RtlUnwindEx+0x3c7 (fffff800`00892237)

..  . ..   . 

..  . ..   . nt!RtlUnwindEx+0x39b:

..  > ..   . fffff800`0089220b cmp     rbx,rbp  ; cmp l_DispatcherContext.EstablisherFrame, pEstablisherFrame

..    .<   . fffff800`0089220e je      nt!RtlUnwindEx+0x3c7 (fffff800`00892237)

..    ..   . 

..    ..   . nt!RtlUnwindEx+0x3a0:

..    ..   . fffff800`00892210 mov     rax,rdi ; rax = &l_Context

..    ..   . fffff800`00892213 mov     rdi,r12 ; rdi = pOriginalContext

..    ..   . fffff800`00892216 mov     r12,rax ; r12 = &l_Context

..    .<   . fffff800`00892219 jmp     nt!RtlUnwindEx+0x3c7 (fffff800`00892237)

..    ..   . 

..    ..   . nt!RtlUnwindEx+0x3ab:

>.    ..   . fffff800`0089221b mov     rcx,qword ptr [rdi+98h]  ; rcx = pOriginalContext->Rsp

 .    ..   . fffff800`00892222 mov     rax,qword ptr [rcx]      ; rax = pOriginalContext->Rsp[0]

 .    ..   . fffff800`00892225 mov     qword ptr [rdi+0F8h],rax ; pOriginalContext->Rip = pOriginalContext->Rsp[0]

 .    ..   . fffff800`0089222c lea     rax,[rcx+8]              ; rax = pOriginalContext->Rsp + 8

 .    ..   . fffff800`00892230 mov     qword ptr [rdi+98h],rax  ; pOriginalContext->Rsp = pOriginalContext->Rsp + 8 （跳过返回值）

 .    ..   .

 .    ..   . nt!RtlUnwindEx+0x3c7:

 .    .>   . fffff800`00892237 test    bl,7 ; 检查 l_DispatcherContext.EstablisherFrame 是否对齐

 .    .<   . fffff800`0089223a jne     nt!RtlUnwindEx+0x444 (fffff800`008922b4)

 .    ..   . 

 .    ..   . nt!RtlUnwindEx+0x3cc:

 .    ..   . fffff800`0089223c cmp     rbx,qword ptr [rsp+50h] ; cmp l_DispatcherContext.EstablisherFrame, l_LowLimit

 .    ..<  . fffff800`00892241 jb      nt!RtlUnwindEx+0x3da (fffff800`0089224a)

 .    ...  . 

 .    ...  . nt!RtlUnwindEx+0x3d3:

 .    ...  . fffff800`00892243 cmp     rbx,qword ptr [rsp+40h] ; cmp l_DispatcherContext.EstablisherFrame, l_HighLimit

 .    ...< . fffff800`00892248 jb      nt!RtlUnwindEx+0x414 (fffff800`00892284)

 .    .... . 

 .    .... . nt!RtlUnwindEx+0x3da:

 .    ..>. . fffff800`0089224a mov     al,byte ptr gs:[20DEh] ; al = _KPCR->DpcRoutineActive

 .    .. . . fffff800`00892252 test    al,al

 .    .. .<. fffff800`00892254 jne     nt!RtlUnwindEx+0x43c (fffff800`008922ac)

 .    .. ... 

 .    .. ... nt!RtlUnwindEx+0x3e6:

 .    .. ... fffff800`00892256 mov     rcx,qword ptr [rsp+40h] ; rcx = l_HighLimit

 .    .. ... fffff800`0089225b mov     rax,qword ptr [rcx-28h] ; rax = l_KernelStackCtrl->Previous.StackBase

 .    .. ... fffff800`0089225f test    rax,rax

 .    .. .<. fffff800`00892262 je      nt!RtlUnwindEx+0x43c (fffff800`008922ac)

 .    .. ... 

 .    .. ... nt!RtlUnwindEx+0x3f4:

 .    .. ... fffff800`00892264 mov     rdx,qword ptr [rcx-20h]  ; rdx = l_KernelStackCtrl->Previous.StackLimit

 .    .. ... fffff800`00892268 mov     rbx,qword ptr [rsp+680h] ; rbx = l_pEstablisherFrame

 .    .. ... fffff800`00892270 cmp     rbx,rdx                  ; cmp l_pEstablisherFrame, l_KernelStackCtrl->Previous.StackLimit

 .    .< ... fffff800`00892273 jb      nt!RtlUnwindEx+0x444 (fffff800`008922b4)

 .    .. ... 

 .    .. ... nt!RtlUnwindEx+0x405:

 .    .. ... fffff800`00892275 cmp     rbx,rax ; cmp l_pEstablisherFrame, l_KernelStackCtrl->Previous.StackBase

 .    .< ... fffff800`00892278 jae     nt!RtlUnwindEx+0x444 (fffff800`008922b4)

 .    .. ... 

 .    .. ... nt!RtlUnwindEx+0x40a:

 .    .. ... fffff800`0089227a mov     qword ptr [rsp+50h],rdx ; l_LowLimit = l_KernelStackCtrl->Previous.StackLimit

 .    .. ... fffff800`0089227f mov     qword ptr [rsp+40h],rax ; l_HighLimit = l_KernelStackCtrl->Previous.StackBase

 .    .. ... 

 .    .. ... nt!RtlUnwindEx+0x414:

 .    .. >.. fffff800`00892284 cmp     rbx,rbp ; cmp l_pEstablisherFrame, pEstablisherFrame

 .    .. <.. fffff800`00892287 je      nt!RtlUnwindEx+0x449 (fffff800`008922b9)

 .    .. ... 

 .    .. ... nt!RtlUnwindEx+0x419:

 .    .. ... fffff800`00892289 mov     rax,qword ptr [rsp+6A8h] ; rax = pHistoryTable

 .    .. ..^ fffff800`00892291 jmp     nt!RtlUnwindEx+0xf0 (fffff800`00891f60)

 .    .. ..  

 .    .. ..  nt!RtlUnwindEx+0x426:

 .    >. ..  fffff800`00892296 mov     ecx,0C0000026h ; ecx = STATUS_INVALID_DISPOSITION

 .     . ..  fffff800`0089229b call    nt!RtlRaiseStatus (fffff800`00889df0)

 .     . ..  fffff800`008922a0 int     3

 .     . ..  

 .     . ..  nt!RtlUnwindEx+0x431:

 >     . ..  fffff800`008922a1 mov     ecx,0C0000028h ; ecx = STATUS_BAD_STACK

       . ..  fffff800`008922a6 call    nt!RtlRaiseStatus (fffff800`00889df0)

       . ..  fffff800`008922ab int     3

       . ..  

       . ..  nt!RtlUnwindEx+0x43c:

       . .>  fffff800`008922ac mov     rbx,qword ptr [rsp+680h] ; rbx = l_pEstablisherFrame

       . .   

       . .   nt!RtlUnwindEx+0x444:

       > .   fffff800`008922b4 cmp     rbx,rbp ; cmp l_pEstablisherFrame, pEstablisherFrame

<        .   fffff800`008922b7 jne     nt!RtlUnwindEx+0x479 (fffff800`008922e9)

.        .   

.        .   nt!RtlUnwindEx+0x449:

.        >   fffff800`008922b9 mov     rax,qword ptr [rsp+698h]  ; rax = ReturnValue

.            fffff800`008922c1 mov     rbx,qword ptr [rsp+690h]  ; rbx = pExceptionRecord

.            fffff800`008922c9 mov     qword ptr [rdi+78h],rax   ; pOriginalContext->Rax, ReturnValue

.            fffff800`008922cd cmp     dword ptr [rbx],80000029h ; cmp pExceptionRecord->ExceptionCode, STATUS_UNWIND_CONSOLIDATE

.<           fffff800`008922d3 je      nt!RtlUnwindEx+0x46c (fffff800`008922dc)

..           

..           nt!RtlUnwindEx+0x465:

..           fffff800`008922d5 mov     qword ptr [rdi+0F8h],r15 ; pOriginalContext->Rip, pJumpTargetIp

..           

..           nt!RtlUnwindEx+0x46c:

.>           fffff800`008922dc mov     rdx,rbx ; rdx = pExceptionRecord

.            fffff800`008922df mov     rcx,rdi ; rcx = pOriginalContext

.            fffff800`008922e2 call    nt!RtlRestoreContext (fffff800`008bd290)

.<           fffff800`008922e7 jmp     nt!RtlUnwindEx+0x4a0 (fffff800`00892310)

..           

..           nt!RtlUnwindEx+0x479:

>.           fffff800`008922e9 cmp     r13,qword ptr [rdi+0F8h] ; pOriginalContext->Rip

 .<          fffff800`008922f0 jne     nt!RtlUnwindEx+0x48d (fffff800`008922fd)

 ..          

 ..          nt!RtlUnwindEx+0x482:

 ..          fffff800`008922f2 mov     ecx,0C00000FFh ; ecx = STATUS_BAD_FUNCTION_TABLE

 ..          fffff800`008922f7 call    nt!RtlRaiseStatus (fffff800`00889df0)

 ..          fffff800`008922fc int     3

 ..          

 ..          nt!RtlUnwindEx+0x48d:

 .>          fffff800`008922fd mov     rcx,qword ptr [rsp+690h] ; rcx = pExceptionRecord

 .           fffff800`00892305 xor     r8d,r8d                  ; r8d = 0

 .           fffff800`00892308 mov     rdx,rdi                  ; rdx = pOriginalContext

 .           fffff800`0089230b call    nt!ZwRaiseException (fffff800`008b9b80)

 .                             ; ZwRaiseException(pExceptionRecord, pOriginalContext, FALSE);

 .           

 .           nt!RtlUnwindEx+0x4a0:

 >           fffff800`00892310 mov     r15,qword ptr [rsp+638h]

             fffff800`00892318 mov     r14,qword ptr [rsp+640h]

             fffff800`00892320 mov     r13,qword ptr [rsp+648h]

             fffff800`00892328 mov     r12,qword ptr [rsp+650h]

             fffff800`00892330 mov     rdi,qword ptr [rsp+658h]

             fffff800`00892338 mov     rsi,qword ptr [rsp+660h]

             fffff800`00892340 mov     rbp,qword ptr [rsp+668h]

             fffff800`00892348 mov     rbx,qword ptr [rsp+670h]

             fffff800`00892350 add     rsp,678h

             fffff800`00892357 ret

参考资料

[1] wrk 源码
[2] Improving Automated Analysis of Windows x64 Binaries, skape
[3] Programming against the x64 exception handling support, Skywing
[4] Exceptional Behavior - x64 Structured Exception Handling, The NT Insider

SEH分析笔记（x64篇）_v1.0.0.zip (Size: 398.19 KB / Downloads: 165)

我的手机史

Sat, 29 Oct 2011 22:20:04 +0800

boxcounter,
2009, August 16

时间：上上周，某个月黑风高夜，

人物：我

地点：某烧烤摊

事件：LG8330翻盖轴断裂

意义：正式宣告我的第三部手机扑街了，我的手机史就此掀开了新的篇章

这里展示下我单薄的手机史，直接上图：

  手机1.jpg (Size: 6.77 KB / Downloads: 21)

第一部，2004年，为了跟美女联系方便买的，最后美女走了，手机扔了。

牌子是迪比特，感觉相当烂，用了一两个月就开始很卡了，按键延迟相当厉害。生产厂商貌似倒了。

  手机2.jpg (Size: 64.18 KB / Downloads: 23)
第二部，2006年，大四那年来深圳进了公司，学校里有不少事需要联系，于是收了部Nokia1100，价格很实在，东西很超值，用了很久，反应依然如初。铃声音量相当劲爆，可以用来对抗公交车上的山寨（播放？）机，目前仍在服役。

  手机3.jpg (Size: 51.09 KB / Downloads: 23)
第三部，2007年，Mr.Cool换了智能机，退役下来一部LG8330，落入我爪。

做工扎实，经摔耐砸，功能丰富，支持3G，好用，让我对LG这个牌子的好感直线飙升。最后死于排线断裂，阿弥陀佛，永垂不朽

单角度，多造型图：

  手机4.jpg (Size: 52.88 KB / Downloads: 21)

再来个两兄弟合影：

  手机5.jpg (Size: 48.04 KB / Downloads: 21)

  手机6.jpg (Size: 14.86 KB / Downloads: 19)
第四部，HTC Cruise 09，这个月收入囊中，目前正在使用，配置强劲，使用感觉良好，缺憾是还未完美解码。原简体ROM是XDA的脏ROM。

感谢Mr.cool同志的强力推荐。顺便抖抖他的糗事，这哥们今年上半年已经折腾了四部手机了，目前在用的第5部，是我的老搭档1100，这厮对手机已经心灰意冷了，这部HTC上上个月他刚掉了一部~

为了这部手机，我兴冲冲的杀到淫乱之都，结果发现价格比深圳的还贵。顺便打听了下E71，发现价格也很离谱，水货2270RMB，后来在深圳我看到行货貌似才2280，我窘啊

日记090315

Thu, 27 Oct 2011 08:20:17 +0800

boxcounter,
2009, March 16

周六和wallace、BigC一起打篮球，之后被wallace带去喝粥，据说3元喝到饱，于是三人兴冲冲的杀过去，进门二话不说，每人一碗粥先，又上了些凉菜，酸、辣、甜，夹杂在一起的感觉实在是爽。但重点还是粥，有甜粥荤粥，由于是3元任喝，于是我狂喝到肚子撑得不行才停，统计了下，一共灌了四碗，其中：小米粥2碗、八宝粥2碗。BigC一边喝着甜粥，一边还念叨着：这样吃要长胖的，怎么办啊，结果到最后丫也喝了四碗~ 菜足粥饱去付账，结果发现俺们把身上所有的钱合在一起买了单之后，仅余一元，好险好险~~~

早上醒来，拿起那家粥店的外卖单搜寻午餐，突然上面赫然写着一道面食：红油抄手！于是中午又和这两位童鞋杀到这家粥店，我主吃抄手，没碰粥。BigC同志则很没出息的又喝了4碗~ 我觉得有一丝的歉意：这家老板也挺不容易的，遇到俺们这样的客户估计也只能背过身去偷偷抹泪。

菜足粥饱后，去找老肖同志，路上的公交车上，看见一对父子，儿子很小，大概小学2、3年级的样子，手上拿着一本旧旧的机器猫在读，过了几分钟，貌似读完了。合上书，盯着书的封面满足的笑了。然后把书递给父亲，自己扭头看车窗外的风景。父亲接过书，看了看封面、又看了看封底，再翻了几页，合上了，貌似并不理解儿子为什么会喜欢。

我突然想起自己小时候，经常去租武侠看，押金10元、租金5角每天。大学之前我是没有零花钱的，只能眼巴巴的盼过年，把几张压岁的毛老爷子偷偷的藏起来，用来租书。父亲很反对我看武侠，见一本就撕一本，平均下来，一年能撕5、6本。书没了，押金自然也打了漂。加上租金，算下来，前一年的压岁钱差不多勉强能撑到第二年过年。为了省租金，我会尽快读完，疯狂的时候一天一本，现在回想起来，貌似还没有哪书能耗我多过一元的租金。这样时间长了，就养成了一目十行、过目就忘的本领。这也是我如今比较偏爱E文资料的原因之一：技术资料都需要仔细琢磨，反复思考，如果是中文资料，我会习惯性的跳着看，经常看了半天不知道里面讲的是什么。于是就逼着自己看E文原著：E文没那么牛X，只能一个单词一个单词的抠，一个分句一个分句的理解。这个习惯我是从大学开始养成的，在学校里看原著的时候被人发现了，要么被认为很牛B，要么被认为很装B。这里啰嗦这么久，只是想顺便解释下。不过说回来，看了一些E文原著后，感觉国人的译著和原著相差还是蛮大的。

哦，忘了说，晚上回到桃源村，我又去光顾了那家粥店，本只想喝喝粥的，但是觉得光点粥不太好意思，于是点了份韭菜盒子，最后肚揣三碗八宝粥，惬意而归。心里琢磨着，以后找媳妇，得好好调教下，至少得能煲一手好甜粥吧。

最后给我的朋友们提个醒：运动之前先热热身，拉伸下肌肉。前阵子打球，没热身就上场拼，晚上休息才发现腰扭伤了，现在还隐隐作痛的。

小面包真好

Thu, 27 Oct 2011 08:18:54 +0800

boxcounter,
2008, November 30

昨晚遇到一系列的怪事，记下来，等老了慢慢回味:

我坐电梯，电梯在十四楼突然卡住了，我只好从电梯的顶窗爬出来。就在这个时候电梯突然又动起来了，我很恐惧的拍打周围的铁墙壁，声音很闷，没人理我。我只好紧紧的抓住面前一个类似把手的东西，听天由命。然后突然发现我跟着电梯平安的到达了地面，而且我直接就站到了地面。还没等我把心放回心窝里，突然又发现地震了，然后赶紧往庇护所跑，遇到了黄师父等。然后我们就惶恐的呆在庇护所里，透过窗户我看见外面的两座摩天大楼从中间断成两截，上面的一截就接连在我面前轰然倒下。这个时候我才反应过来，干净吼着跟大伙一起跑到外面的空地上，惊恐的看着庇护所，庆幸的是庇护所安然无事。

然后我又突然想起我的行李，我的钱包、手机还留在庇护所里，这个时候大伙也都反应过来，都嚷嚷的着要冲进去拿回自己的东西。我安抚了半天，最终达成协议，由我和黄师父回去把大家值钱的东西都拿回来，其他人安全起见就留在空地上。等把东西都拿出来，我才想起要给某MM打电话问问她是否安好，于是紧张兮兮的打电话过去，得知她一切安好，心里顿感踏实了不少。挂了电话，我就四处乱瞅，突然发现头顶上很高很高的地方的建筑天顶要倒了（不知道咋描述这个建筑，可以这么想，我们在一个“王”字形的庞然建筑里，我们呆的具体位置就是中间那一横，天顶指的是上面一横，地面就是最底下一横），于是大家又紧张兮兮的想办法赶紧下到地面。

就在这节骨眼，我醒了。MD，原来是个梦。

感觉饥肠辘辘，以我质朴的心灵揣测，我应该是被饿醒的。很是后悔，就因为自己肚子饿，就抛弃了黄师父等，留他们孤零零的享受地震。再一想，MD，活着的感觉真好。于是晃悠到客厅连吃了5个小面包，喝了大半瓶的水，感觉好多了。然后一边感谢赐予我美好生活的爸妈、各路神仙、兄弟、姐妹还有自己，一边踱步到窗边，看着14层楼下的芸芸几辆taxi来来往往，感觉特别踏实，然后又倒头昏睡过去。

再醒来时，天已经大亮，仍觉得不可思议，这应该是我自小做过的感受最真实的梦了。我经常在梦里可以感觉到自己是在做梦，于是很享受的赖在梦里不醒，但这次在这次梦中，我始终感觉到紧张和惊恐，一丝都没有察觉是个梦。

OK，这次也算是很真实的感受了下地震，收获不少，最大的收获是：还活着的感觉真好；饿醒了有小面包吃，真好。

以前经常开玩笑：
我：经历过地震没？
某：没~
我：那你的生活的乐趣少了 1/4。经历过火山没？
某：没~
我：那你的生命的乐趣少 2/4。经历过龙卷风没？
某：没~
我：那你的生命的乐趣少了 3/4。经历过海啸没？
某：没~
我：那你跟咸鱼没什么分别了。
现在我总算是保住了我生活乐趣的 1/4~

总结：
（1）电梯重新动起来时，我是踩着电梯厢的，怎么后来就直接安全的踏上地面了？这个我要好好研究下
（2）本梦的出场人员中，我貌似没有看到Quack、BT姐、mrcool、村长，估计是地震前就没义气的跑了，B4他们~
（3）地震中，我居然只想到给MM打电话，没想到给家里人打，实在是不孝，深刻检讨。

日记080917

Thu, 27 Oct 2011 08:18:02 +0800

boxcounter,
2008, September 17

1. 梨花版的quack
通常我们在聚餐时，都会趁着上菜前的一段时间大肆YY一番，天南地北、歪瓜裂枣，无所不吹。这天也不例外，大家YY到了情书，有人提到quack同学善情诗，quack同学谦虚了一番，然后颇为得意的说：
“我不用写，我往那一站，就是一首情诗。”
mrcool小小声的接了句：“是啊，梨花体~”
一席人爆笑不止。

作为男主角，quack同学事后以完全不记得为由怀疑此事的真实性。但本报道还是得到了其家属的鼎力支持，在这里严重感谢BT姐。

2. 音乐：
个人感觉不错的：
《乱红》
《绿野仙踪》
《いきものがかり-ブルーバード》
《画心》

牢骚、键盘和音乐

Thu, 27 Oct 2011 08:17:11 +0800

boxcounter,
2008, August 15

貌似又好些天没写东西了，貌似最近一直没心思写东西，比如这篇就是觉得实在得写点什么才写的。最近对什么都缺乏兴趣，总觉得没精神，脑子貌似都不好使了，有时候说话都不利索，时不时会为一个简单的词想半天，还有时候会前言不搭后语，不知道是不是无意中伤了脑神经~~BigC也说我白头发又多了不少，NND，真乱。
不废话了，进入主题：

1.我的键盘

在公司里，我用的是款多彩的K8080，这款本来是键鼠套装，但是我已经有了一只很喜欢的罗技鼠了，所以就只用键盘。感觉这款键盘很不错，虽然是仿制品。优点很多：
1.键程短，弹力不错，敲起来很有感觉。
2.键帽做了平滑的处理，更舒服，敲字的时候更精准。
3.敲击的声音较小，对于跟我这种喜欢死命敲键盘的同处一办公室的人来说算是个福音~
4.去掉了Power、Sleep、Wakeup这三个我从来都不会正经用到，但是却经常一不小心就按到~~ 每次都好烦好烦~~~

这里发发牢骚，我不懂那些设计键盘的人是怎么想的，这几个键本来多数普通用户就不常用，干嘛非要做到键盘上？还有的键盘更让人无语，Power键就在'F12'键的旁边，一不小心就按到，让我数次抓狂。所以我每拿到一款键盘，首先就把Power键给取下来~ 而K8080就完全去掉了这三个键，太明智了。扯远一点，我挺喜欢WIN这个辅助键，之前用过一段时间的IBM T42，没法用类似WIN+D这种很实用的快捷键让我很是郁闷。所以后来联想把这个键加到Thinkpad机型的时候，我还是蛮高兴的，不过最近听了mrcool，glacier不少关于X61、T60的抱怨，为联想的模具设计和制作工艺汗颜~

前些天，在家里攒了台台式机，买键盘的时候就专门去买K8080的原型 - DELL 8115。DELL还有一款8135，是8115的升级版，多了很多功能键，多了个托盘，造型也时尚了不少，可惜我用键鼠都喜欢精简的，套用一句广告：“简约而不简单”。感觉这款也不错，仔细的瞧了瞧，制作工艺没话说，相比之下，K8080就逊色了些，我甚至能看出K8080上某些键帽的大小有些不一样~~ 但是最可惜的它的键帽还是经典设计，没有像K8080做平滑处理，让我失望了一把。所以K8080虽然是模仿出来的，但看得出多彩还是费了番心思的。

2.音乐
近几个月都在用qqmusic听音乐，的确好用。以前用千千静听，听歌都是上baidu top 100一首一首的载回来，听完后再一首一首的把不喜欢的删除，挺累的。而QQMusic就挺好，在线听，觉得喜欢再去百度上下（QQMusic上可以下载，可惜要绿钻），不过有点不习惯的是，QQMusic的排行榜里没有BaiDu Top 100，而内置的排行榜更新又慢，经常一个多星期过去了，还是那些歌。
最近淘到的喜欢的歌有：
《即使知道要见面》 - Sara(泰国)
这首歌是泰语的，听求不懂，但是第一次听到的时候就觉得旋律不错，后来专门搜了歌词，歌词也不错

《你不像她》 - 南拳妈妈
以前一直不喜欢南拳妈妈，我比较排斥靠大腕突然间就火箭般蹿出来的歌手，不过最近发现他们的这首歌老是在排行榜的前几名，好奇心使然，试听了下，觉得蛮不错，所以回头就把他们所有的专辑都翻出来听了听。

[attach=22]

DELL 8115

[attach=23]

K8080

[attach=24]

相对于普通键盘的键帽，K8080的键帽做了平滑处理

[attach=25]

公司里用的罗技鼠，很不错，就是小了点。下次换鼠标就买适合大手掌的MX518好了。

[attach=26]

办公的小窝

[boxcounter,2011-10-27：迁移blog时所有照片都丢失了]

被朋友点名鸟~

Thu, 27 Oct 2011 08:15:21 +0800

boxcounter,
2008, June 17

朋友在QZONE点名，于是作答。本来这个游戏是要继续传递下去的，但是我有两个原则：
1. 群发的消息，一律不回
2. 要求我必须发给多少人，否则怎么怎么样的。这种短信、消息，一律终结。
所以这个游戏，我就不点名了。

很多问题都是“首要”、“最”，很难排序，于是我就把前几位都做为答案

1、上次哭在什么时候？
几年前第一次听《矜持》的时候。第二天，在一个女孩子的陪同下，为另外一个女孩痛哭。

2、说出点你名的朋友的三个优点？
乖巧，人好，眼睛很漂亮，笑起来更漂亮。

3、如果给你一次机会，你想从自己多大那一年从头过起？
可惜没有这么个机会

4、相信爱情吗？
还相信

5、现阶段最大的愿望是什么？
买房买车包二奶

6、觉得最享受的是什么？
她沉沉的睡在我怀里；
听着音乐，看着书；
和一群大学的狐朋狗友一起打游戏；
打完篮球后，洗完澡、穿得清爽的去西师后面的小火锅店吃小火锅
还有很多，就不列举了。

7、你最想去的地方？为什么？
家，想家。

8、你的首要择偶条件是什么？
女的、活的、善良、不傻、专一、不丑（如果可以选择的话，希望耐看一点）

9、你觉得最合适你结婚的年龄是什么时候？
遇到合适的人的时候

10、幸福的事的定义是什么？
让我幸福的事

11、你是一个固执的人吗？
要看你有没有合理的理由说服我

12、可以选择的话，你选择结婚，还是不结婚？
结婚

13、出去后，你想干什么？（我的问题，这难道就是所谓的梦想）？
这个问题很无敌，我开始以为是给监狱里的朋友做的题~

14、你在意你的男友或女友有异性朋友吗？
看人，对方如果是我觉得可靠的，就不太在意。但是如果不是什么好人，那就给我断干净，免得我急。

15、你打算生几个孩子？男的还是女的？
这个得靠孩子他（她、他们、她们）妈

16、当朋友误解你的时候，你会怎么办？
我讨厌误解，会尽量把自己的想法、为什么有这样的想法告诉他，如果他实在理解不了，那我也很无奈。

17、幻想你到30岁的时候，你会是个怎样的人?
我也很想知道。

18、你最想留住哪个城市生活？
深圳、珠海

19、你觉得你对你现在的生活状态满意吗？为什么会有这样的想法？
还不错。父母过得还不错，自己做着自己想做的事，身边有几个好朋友，能互相帮助，能互相理解。

20、你做过的最浪漫的事情？（嘿嘿，，可以说得仔细点哦）
这个得问她

Ok，完成了朋友的任务，收工。