Win32结构化异常处理（SEH）探秘(下)
2010-10-15 09:07:35 来源：Web开发网 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁惧墽鎳撻—鍐偓锝庝簻椤掋垺銇勯幇顖毿撻柟渚垮妼椤粓宕卞Δ鈧獮濠勭磽閸屾艾鈧懓顫濋妸鈺佺疅缂佸顑欓崥瀣煕椤愵偅绶氱紓鍐╂礋濮婂宕掑▎鎴М濠电姭鍋撻梺顒€绉甸幆鐐哄箹濞ｎ剙濡肩紒鎰殜閺屸€愁吋鎼粹€茬敖婵炴垶鎸哥粔鐢稿Φ閸曨垰鍐€妞ゆ劦婢€濞岊亪姊虹紒妯诲蔼闁稿海鏁诲濠氭晲婢跺﹤宓嗛梺缁樺姈缁佹挳宕戦幘璇叉嵍妞ゆ挻绋戞禍鐐叏濡厧浜鹃悗姘炬嫹
闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁惧墽鎳撻—鍐偓锝庝簼閹癸綁鏌ｉ鐐搭棞闁靛棙甯掗～婵嬫晲閸涱剙顥氬┑掳鍊楁慨鐑藉磻濞戔懞鍥偨缁嬫寧鐎梺鐟板⒔缁垶宕戦幇鐗堢厵缂備焦锚缁椦囨煃瑜滈崜锕傚矗閸愵煈娼栭柛婵嗗珔瑜斿畷鎯邦槾濞寸姴銈稿铏规嫚閼碱剛顔夐梺鐓庣秺缁犳牠骞冩ィ鍐╁€婚柦妯侯槼閹芥洟姊洪棃娑辨濠碘€虫喘瀹曘垽鎮介崨濞炬嫼闁荤喐鐟ョ€氱兘宕箛娑欑厱闁绘ê纾晶鐢告煏閸℃鈧湱缂撴禒瀣窛濠电姴瀚獮鍫ユ⒑绾懎顥嶉柟娲讳簽濡叉劙寮撮悢鍝勨叞闂傚倸鍊风欢姘缚瑜嶇叅闁靛牆娲犻崑鎾愁潩椤愩垹绁梺缁樹緱閸ｏ綁鐛幒鎳虫棃鍩€椤掑倻涓嶉柨婵嗘缁♀偓闂傚倸鐗婄粙鎴﹀汲濞嗗緷鐟扳堪閸垻鏆梺鍝勭焿缂嶄焦鎱ㄩ埀顒勬煃閹増纭炬繝鈧潏銊х彾闁哄洨鍠撶弧鈧┑顔斤供閸橀箖宕㈤悽鍛娾拺缂備焦锚婵箓鏌涢幘鏉戝摵闁诡喗蓱濞煎繘濡搁妶鍥╃暰闂備礁婀辩划顖滄暜閻愬瓨娅犳繛鎴炴皑绾捐偐绱撴担璐細婵炴彃顕埀顒冾潐濞叉牕鐣烽鍐簷闂備礁鎲￠崝鏇㈠疮閻樿绀堟繝闈涚墛瀹曞弶绻涢幋鐐ㄧ細闁哄棗妫楅埞鎴︽偐鏉堫偄鍘￠梺杞扮劍閻楁粎妲愰幘瀛樺濞寸姴顑呴幗鐢告⒑閸︻厽鍤€婵炲眰鍊濋幃楣冩倻閽樺顔婇梺瑙勬儗閸樹粙宕撻悽鍛娾拺闁荤喐婢橀幃渚€鏌ｉ幒鐐电暤闁诡喗顨婇獮鏍ㄦ媴閸忓瀚藉┑鐐舵彧缁插潡宕曢妶澶婂惞闁逞屽墴濮婃椽骞栭悙娴嬪亾閺嶎厽鍋嬮柣妯垮吹瀹撲線鐓崶銊р姇闁哄懏鎮傞弻銊╂偆閸屾稑顏�
婵犵數濮烽弫鍛婃叏閻戣棄鏋侀柛娑橈攻閸欏繘鏌ｉ幋锝嗩棄闁哄绶氶弻娑樷槈濮楀牊鏁鹃梺鍛婄懃缁绘垿濡甸崟顖氱闁告鍋熸禒鑲╃磽娴ｅ搫顎岄柛銊ョ埣瀵鈽夐姀鐘电杸闂傚倸鐗婄粙鎺楁倶閸儲鍊甸柣鐔哄閸熺偟绱掔拠鎻掓殻濠碉紕鏁诲畷鐔碱敍濮橀硸鍟嬮梺璇查叄濞佳囧箺濠婂牊鍋╁┑鍌氭啞閳锋垹鐥鐐村婵炲吋鍔栫换娑㈡嚑椤掆偓閺嬪孩銇勯銏㈢缂佽鲸甯掕灒闁兼祴鏅滈崵宀勬⒒娓氣偓閳ь剛鍋涢懟顖涙櫠椤旇偐鏆嗛柨婵嗙墕閸斿灚銇勯敂鐣屽弨闁诡噯绻濇俊鑸靛緞鐎ｎ剙甯鹃梻浣稿閸嬪懐鎹㈤崘顔肩；妞ゅ繐鎳愮粻鍓р偓鐟板閸犳洜鑺辨繝姘畾闁绘柨鍚嬮埛鎴︽倵閸︻厼校闁靛棗鍟撮弻銈夊礃閼碱剙鐓熼悗瑙勬礃缁诲牓寮崘顔肩劦妞ゆ帒瀚ч埀顒佹瀹曟﹢顢欓崲澹洦鐓曢柍鈺佸枤濞堟﹢鏌ｉ悢绋垮婵﹥妞介幃鈩冩償閳╁啯鐦ｉ梻浣虹帛閻楁洟濡剁粙璺ㄦ殾闁绘垶岣跨弧鈧梺鎼炲劀閸愩劎銈梻鍌欑窔濞佳勵殽韫囨洘顫曢柡鍥ュ灩閸屻劍銇勮箛鎾跺闁抽攱鍨块弻鐔兼嚃閳轰椒绮堕梺鍛婃⒐椤ㄥ﹪寮婚敓鐘插窛妞ゆ棃鏁慨鍥╃磽娴ｇǹ鈧湱鏁悢濡撳洨鈧潧鎽滅壕濂稿级閸稑濡肩紒妤佺缁绘盯鎮℃惔锝囶啋闂佺硶鏂侀崜婵嬪箯閸涘瓨鐓ラ悗锝呯仛缂嶆姊婚崒姘偓宄懊归崶褜娴栭柕濞炬櫆閸婂潡鏌ㄩ弴鐐测偓鍝ョ不閺屻儲鐓曢柕澶樺枛婢ь噣鏌＄€ｂ晝绐旈柡宀€鍠栧畷婊嗩槾閻㈩垱鐩弻锟犲川椤旇棄鈧劙鏌＄仦璇插闁诡喓鍊濆畷鎺戔槈濮楀棔绱�闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁惧墽鎳撻—鍐偓锝庝簻椤掋垺銇勯幇顖毿撻柟渚垮妼椤粓宕卞Δ鈧獮濠勭磽閸屾艾鈧懓顫濋妸鈺佺疅缂佸顑欓崥瀣煕椤愵偅绶氱紓鍐╂礋濮婂宕掑▎鎴М濠电姭鍋撻梺顒€绉甸幆鐐哄箹濞ｎ剙濡肩紒鎰殜閺屸€愁吋鎼粹€茬敖婵炴垶鎸哥粔鐢稿Φ閸曨垰鍐€妞ゆ劦婢€濞岊亪姊虹紒妯诲蔼闁稿海鏁诲濠氭晲婢跺﹤宓嗛梺缁樺姈缁佹挳宕戦幘璇叉嵍妞ゆ挻绋戞禍鐐叏濡厧浜鹃悗姘炬嫹 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻锝夊箣閿濆憛鎾绘煕閵堝懎顏柡灞诲€濆畷顐﹀Ψ閿旇姤鐦庡┑鐐差嚟婵潧顫濋妸褎顫曢柟鎹愵嚙绾惧吋绻涢崱妯虹瑨闁告﹫绱曠槐鎾寸瑹閸パ勭彯闂佹悶鍔岄悥鍏间繆閹绢喖绀冩い鏃傚帶缁愭盯姊洪崫鍕垫Ч闁搞劌缍婂畷銏犆洪鍛偓鍨殽閻愯尙浠㈤柛鏃€纰嶉妵鍕晜鐠囪尙浠搁悗瑙勬穿缁绘繈鐛惔銊﹀殟闁靛／鍐ㄥ闂傚倸饪撮崑鍕洪敃鈧叅闁哄秲鍔庢晶锟犳⒒閸屾瑦绁版い鏇嗗應鍋撻崹顐㈡诞鐎规洘绮撻幃銏＄附婢跺绋侀梻浣瑰劤缁绘劕锕㈡潏鈺侇棜闁稿繘妫跨换鍡樸亜閺嶃劎顣查柟顖氱墛閵囧嫰顢曢姀銏㈠姱濠殿喖锕ュ钘夌暦閻戠瓔鏁囨繛鎴炵懃閻濋亶姊绘担鍛靛綊顢栭崨顓囨稑鈹戠€ｎ亞鐣鹃梺閫炲苯澧柕鍥у缁犳盯骞樼€垫悶鍋愭繝纰樻閸ㄦ壆鈧碍婢橀～蹇撁洪鍕炊闂佸憡娲﹂崜姘跺箯閸楃偐鏀介柣鎰絻缁狙冪暆閿濆懏鍋ユ鐐村灴婵偓闁绘﹩鍋呴弬鈧┑鐘垫暩婵鈧凹鍣ｅ鍫曞箹娴ｅ厜鎷洪梺鍛婄箓鐎氼厼顔忓┑鍡忔斀妞ゆ梹鍎抽崢鎾煙椤旇宓嗗┑锛勫厴閸╋繝宕掑Δ浣割伜婵犵數鍋犻幓顏嗗緤娴犲绠规い鎰╁€栭弳婊堟偣鏉炴媽顒熼柣鏂挎閺岋綁鎮㈠畡鎵泿闂佽 鍋撻柤濮愬€楃壕濂告煕鐏炵偓鐨戠€涙繂螖濡ゅ﹣绨烽柛妤€鍟块悾鐑芥偂鎼搭喗鍍甸梺鎸庣箓閹冲秵绔熼弴銏♀拺闁告繂瀚弳娆撴煟濡も偓濡稓鍒掗崼銉ョ闁崇懓銇樼花濠氭椤愩垺鎼愭繛瀵稿厴钘濋柨鏇楀亾闂囧绻濇繝鍌滃ⅱ闁伙絾妞介弻锛勪沪鐠囨彃顬堥梺瀹狀潐閸ㄥ灝鐣烽崡鐐╂闁瑰吀绀佹禍鐐繆閵堝倸浜惧銈庡弨閸庡篓娓氣偓閺屾盯鎮╁畷鍥р拰濠电姭鍋撳〒姘ｅ亾婵﹨娅ｇ槐鎺懳熼弴鐔风伌闁诡喚鍏樻俊鐤槷闁稿鎸搁～婵嬫偂鎼淬垻浜剧紓鍌欑贰閸犳氨鍒掗鐐参ч柨婵嗩槸缁€鍐煃閸濆嫬鏆欐鐐茬墛娣囧﹪鎮欓鍕ㄥ亾閺嶎厼绀夐柟杈剧畱绾惧綊鏌￠崶銉ョ仼闁告垹濞€楠炴牕菐椤掆偓婵′粙鏌ｉ幘璺烘灈闁绘搩鍋婂畷鎯邦檨闁稿骸绻橀弻娑㈠籍閳ь剛鍒掗幘璇茶摕闁哄洢鍨归悙濠勬喐瀹ュ鏁傛い鎾跺Л閸嬫挸鈻撻崹顔界亶濠电偛鍚嬮悷銊╂倶閹烘鈷戦柛娑橈功缁犳捇鎮楀鐓庡⒉妞ゃ倕鍊圭换婵堝枈婢跺瞼锛熼梺绋款儐閸ㄥ灝鐣烽幇鏉跨闁挎洍鍋撻柛銊ュ€圭换娑橆啅椤旇崵鍑归梺绋款儜缁绘繈寮诲澶婁紶闁告洦鍓欏▍锝囩磽娴ｅ搫校闁绘濞€瀵顓兼径濠勫幐婵炶揪绲介幉鈥斥枔閺屻儲鈷戠紒瀣閹癸綁鏌涢悩宕囧⒌鐎殿喖顭峰鎾閻橀潧鈧偤鎮峰⿰鍐ら柤楦块哺缁绘繂顫濋鐘插箥闂備礁鎲￠崹顖炲磹閺嶎偀鍋撳鐐
KiUserExceptionDispatcher 的核心是对 RtlDispatchException 的调用。这拉开了搜索已注册的异常处理程序的序幕。如果某个处理程序处理这个异常并继续执行，那么对 RtlDispatchException 的调用就不会返回。如果它返回了，只有两种可能：或者调用了NtContinue以便让进程继续执行，或者产生了新的异常。如果是这样，那异常就不能再继续处理了，必须终止进程。
现在把目光对准 RtlDispatchException 函数的代码，这就是我通篇提到的遍历异常帧的代码。这个函数获取一个指向EXCEPTION_REGISTRATION 结构链表的指针，然后遍历此链表以寻找一个异常处理程序。由于堆栈可能已经被破坏了，所以这个例程非常谨慎。在调用每个EXCEPTION_REGISTRATION结构中指定的异常处理程序之前，它确保这个结构是按DWORD对齐的，并且是在线程的堆栈之中，同时在堆栈中比前一个EXCEPTION_REGISTRATION结构高。
RtlDispatchException并不直接调用EXCEPTION_REGISTRATION结构中指定的异常处理程序。相反，它调用 RtlpExecuteHandlerForException来完成这个工作。根据RtlpExecuteHandlerForException的执行情况，RtlDispatchException或者继续遍历异常帧，或者引发另一个异常。这第二次的异常表明异常处理程序内部出现了错误，这样就不能继续执行下去了。
RtlpExecuteHandlerForException的代码与RtlpExecuteHandlerForUnwind的代码极其相似。你可能会回忆起来在前面讨论展开时我提到过它。这两个“函数”都只是简单地给EDX寄存器加载一个不同的值然后就调用ExecuteHandler函数。也就是说，RtlpExecuteHandlerForException和RtlpExecuteHandlerForUnwind都是 ExecuteHanlder这个公共函数的前端。
ExecuteHandler查找EXCEPTION_REGISTRATION结构的handler域的值并调用它。令人奇怪的是，对异常处理回调函数的调用本身也被一个结构化异常处理程序封装着。在SEH自身中使用SEH看起来有点奇怪，但你思索一会儿就会理解其中的含义。如果在异常回调过程中引发了另外一个异常，操作系统需要知道这个情况。根据异常发生在最初的回调阶段还是展开回调阶段，ExecuteHandler或者返回DISPOSITION_NESTED_EXCEPTION，或者返回DISPOSITION_COLLIDED_UNWIND。这两者都是“红色警报！现在把一切都关掉！”类型的代码。
如果你像我一样，那不仅理解所有与SEH有关的函数非常困难，而且记住它们之间的调用关系也非常困难。为了帮助我自己记忆，我画了一个调用关系图（图十五）。
图十五 在SEH中是谁调用了谁
KiUserExceptionDispatcher()
RtlDispatchException()
RtlpExecuteHandlerForException()
ExecuteHandler() // 通常到 __except_handler3
__except_handler3()
scopetable filter-expression()
__global_unwind2()
RtlUnwind()
RtlpExecuteHandlerForUnwind()
scopetable __except block()
现在要问：在调用ExecuteHandler之前设置EDX寄存器的值有什么用呢？这非常简单。如果ExecuteHandler在调用用户安装的异常处理程序的过程中出现了什么错误，它就把EDX指向的代码作为原始的异常处理程序。它把EDX寄存器的值压入堆栈作为原始的 EXCEPTION_REGISTRATION结构的handler域。这基本上与我在MYSEH和MYSEH2中对原始的结构化异常处理的使用情况一样。
结论
结构化异常处理是Win32一个非常好的特性。多亏有了像Visual C++之类的编译器的支持层对它的封装，一般的程序员才能付出比较小的学习代价就能利用SEH所提供的便利。但是在操作系统层面上，事情远比Win32文档说的复杂。
不幸的是，由于人人都认为系统层面的SEH是一个非常困难的问题，因此至今这方面的资料都不多。在本文中，我已经向你指出了系统层面的SEH就是围绕着简单的回调在打转。如果你理解了回调的本质，在此基础上分层理解，系统层面的结构化异常处理也不是那么难掌握。
附录：关于 “prolog 和 epilog ”
在 Visual C++ 文档中，微软对 prolog 和 epilog 的解释是：“保护现场和恢复现场” 此附录摘自微软 MSDN 库，详细信息参见：
http://msdn.microsoft.com/en-us/library/tawsa7cb(VS.80).aspx（英文）
http://msdn.microsoft.com/zh-cn/library/tawsa7cb(VS.80).aspx（中文）
每个分配堆栈空间、调用其他函数、保存非易失寄存器或使用异常处理的函数必须具有 Prolog，Prolog 的地址限制在与各自的函数表项关联的展开数据中予以说明（请参见异常处理 (x64)）。Prolog 将执行以下操作：必要时将参数寄存器保存在其内部地址中；将非易失寄存器推入堆栈；为局部变量和临时变量分配堆栈的固定部分；（可选）建立帧指针。关联的展开数据必须描述 Prolog 的操作，必须提供撤消 Prolog 代码的影响所需的信息。
如果堆栈中的固定分配超过一页（即大于 4096 字节），则该堆栈分配的范围可能超过一个虚拟内存页，因此在实际分配之前必须检查分配情况。为此，提供了一个特殊的例程，该例程可从 Prolog 调用，并且不会损坏任何参数寄存器。
保存非易失寄存器的首选方法是：在进行固定堆栈分配之前将这些寄存器移入堆栈。如果在保存非易失寄存器之前执行了固定堆栈分配，则很可能需要 32 位位移以便对保存的寄存器区域进行寻址（据说寄存器的压栈操作与移动操作一样快，并且在可预见的未来一段时间内都应该是这样，尽管压栈操作之间存在隐含的相关性）。可按任何顺序保存非易失寄存器。但是，在 Prolog 中第一次使用非易失寄存器时必须对其进行保存。
典型的 Prolog 代码可以为：
mov [RSP + 8], RCX
push R15
push R14
push R13
sub RSP, fixed-allocation-size
lea R13, 128[RSP]
...
中查找“Win32结构化异常处理（SEH）探秘(下)”更多相关内容
中查找“Win32结构化异常处理（SEH）探秘(下)”更多相关内容更多精彩
赞助商链接
