北京建网站实力公司,网站后台验证码不显示,优化公司哪家好,网站必须做ipv6点击蓝字关注我们最近几年工作当中很大一部分内容是排查软件运行过程中遇到的各种异常#xff0c;积累了一定的经验#xff0c;在此给大家分享一下。本文将详细讲述Windows系统中软件异常的分类以及常用的排查方法#xff0c;给大家提供一个借鉴与参考。1、软件异常的分类常…点击蓝字关注我们最近几年工作当中很大一部分内容是排查软件运行过程中遇到的各种异常积累了一定的经验在此给大家分享一下。本文将详细讲述Windows系统中软件异常的分类以及常用的排查方法给大家提供一个借鉴与参考。1、软件异常的分类常见的软件异常有内存越界、内存访问违例、stack overflow线程栈溢出、空指针与野指针、死循环、死锁、内存泄露、GDI对象泄露、函数调用约定不一致导致的栈不平衡等。有的异常会立即导致软件崩溃。有的异常在运行一段时间或者长时间运行后才会导致崩溃比如内存泄露。有的异常则不会导致崩溃只会导致软件发生堵塞或卡死比如死循环和死锁。还有一类问题会导致业务代码执行上的异常这类问题不会导致软件崩溃会导致业务代码没有按照正常逻辑或者分支被执行导致业务逻辑出异常。比如函数抛出异常导致部分代码被跳过即该执行的代码没有执行到导致后续业务代码执行时出现逻辑异常。正常情况下这些被跳过的代码会执行一些判断会设置一些变量的值会直接影响后续代码的判断与执行逻辑所以会导致后续代码在运行时出现业务逻辑上的异常。这样的问题我们以前遇到过几次。再比如系统API函数的lasterror被覆盖导致后续判断lasterror值的条件判断出现逻辑上的错误即产生了误判。这个问题我们以前也遇到过在libjingle库的开源代码中添加了一个打印因为开源代码的接口封装的层次比较深导致我们在添加日志打印的代码时没看出会把lasterror值覆盖的问题。具体的是添加的那句打印日志的代码中调用系统API函数该行打印日志的代码执行完后就会把其前一句的开源库代码产生的lasterror值给覆盖了。而在打印日志下面的下一句开源代码中的接口内部会判断上一句开源代码执行后的lasterror值因为该lasterror值被覆盖了所以导致对lasterror的判断条件出现误判导致后续的业务代码出现了逻辑上的异常。2、使用windbg分析软件异常windbg是Windows平台一个最强大、最通用的软件调试分析工具Windows平台主要使用它来分析各种软件异常。大部分异常崩溃问题软件中的异常捕获模块大家都在使用开源的carshreport异常捕获库都能捕获到并将发生异常时的上下文保存到dump文件中事后可以使用windbg静态分析这些dump文件。对于有些不会导致软件崩溃的异常比如死锁、死循环和内存泄露需要我们将windbg挂载到目标进程上进行动态分析了。对于少数异常捕获模块捕获不到的异常比如程序在运行过程中发生闪退需要将windbg附加到目标进程上跑即windbg和其附加的目标进程绑定在一起运行一旦目标进程出现异常windbg就能立即感知到并中断下来。将windbg附加到目标进程上后我们需要想办法去复现异常异常产生后windbg会捕获到并中断下来此时可以直接去使用windbg命令去分析了也可以将使用.dump命令将异常上下文导出到dump文件中供事后分析。可能分析问题会比较耗时可能出问题的电脑是同事的或者是领导的不能一直占着别人的电脑此时可以选择导出dump文件供事后用windbg分析。对于一些弹框报错或者软件发生卡死的异常软件一直卡在这个点上目标进程还在此时可以直接将windbg挂上去这个时间点已经出现了异常但挂载windbg的时机也不晚也是可以获取到异常的上下文信息的。对于这类问题不要点击报错的确定按钮或者不要急于通过资源管理器去强杀目标进程将目标进程保留住此时将windbg挂上去正是时候也能获取到完整的异常上下文信息。这些异常可能是事后很难复现的必须要逮住这个机会将windbg直接挂载到出问题的进程上进行分析。错过这个机会下次可能就很难复现了这样软件中就留下了很大的隐患。3、除windbg之外的常用异常排查方法当然除了windbg的静态分析和动态调试还有一些其他的常用方法这些方法也很重要也需要掌握比如使用VS直接调试Debug或Release调试、附加到进程中调试、添加打印日志、历史版本比对法找出开始出问题的那个时间点、分块注释代码、设置数据断点对内存进行实时监控等。有时我们需要将多种方法结合起来使用。对于业务上的一些逻辑异常一般需要通过添加日志打印来排查。还有一种典型的异常是软件运行过程中遇到了错误软件自己判断出来了并认为是致命性错误会直接调用abort或者exit强行终止进程的。比如在开源的jsoncpp库中在解析到异常的json节点时出错会直接调用abort强行终止整个进程。再比如在开源的webrtc库中在用new申请堆内存失败时webrtc库内部会认为发生了致命性的错误也会调用abort强行终止进程。这类主动强行终止进程的异常捕获模块是捕获不到的异常因此是不会生成dump文件的。 这类情况可以将windbg挂载到目标进程上跑一旦调用abort接口windbg就会中断下来此时查看函数的调用堆栈就能看到是何处代码触发的问题了。为啥windbg能感知到软件中安装的异常捕获模块捕获不到呢因为软件本身并没有RaiseException是软件主动终止进程的。那为啥windbg能感知到呢因为abort接口中会产生一个SIGABRT终止信号通知这个调试器能感知到于是windbg就产生了中断。此时使用kn命令查看函数调用堆栈就可以看到是哪些接口触发的问题了。可以直接在Visual Studio中go到abort函数实现处查看abort函数的内部实现了如下/***
*void abort() - abort the current program by raising SIGABRT
*
*Purpose:
* print out an abort message and raise the SIGABRT signal. If the user
* hasnt defined an abort handler routine, terminate the program
* with exit status of 3 without cleaning up.
*
* Multi-thread version does not raise SIGABRT -- this isnt supported
* under multi-thread.
*
*Entry:
* None.
*
*Exit:
* Does not return.
*
*Uses:
*
*Exceptions:
*
*******************************************************************************/void __cdecl abort (
void)
{_PHNDLR sigabrt_act SIG_DFL;#ifdef _DEBUG
if (__abort_behavior _WRITE_ABORT_MSG){
/* write the abort message */_NMSG_WRITE(_RT_ABORT);}
#endif /* _DEBUG *//* Check if the user installed a handler for SIGABRT.* We need to read the user handler atomically in the case* another thread is aborting while we change the signal* handler.*/sigabrt_act __get_sigabrt();
if (sigabrt_act ! SIG_DFL){raise(SIGABRT);}/* If there is no user handler for SIGABRT or if the user* handler returns, then exit from the program anyway*/if (__abort_behavior _CALL_REPORTFAULT){_call_reportfault(_CRT_DEBUGGER_ABORT, STATUS_FATAL_APP_EXIT, EXCEPTION_NONCONTINUABLE);}/* If we dont want to call ReportFault, then we call _exit(3), which is the* same as invoking the default handler for SIGABRT*/_exit(3);
}从代码中可以看出产生了一个SIGABRT终止信号通知。 4、开源的CrashReport库存在的问题很多厂商都在使用开源的crashreport异常捕获库但原生的CrashReport库是有缺陷的。很多大厂使用的应该是经过深度改进的crashreport库。开源的crashreport异常捕获库是动态地将已加载的库的导入表中创建线程的API函数CreateThread HOOK成我们自定义的MyCreateThread函数不管调用哪个创建线程的接口最终都会走到CreateThread接口中的这样就能在MyCreateThread中调用系统API函数SetUnhandledExceptionFilter给每个创建的线程挂载异常处理函数了。但这种机制是有缺陷的不能给软件的所有模块的线程挂载异常处理函数只能给在crashreport库之前加载的库挂载异常处理函数在crashreport之后加载的库就没法去hook了这样就会导致没进行hook操作的那些库中发生的异常都捕获不到了。在exe启动时会把所有依赖的库加载到进程空间中我们没法控制所有的库都在crashreport库之前被加载的这也导致了有些异常崩溃crashreport时捕获不到的。后来我们对crashreport库进行了改进使用微软开源的detours项目中的代码将windows系统库中的UnhandledExceptionFilter接口给HOOK掉。因为基本所有的异常都会最终进入到该函数中我们将UnhandledExceptionFilter接口hook成我们自定义的接口我们就能在该自定义的接口中感知到几乎所有的异常了。感知到异常后就可以生成包含异常上下文的dump文件了。这样就能很好的解决老版本crashreport不能hook后加载的库的问题新版本的crashreport就可以作用于当前进程的所有模块了基本可以捕获到进程的所有异常了。当然改进后的crashreport也不是100%的异常都能捕获到但可以捕获大概90%以上的异常。对于捕获不到的场景就需要将windbg挂载到目标进程上让windbg去捕获了。*声明本文于网络整理版权归原作者所有如来源信息有误或侵犯权益请联系我们删除或授权事宜。戳“阅读原文”我们一起进步
