前一节我讲了怎么设置C++崩溃时生成Dump文件 , 点击 传送门 , 这一节我讲讲怎么使用 VS2012 调试生成的 Dump 文件 , 甚至可以精确到出错的那一行代码上面 ; 1. 生成 Dump 文件 我在主函数写了如下崩溃代码 : int main() { // 加入崩溃dump文件功能 SetUnhandledExceptionFilter(ExceptionFilter); // 使程序崩溃产生 Dump 文件 int *p = NULL; *p=; } 双击运行主程序 , 产生了

原文地址:http://blog.csdn.net/starlee/article/details/6649605 在我上篇文章<让程序在崩溃时体面的退出之SEH>中讲解了SEH中try/except可以捕捉异常,避免程序的崩溃,并且可以在处理完异常之后,还能决定进该进程如何执行.对于应用程序的使用者来说,并不知道异常的发生.但是对于软件的开发者来说,虽然避免了程序的崩溃,可是这样可以让程序崩溃的缺陷存在于代码中,就像一个定时炸弹,不知道什么时候会爆炸.要想修复这样的缺陷,首先要找到导致程序崩

突然有一天部署在服务器的一个应用挂掉了,没办法只能进入服务器打开 [事件查看器]查看下,好不容易找到了打开后一脸懵逼 事件查看器查到的内容根本对我们排障没有任何作用. 在这个时候如果有对应的dump文件就能派上用场了, 只要有dump文件就能查到应用挂掉那刻的一手情报,可能有人认为分析dump文件是非常难的事情, 但是最近不断有新的dump分析工具出来,例如用vs2017就能够很简单的分析dump文件. 接下来我们用几个实际的例子来看看如何用vs2017来分析dump文件吧 dump文件的收集

前言 在windows 下 系统核心态程序蓝屏,会产生dump文件. 用户级程序在设置后,程序崩溃也会产生dump文件.以方便开发者用windbg进行分析. so,linux 系统也有一套这样的东东----->Linux Core Dump Linux Core Dump 引用 文章 <Linux Core Dump>  http://www.cnblogs.com/hazir/p/linxu_core_dump.html 的话: 当程序运行的过程中异常终止或崩溃,操作系统会将程序当时的

原文地址:http://gao-xianglong.iteye.com/blog/2173140?utm_source=tuicool&utm_medium=referral 前言 生产环境中,尤其是吃大内存的JVM,一旦出现内存泄露等问题是非常容易引发OutofMemory的,如果没有一个好的工具提供给开发人员定位问题和分析问题,那么这将会是一场噩梦.目前JDK其实自带有一些内存泄露分析工具专门用于帮助开发人员定位内存泄露等问题,但是这些工具往往并不是能够满足一些现状,这里笔者所指的现状更多是

  1.生成core dump文件的方法: $  ulimit -c //查看是否为0 如果为0 $   ulimit -c unlimited 这样在程序崩溃以后会在当前目录生成一个core.xxxx的文件 2.调试core dump文件 生成了core.xxx文件以后 $  gdb ./应用程序  core.xxxx 就会恢复现场到你的程序崩溃的那一刻 (gdb)bt          //这个命令会列出程序崩溃时的堆栈信息,一层一层会有标号  #0  #1  #2 ....... 如果你要

前言 在产品的实际应用环境中,如果我们的程序在客户那里出现了问题,例如程序异常了,而这个时候的现象又不能还原或者很难还原重现,那么只有使用dump文件来保存程序的当前运行信息,例如调用堆栈等,同时使用符号文件来定位问题了;这里主要讲解使用dbghelp库来生成输出dump文件,同时使用符号文件和windbg来分析问题.样例代码 1 #include "stdafx.h" 2 #include <Windows.h> 3 #include <iostream> 4

WinDbg使用有点麻烦,还要符号表什么的.试了下,感觉显示很乱,分析的也不够全面... 试试其他的吧!今天电脑蓝屏了,就使用其dump文件测试,如下: 1.首先,最详细的,要属Osr Online这个在线分析网站了: 打开其分析地址:http://www.osronline.com/page.cfm?name=analyze 下拉,找到上传按钮(上图),将需要分析的dump文件浏览上传即可...dump文件一般在C:\Windows\minidump下 分析完成后生成的内容非常多: 主要看第一

调试SQLSERVER (一)生成dump文件的方法 调试SQLSERVER (二)使用Windbg调试SQLSERVER的环境设置调试SQLSERVER (三)使用Windbg调试SQLSERVER的一些命令 我们知道调试程序主要有两种方法 一种是:live debugging (附加进程 使进程hang住) 生产环境最好不要live debugging 一种是:post-mortem debugging or reading dump files (生成dump文件然后进行分析) 现在介绍一

前言 在开始这篇文章之前我们先来讲讲如何从高度优化的Release版的Dump中找到正确的异常上下文地址,并手动恢复异常发生的第一现场. 1. 什么是异常上下文 简单来说,在windows体系的操作系统里面,每个线程都有自己的线程上下文来保存需要的信息,其中包括当前寄存器的值.我们这里需要找到的异常上下文就是当异常发生的时候,异常分发器帮我们保存的当前寄存器的值(也叫寄存器上下文),利用这些信息结合汇编代码的分析,我们就可以进一步找到发生异常的原因.关于寄存器上下文结构体的定义我们可以在winn

linux下生成core dump文件方法及设置    from:http://www.cppblog.com/kongque/archive/2011/03/07/141262.html core dump的概念: A core dump is the recorded state of the working memory of a computer program at a specific time, generally when the program has terminated a

dump文件可以在程序crash时,方便我们查看程序crash的地方和上下文信息.在window下,要能生成dump文件,需要自己编写相应的代码.不过现在网上可以找到相应的代码,只要把它下载后然后加到自己的工程中去,就可以了! 在linux下面就简单的许多.只要打开相应的开关,linux会自动在程序crash时生成相应的core文件.这个文件和window下的dump文件类似.  下面是简单的一些步骤: 1.查看当前是否已经打开了此开关   通过命令:ulimit -c 如果输出为 0 ,则代表

转载地址:http://erniu.sz.blog.163.com/blog/static/11517292220103282813176/ 把SVN的dump文件导入SVN数据库的方法: 在SVN Server Manager上新建一个Repositories,比如名字为ABCD,则导入命令如下: svnadmin load ABCD > dump文件的全路经 例如:svnadmin load c:\ABCD > d:\abcd.dump

在开发过程中,当一个Linux程序异常退出时,我们可以通过core文件来分析它异常的详细原因.缺省情况下,Linux在程序异常时不产生core文件,要想让程序异常退出时产生core dump文件,需要使用ulimit命令更改coredump的设置: ulimit -c unlimited 上面的命令表示在程序异常时产生core dump文件,并且不对core dump文件的大小进行限制. 上述设置只是使能了core dump功能,缺省情况下,内核在coredump时所产生的core文件放在与该程

前言:通过drwtsn32.NTSD.CDB等调试工具生成Dump文件, drwtsn32存在的缺点虽然NTSD.CDB可以完全解决,但并不是所有的操作系统中都安装了NTSD.CDB等调试工具.了解了mini dump文件格式后,完全可以程序自动生成Dump文件. 本文主要讨论以下内容: 1.  运行原理 2.  程序修改 3.  注意事项 一.   运行原理 当程序遇到未处理异常(主要指非指针造成)导致程序崩溃死,如果在异常发生之前调用了SetUnhandledExceptionFilter(

前言:利用drwtsn32或NTSD进行程序崩溃处理,都可以生成可用于调试的dmp格式文件.使用VS2005打开生成的DMP文件,能很方便的找出BUG所在位置.本文将讨论以下内容: 1.  程序编译选项 2.  利用VS2005 分析dump文件 3.  常见问题讨论 一.       程序编译选项 PDB files contains all debug information like type definition and function prototype. When applicat

GBK Encoding Support 没有安装前打开ASNI格式编码文件会乱码,安装成功重启则可以打开正常 关于.dump文件生成的解释: 当打开一个非utf-8格式且包含汉字的文件时,sublime text 2会自动生成一个dump文件,文件修改过程中,不会修改原文件,只有按"保存"了才会将dump的数据更新到原文件里,关闭当前编辑的dump文件则会自动删除dump文件. 但是有时候 GBK Encoding Support 插件也会出些bug,就想这样,生成.dump文件后自

博客搬到了fresky.github.io - Dawei XU,请各位看官挪步.最新的一篇是:如何生成Dump文件.

原文地址:http://blog.csdn.net/starlee/article/details/6630816 在我的那篇<让程序在崩溃时体面的退出之CallStack>中提供了一个在程序崩溃时得到CallStack的方法.可是要想得到CallStack,必须有pdb文件的支持.但是一般情况下,发布出去的程序都是Release版本的,都不会附带pdb文件.那么我们怎么能在程序崩溃的时候找到出错的具体位置呢?这个时候就该Dump文件出场了!Dump文件是进程的内存镜像,可以把程序运行时的状态

近期两天因为项目的须要,研究了一下Dump文件相关的知识,今天做一个小节(因为研究不久而且第一次写blog,希望网友们看到不要见笑). Dump文件是进程的内存镜像.能够把程序的运行状态通过调试器保存到dump文件里.   Dump文件是用来给驱动程序编写人员调试驱动程序用的,这样的文件必须用专用工具软件打开,比方使用WinDbg打开. 当我们的程序公布出去之后,在客户机上是无法跟踪自己代码的bug的,所以Dump(扩展名是 .dmp)文件对于我们来说特别实用.我们能够通过.dmp文件把出现bu

前言:通过drwtsn32.NTSD.CDB等调试工具生成Dump文件, drwtsn32存在的缺点虽然NTSD.CDB可以完全解决,但并不是所有的操作系统中都安装了NTSD.CDB等调试工具.了解了mini dump文件格式后,完全可以程序自动生成Dump文件. 本文主要讨论以下内容: 1.  运行原理 2.  程序修改 3.  注意事项 一.   运行原理 当程序遇到未处理异常(主要指非指针造成)导致程序崩溃死,如果在异常发生之前调用了SetUnhandledExceptionFilter(