|
《Windows 用户态程序高效排错》市场价元 特价元 购买>> 这里直接把 ebx推入stack然后调用std::cout并没有读取stack中的资料说明func_template（callee）认为参数应该是从寄存器中传入的然而transform函数（caller）却把参数通过stack传递于是使用transform调用func_template的时候func_template无法拿到正确的参数因而导致崩溃通过for loop调用的时候由于参数通过寄存器传递所以func_template就可以正常工作 结论是编译器对参数的传入读取处理不统一导致了这个问题 为何问题在debug模式下不发生或者调换函数次序后也不发生留作你的练习吧 :P 案例分析臭名昭着的DLL Hell如何导致ASPNET出现Server Unavailable 客户的ASPNET程序访问任何页面都报告 Server Unavailable观察发现ASPNET的宿主wwpexe进程每次刚启动就崩溃通过调试器观察崩溃的原因是访问了一个空指针但是从 call stack看这里所有的代码都是wwpexe和net framework的代码还没有开始执行客户的页面所以跟客户的代码无关通过代码检查发现该空指针是作为函数参数从调用者（caller）传到被调用者（callee）的当callee使用这个指针的时候问题发生接下来应该检查caller为什么没有把正确的指针传入callee 奇怪的时候caller中这个指针已经正常初始化了是一个合法的指针调用call语句执行callee的以前这个指针已经被正确地push到stack上了为什么caller从stack上拿的时候却拿到一个空指针呢？再次单步跟蹤发现问题在于caller把参数放到了callee的［ebp+］但是callee在使用这个参数的时候却访问［ebp+c］是不是跟前一个案例很像？但是这次的凶手不是编译器而是文件版本Caller和callee的代码位于两个不同的DLL其中caller是NET Framework 带的而callee是NET Framework SP带的在NET Framework 中callee函数接受个参数但是新版本SP对callee这个函数作了修改增加了个参数由于caller还使用SP以前的版本所以caller还是按照个参数在传递而callee按照个参数在访问所以拿到了错误的参数典型的DLL Hell问题在重新安装NET Framework SP让两个DLL保持版本一致重新启动后问题解决 导致DLL Hell的原因有很多根据经验猜测版本不一致的原因可能是 安装了NET Framework SP后没有重新启动导致某些正在使用的DLL必须要等到重新启动后才能够完成更新 由于使用了Application Center做Load Balance集群中的服务器没有做好正确的设置导致系统自动把老版本的文件还原回去了 [] [] [] |
