MiniDump向导应用程序允许在不编写代码的情况下尝试MiniDumpWriteDump和MiniDumpCallback函数.可以指定将传递给MiniDumpWriteDump函数的MINIDUMP_TYPE标志的组合,并且可以在一系列对话框中响应MiniDumpCallback调用. 如何使用MiniDump Wizard 启动MiniDump向导时,它会显示一个对话框窗口,允许您选择将传递给MiniDumpWriteDump函数的MiniDump类型标志.在同一对话框中,可以指定要响应的

前言 不知道各位看官是否有过类似的经历.好不容易找到一个电影的种子文件,想用百度云的离线下载功能去下载文件,却被百度云无情提示“离线文件因含有违规内容被系统屏蔽无法下载”!假设有这么一个场景,比如最近有一部电影<速度与激情7>很火,百度为了保护版权方的利益,对于凡是种子文件中包含了关键字“速度与激情7”的,一律提示包含有违规内容,禁止下载. 于是乎,后来就有了通过“BEncode Editor”这款工具来修改其中一些敏感性文字的方法来修改种子文件,以达到下载的目的.比如在上一个例子中,我们把种

jhat 是Java堆分析工具(Java heap Analyzes Tool). 在JDK6u7之后成为标配. 使用该命令需要有一定的Java开发经验,官方不对此工具提供技术支持和客户服务. 用法: jhat [ options ] heap-dump-file 参数: options 可选命令行参数,请参考下面的 Options heap-dump-file 要查看的二进制Java堆转储文件(Java binary heap dump file). 如果某个转储文件中包含了多份 heap d

简介 MiniDumpView实用程序可用于显示minidump中数据流的内容.特别是,可以显示以下信息: 操作系统和CPU信息 进程信息(进程ID和时间) 模块列表(包含每个模块的详细信息) 线程列表(包含每个线程的详细信息) 异常信息 保存在小型转储中的内存区域列表 打开的句柄列表 虚拟内存布局 注释 以绿色包的形式提供,解压后可用 用法 设置环境变量 命令行里执行MdpView FileName其中FileName是小型转储文件的名称 SYSTEM INFORMATION---------

转载:http://blog.csdn.net/kevin_luan/article/details/8447896 http://liulinxia02.blog.163.com/blog/static/26868772009111861834942/ http://zhumeng8337797.blog.163.com/blog/static/100768914201242410583187/ 其中jmap是java自带的工具 查看整个JVM内存状态 jmap -heap [pid]要注意的

一.Windows系统的任务管理器里抓dump 启动任务管理器,选中某个进程,右键,弹出菜单"创建转储文件" 注意事项: 当你在64位Windows系统上抓32位进程的dmup文件时,如果用的是64位任务管理器,那么在用Windbg加载后,要用!wow64exts.sw切换到X86模式下,如果不想做这步切换,就要用32位的任务管理器来生成dmp文件.32位任务管理器在C:\Windows\SysWOW64\Taskmgr.exe 适合的场景:在任务管理器里还能看到进程,当程序出现业务问

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

当我们抓取到Dump文件后,我们抓取的方式对不对,是否包含了我们想要的信息,可不可用,又或这个文件在抓取或传输过程种,有没有损坏,又或者我不想用Windbg进行细致的分析,只想大概了解下异常信息,在这样的需求下,有没有工具帮我们快速浏览Dump文件信息呢,有,今天给大家介绍两款工具. 一.DumpChk.exe DumpChk是Microsoft 崩溃转储文件检查器工具, 是一个可执行的崩溃转储文件的快速分析程序.可以查看有关转储文件包含摘要信息. 如果转储文件已损坏,无法由调试器打开时,dum

前段时间线上服务经常发生卡顿,经过排查发现是大对象引起的Fullgc问题,特此记录排查逻辑. 目录 目的 一.获得服务进程 二.生成dump文件 三.下载mat工具 四.使用mat工具导入第二步生成的dump文件 五.导入后得到如下界面 六.定位大对象(方法一) 七.定位大对象(方法二) 目的 定位产生大对象的代码 一.获得服务进程 jps -l 27885\32474 对应的即为运行的Jar ps:也可使用netstat -lnput|grep 启动端口号 等方式查找 二.生成dump文件 j

1.获取dump文件 使用 以下命令 创建 进程PID = 16231的 dump文件,命名为 order.hprof jmap -dump:format=b,file=order.hprof 16231 将文件下载到本地. 2.使用jdk bin目录下的jvisualvm.exe 装入 order.hprof 分析对应对象的占用内存

1.场景 通常,使用eclipse的mat图形化工具打开dump的时候都会内存溢出. 对于比较小的dump,eclipse可以打开,但一旦dump文件太大,eclipse就有点束手无策. 这时候怎么办呢?可以使用linux下的mat,既Memory Analyzer Tools 2.dump生成 dump可以是内存溢出时让其自动生成,或者手工直接导.配置jvm参数-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/biapp/m.hpro

原文: http://baidutech.blog.51cto.com/4114344/904419 Core,又称之为Core Dump文件,是Unix/Linux操作系统的一种机制,对于线上服务而言,Core令人闻之色变,因为出Core的过程意味着服务暂时不能正常响应,需要恢复,并且随着吐Core进程的内存空间越大,此过程可能持续很长一段时间(例如当进程占用60G+以上内存时,完整Core文件需要15分钟才能完全写到磁盘上),这期间产生的流量损失,不可估量. 凡事皆有两面性,OS在出Core

1. Dump文件的用途 Dump文件, 主要用于诊断一个进程的运行状态,尤其是碰到崩溃(Crash)或者挂起(hang)不响应时,需要分析它的工作状态.  除了平时常见的attach到这个进程, 分析Dump文件就成了一个重要的手段了. 相信一些做软件维护和支持的工程师在这方面深有体会, 比如某天某时,客户说, 呀, 糟糕, 服务器进程挂掉了, 怎么回事? 然后,看看了日志文件,也没有什么可用的信息.  技术支持告诉他, 按某步骤生成一个dump文件来看看...... 2. 如何生成Dump文

一.Windows系统的任务管理器里抓dump 启动任务管理器,选中某个进程,右键,弹出菜单"创建转储文件" 注意事项: 当你在64位Windows系统上抓32位进程的dmup文件时,如果用的是64位任务管理器,那么在用Windbg加载后,要用!wow64exts.sw切换到X86模式下,如果不想做这步切换,就要用32位的任务管理器来生成dmp文件.32位任务管理器在C:\Windows\SysWOW64\Taskmgr.exe 适合的场景:在任务管理器里还能看到进程,当程序出现业务问

问题情形 当应用在Azure 应用服务App Service中运行时,有时候出现CPU,Memory很高,但是没有明显的5XX错误和异常日志,有时就是有异常但是也不能明确的指出具体的代码错误.当面临这样的情形是,有效的排查办法就是在问题重现的时候抓取DUMP文件,可以通过DUMP文件分析出是否有线程死锁,或查看时那些请求导致的死锁问题.也可以定位到相关的自定义代码类文件.非常助于下一步的查找问题. 抓取DUMP文件 1) 利用App Service自带Kudu的工具获取DUMP文件 登录进当前应

一.背景 今天下午,正酣畅淋漓的搬砖,突然运维同事在群里通知,核心服务某个节点内存异常,服务假死.神经一下子紧张起来,赶紧跑到运维那边观察现象. 观察的结果是服务内存溢出,该服务是核心服务,分配了5G内存.运维在转存快照后,立刻重启服务后正常.在接下来的一段时间里,另一台服务节点也发生了同样的情况. 二.分析过程 这个服务是另外一个同事负责开发的,本着学习的态度,在拿到运维转存的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 的话: 当程序运行的过程中异常终止或崩溃,操作系统会将程序当时的

  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

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