近日在用OllyDBG调试程序时出现异常，停留在堆栈 [0012F358]=77BE14BC (msvcrt.77BE14BC), ASCII "Access violation - no RTTI data!"，异常代码是E06D7363，强行Shift+F8/F9后，然后还会继续持续异常，报0eedfade，如此循环。
开始时怀疑是程序内部做了防DEBUG监控处理，用IsDebugPresent插件隐藏调试标识，还是不行，查API参考并没有DEBUG类似的函数调用，程序本身在没有DEBUG的情况下能正常运行，搞什么虾米嘛。
动手上WinDBG，好了微软的东西就是微软的，找到问题还能自己处理，提示如下：
C++ EH exception - code e06d7363 (first chance)
(7a0.78c): Unknown exception - code 0eedfade (first chance)
(7a0.78c): Unknown exception - code 0eedfade (first chance)
……
发现问题了是C++ EH exception这个错误，然后还有个重点first chance。
官方意思就是仅仅表明有条C++环境异常发生，并被调试器首个捕捉到，这是调试程序可以在被调试程序处理该异常前得到通知，例如catch中的回调。
在这种情况下，WinDBG或者VC++得调试器会仅仅打印信息而忽略此项错误，继续工作。
……
到这里真相大白， OllyDBG没有识别这类异常，按常理进行处理，所以就挂在那找不到北了，因为如果从异常那里跟踪下去，很快就会遇到内存访问错误，是跟不下去的。
好了，知道这马事，不是反调试的话那就好办多了，动手处理吧，还是用OllyDBG继续调试吧，用习惯了，打开OD菜单中的“选项”，“调试选项”->“异常”处，选中同时忽略以下异常：e06d7363和0eedfade。
确定后重新加载程序，最后该干啥干啥去。
(The message just tells you that a C++ exception has been thrown. The debugger gets a notification before handler code which may handle the exception (e.g. a catch block somewhere up the callstack) -- hence first chance.
The default action for Windbg and the Visual C++ debugger is to print a message and continue execution.
So it's perfectly possible that the exception is expected and handled correctly. However, if you are not certain you can always instruct the debugger to break on first chance exceptions and the examine the program state (e.g. the callstack)
In windbg it would be sxe eh and in the Visual C++ use Debug, Exceptions, C++ exceptions, break when thrown.）