应用程序自动退出有关问题，深夜求救，不想通宵啊
应用程序自动退出问题，深夜求救，不想通宵啊。
现有一使用VS2003 VC 的通信服务程序，以前一直运行很正常，最近突然发现有不定期退出问题，并且退出的时间一般都在通信量比较大的情况下。在退出时，程序没有任何报错信息，就是突然一下就没有了，检查程序的退出消息，也没有发现调用的迹象，现求助：
解决该问题常用的思路。
解决该问题需要的工具。
使用写日志的方法也尝试了，由于也没有定位到确切的位置。
今天一天都在搞这个问题，实在快不行了，360度冰天雪地裸求答案。
------解决方案--------------------
程序里面在认为比较关键的地方加日志,
或者用调试的方式启动程序, 查看异常之类的情况
------解决方案--------------------
个人觉得还是越界的问题。以前我也碰到过这样的问题，要很长时间之后才能出现。你重点查看一下你收包之后的处理，是不是要解压缩等等？是不是和你的收到的数据包有关系呢？只有写日志分析，以及用一些抓包的工具来分析你的数据包，没有别的特别好的办法。
------解决方案--------------------
试试这个程序崩溃报告
http://www.codeproject.com/debug/crash_report.asp
------解决方案--------------------
崩溃的时候，
线程会自动被服务器杀死，try-catch也无法阻止的，例如你对一个NULL指针执行了一个强制转换操作，即使用TRY-CATCH，你的程序也会崩溃并被服务器杀死，你是记录不到这个异常的
使用SetUnhandleException函数看看
因该是发生了全局无法处理的异常
导致这样的退出，一般都是内存操作出问题，而内存问题里引发这样错误有30%是指针越界 30%是代码错误导致对NULL指针进行了操作
------解决方案--------------------
看看DrWatson有没有抓到程序崩溃的dump，其中的log文件可以查到导致崩溃的指令。如果用WinDbg查看dump文件，结合源代码可以定位到发生错误的代码行。
------解决方案--------------------
1.假如怀疑跟通信量有关,可以人为的采用一些手段,产生巨大的通信量,从 "偶尔崩溃 "到 "快速崩溃 ".从而能够在在线调试时复现这个问题,这是最理想的情况.
2.在线调试.运行一晚上不关机,到崩溃了调试器自然会捕获到异常.
如果Debug版本不崩溃,只是Release版本崩溃,那么有可能是编译器优化产生的问题.可以将优化选项去掉,看看是否仍然崩溃.如果去掉优化选项后不崩溃,那么基本上你倒霉了,需
要进一步尝试增减优化选项,直到发现是什么优化产生了问题,关掉此优化即可.
如果去掉优化后仍有问题,基本上可以肯定是你的代码有BUG.可以把Release版本配置成也产生必要的调试信息,再按照1或2的方式在线调试.
3.如果在线调试不崩溃,那只有实际运行了.编译时产生.MAP文件.使用SEH的__try .. __except语句捕捉异常. 要捕获内存访问方面的异常,恐怕还要加上捕捉异步异常的选项/EHa
了.
另外,在多线程应用中,必须在每个线程过程函数中包上SEH. 最后还需要在异常捕获后将发生异常时的CONTEXT用日志记录下来,主要是记录CPU执行到哪个地址上的指令时产生异常,
以及指令正在访问的内存地址.这样通过MAP文件可以找到崩溃地址.
4.崩溃地址其实只能作为参考,造成崩溃的真正凶手可能是之前的某个操作破坏了程序中的某个数据结构,而这个操作并没有使程序产生异常,直到后面的另一个操作要访问这个数据
结构时,才引发异常,那么这个恐怕是比较难查了. 而且，这个破坏性操作可能与崩溃地址相隔很远，可能是在不同的线程中，或者不同的模块中，或者不同的DLL中。 这通常会让我非常郁闷.在经过N次的调试和执行之后,,也许能够从种种迹象,比如崩溃发生的条件和时机等等,发现一些蛛丝马迹.
如果足够幸运,N次的静态阅读代码之后,也许还能找到若干处真正可疑的代码,最后经过排除,甚至能找到导致崩溃的真正的原因. 这种破坏性操作,可能是数组越界,也可能是对无效
指针进行了写操作,而根据我的调试经验，在多线程程序中,后者似乎更常见些。 有很多调试工具可以帮助我们快速的找到这个破坏性操作! 比如Boundcheck,Rational Purify.我
更推荐使用Rational Purify，因为它能在第一时间轻易的发现多种类型的破坏性操作。
最后祝楼主好运.
现有一使用VS2003 VC 的通信服务程序，以前一直运行很正常，最近突然发现有不定期退出问题，并且退出的时间一般都在通信量比较大的情况下。在退出时，程序没有任何报错信息，就是突然一下就没有了，检查程序的退出消息，也没有发现调用的迹象，现求助：
解决该问题常用的思路。
解决该问题需要的工具。
使用写日志的方法也尝试了，由于也没有定位到确切的位置。
今天一天都在搞这个问题，实在快不行了，360度冰天雪地裸求答案。
------解决方案--------------------
程序里面在认为比较关键的地方加日志,
或者用调试的方式启动程序, 查看异常之类的情况
------解决方案--------------------
个人觉得还是越界的问题。以前我也碰到过这样的问题，要很长时间之后才能出现。你重点查看一下你收包之后的处理，是不是要解压缩等等？是不是和你的收到的数据包有关系呢？只有写日志分析，以及用一些抓包的工具来分析你的数据包，没有别的特别好的办法。
------解决方案--------------------
试试这个程序崩溃报告
http://www.codeproject.com/debug/crash_report.asp
------解决方案--------------------
崩溃的时候，
线程会自动被服务器杀死，try-catch也无法阻止的，例如你对一个NULL指针执行了一个强制转换操作，即使用TRY-CATCH，你的程序也会崩溃并被服务器杀死，你是记录不到这个异常的
使用SetUnhandleException函数看看
因该是发生了全局无法处理的异常
导致这样的退出，一般都是内存操作出问题，而内存问题里引发这样错误有30%是指针越界 30%是代码错误导致对NULL指针进行了操作
------解决方案--------------------
看看DrWatson有没有抓到程序崩溃的dump，其中的log文件可以查到导致崩溃的指令。如果用WinDbg查看dump文件，结合源代码可以定位到发生错误的代码行。
------解决方案--------------------
1.假如怀疑跟通信量有关,可以人为的采用一些手段,产生巨大的通信量,从 "偶尔崩溃 "到 "快速崩溃 ".从而能够在在线调试时复现这个问题,这是最理想的情况.
2.在线调试.运行一晚上不关机,到崩溃了调试器自然会捕获到异常.
如果Debug版本不崩溃,只是Release版本崩溃,那么有可能是编译器优化产生的问题.可以将优化选项去掉,看看是否仍然崩溃.如果去掉优化选项后不崩溃,那么基本上你倒霉了,需
要进一步尝试增减优化选项,直到发现是什么优化产生了问题,关掉此优化即可.
如果去掉优化后仍有问题,基本上可以肯定是你的代码有BUG.可以把Release版本配置成也产生必要的调试信息,再按照1或2的方式在线调试.
3.如果在线调试不崩溃,那只有实际运行了.编译时产生.MAP文件.使用SEH的__try .. __except语句捕捉异常. 要捕获内存访问方面的异常,恐怕还要加上捕捉异步异常的选项/EHa
了.
另外,在多线程应用中,必须在每个线程过程函数中包上SEH. 最后还需要在异常捕获后将发生异常时的CONTEXT用日志记录下来,主要是记录CPU执行到哪个地址上的指令时产生异常,
以及指令正在访问的内存地址.这样通过MAP文件可以找到崩溃地址.
4.崩溃地址其实只能作为参考,造成崩溃的真正凶手可能是之前的某个操作破坏了程序中的某个数据结构,而这个操作并没有使程序产生异常,直到后面的另一个操作要访问这个数据
结构时,才引发异常,那么这个恐怕是比较难查了. 而且，这个破坏性操作可能与崩溃地址相隔很远，可能是在不同的线程中，或者不同的模块中，或者不同的DLL中。 这通常会让我非常郁闷.在经过N次的调试和执行之后,,也许能够从种种迹象,比如崩溃发生的条件和时机等等,发现一些蛛丝马迹.
如果足够幸运,N次的静态阅读代码之后,也许还能找到若干处真正可疑的代码,最后经过排除,甚至能找到导致崩溃的真正的原因. 这种破坏性操作,可能是数组越界,也可能是对无效
指针进行了写操作,而根据我的调试经验，在多线程程序中,后者似乎更常见些。 有很多调试工具可以帮助我们快速的找到这个破坏性操作! 比如Boundcheck,Rational Purify.我
更推荐使用Rational Purify，因为它能在第一时间轻易的发现多种类型的破坏性操作。
最后祝楼主好运.