1.使用~*kb 2000 查看本地锁的callstack情况,有sleep的线程关注是否占用锁,有wait等待的线程可能是正在等待锁资源. 2.使用~*e!clrstack 查看.net的callstack.出现..threading.monitor.Enter--->表示该线程可能在等待锁:...threadsleepInternal--->该线程在sleep可能正占用锁: 3.使用!syncblk查看线程中锁的信息.info列表示占用锁的线程ID; 4.使用!ip2md [方法对应的ei

这两天有同学使用数据校验工具时发现进程hang住了,也不知道什么原因,我简单看了看进程堆栈,问题虽然很简单,但能导致程序hang住,也一定不是小问题.简单说明下程序组件的结构,程序由两部分构成,dbchk和dbchk_inner,dbchk采用python代码实现,dbchk_inner采用C语言实现.dbchk负责并发控制,dbchk_inner则负责具体的校验任务.用户通过运行dbchk命令即可达到校验的目的.进程关系如下: $ pstree 18649 dbchk─┬─sh───dbchk

1. 问题简介 最近产品发布大版本补丁更新,一商超客户升级后,反馈系统经常奔溃,导致超市的收银系统无法正常收银,现场排队付款的顾客更是抱怨声声.为了缓解现场的情况, 客户都是手动回收IIS应用程序池才能解决. 这样的后果是很严重的,接到反馈,第一时间想到的是加内存吧,这样最快.但是客户从8G-->16G-->32G,只是延长了每次奔溃的时间,但是并没有解决系统卡顿的问题.到这里,也基本猜测了问题所在了,肯定是什么东西一直在吃内存且得不到释放.这种问题,也就只能打Dump分析了. 2. 打Dum

记录下自己使用WinDbg分析Dump时常用的一些方法和命令 !analyze -v //找出出错的堆 .exrc //找到程序崩溃的位置 !heap //打印出错函数的局部位置 !for_each_frame dv /t //显示call stack内容 ~*kbn //显示所有线程信息 ~线程号 s //切换线程 kbn //显示当前线程信息 .reload //加载符号信息 !runaway //查看19号线程所用时间 .load wow64exts !sw //切换到64位 定位Unha

1.     必须在命令行中设置为要分析的进程打开用户堆栈信息:C:\Program Files\Debugging Tools for Windows (x64)>gflags.exe -i YourDebugProcess.exe +ust 2.     必须是Debug版本的进程 3.     设置好windbg的pdb路径,即symbol path 4.     利用windbg的AttachToProcess (貌似后面这个方案不行:在目标机器上产生转储文件(dump)然后用windb

Windbg的一些简单使用命令 一.崩溃 1.  输入.ecxr;kbn得到崩溃的堆栈 其中源代码如下 2.  查看堆栈和源代码,发现第0帧导致崩溃,代码也是本地代码 输入.frame  0,切到第0帧如下 3.  输入 dv 查看当前帧的一些变量信息 发现变量p =0x00000000 二.句柄泄漏 1.  启动进程 2.  用windbg附加到进程 3.  !htrace  -enable命令开启句柄检测 4.  !htrace  –snapshot 5.  运行一段时间后 6.  !htr

大多数人或许都经历过系统蓝屏问题,然而大多数人不清楚该怎么处理蓝屏问题,这里主要对系统蓝屏做一些解释,同时介绍下蓝屏问题分析工具WinDbg分析蓝屏问题的一般步骤. 微软官方对蓝屏的定义是,当系统遇到一些可能会威胁系统安全的情况时,系统会停止工作,这时的状态(即蓝屏)叫做Bugcheck, 即bug检查. 一般导致蓝屏的原因可能是:系统崩溃,系统内核出错,或者别的程序导致系统停止工作. 系统蓝屏其实是系统对电脑的一种保护机制,当系统检测到严重威胁可能会导致系统或硬件安全时,这时会停止工作以起到保

一:背景 1. 讲故事 上个月有位朋友加微信求助,说他的程序跑着跑着就内存爆掉了,寻求如何解决,截图如下: 从聊天内容看,这位朋友压力还是蛮大的,话说这貌似是我分析的第三个 MES 系统了,看样子 .NET 在传统工厂是巨无霸的存在哈... 话不多说,一起用 Windbg 一探究竟吧. 二:Windbg 分析 1. 托管还是非托管 先看下进程的commit内存,用 !address -summary 即可. 0:000> !address -summary Mapping file sectio

http://www.appinn.com/blue-screen-search-code/ 蓝屏代码查询器 – 找出蓝屏的元凶 11 文章标签: windows / 系统 / 蓝屏. 蓝屏代码查询器可以帮你查出引起蓝屏的故障原因并可以到微软知识库中查询解决方案,和之前的 BlueScreenView 配合是很好的蓝屏故障排除组合.@Appinn 使用时只需填入错误代码的简写即可,另外在支持中心中有关于蓝屏原因分析的文章链接,有兴趣的童鞋可以去看看..  官方网站 | 来自小众软件 http:/

1.关于ODP.NET的Windows计数器问题 使用微软的缺省驱动时,可以通过windows性能监视器很方便的监控数据库连接数,选择.NET Data Provider for Oracle/Sqlserver中的NumberOfPooledConnections即可.但是微软早就放弃了对Oracle驱动的更新,该驱动不仅在性能上比较差(读取40000 rows * 30 cols的数据,仅数据转换大约耗时25秒,而ODP.NET仅需5秒),更悲催的是System.Data.OracleCli

一.WinDbg是什么?它能做什么? WinDbg是在windows平台下,强大的用户态和内核态调试工具.它能够通过dmp文件轻松的定位到问题根源,可用于分析蓝屏.程序崩溃(IE崩溃)原因,是我们日常工作中必不可少的一个有力工具,学会使用它,将有效提升我们的问题解决效率和准确率. 二.设置符号表: 符号表是WinDbg关键的“数据库”,如果没有它,WinDbg基本上就是个废物,无法分析出更多问题原因.所以使用WinDbg设置符号表,是必须要走的一步. 1.运行WinDbg软件,然后按[Ctrl+

步骤一: 生成dump文件. #include <Windows.h> #include <iostream> #include <DbgHelp.h> #include <tchar.h> using namespace std; #pragma comment(lib, "dbghelp.lib") LONG WINAPI TopLevelExceptionFilter(struct _EXCEPTION_POINTERS *pExc

百篇博客系列篇.本篇为: v56.xx 鸿蒙内核源码分析(进程映像篇) | ELF是如何被加载运行的? | 51.c.h.o 加载运行相关篇为: v51.xx 鸿蒙内核源码分析(ELF格式篇) | 应用程序入口并不是main | 51.c.h.o v53.xx 鸿蒙内核源码分析(ELF解析篇) | 你要忘了她姐俩你就不是银 | 51.c.h.o v54.xx 鸿蒙内核源码分析(静态链接篇) | 完整小项目看透静态链接过程 | 51.c.h.o v55.xx 鸿蒙内核源码分析(重定位篇) | 与国

百篇博客系列篇.本篇为: v47.xx 鸿蒙内核源码分析(进程回收篇) | 临终前如何向老祖宗托孤 | 51.c.h .o 进程管理相关篇为: v02.xx 鸿蒙内核源码分析(进程管理篇) | 谁在管理内核资源 | 51.c.h .o v24.xx 鸿蒙内核源码分析(进程概念篇) | 进程在管理哪些资源 | 51.c.h .o v45.xx 鸿蒙内核源码分析(Fork篇) | 一次调用,两次返回 | 51.c.h .o v46.xx 鸿蒙内核源码分析(特殊进程篇) | 龙生龙凤生凤老鼠生儿会打洞

百篇博客系列篇.本篇为: v28.xx 鸿蒙内核源码分析(进程通讯篇) | 九种进程间通讯方式速揽 | 51.c.h .o 进程通讯相关篇为: v26.xx 鸿蒙内核源码分析(自旋锁篇) | 自旋锁当立贞节牌坊 | 51.c.h .o v27.xx 鸿蒙内核源码分析(互斥锁篇) | 比自旋锁丰满的互斥锁 | 51.c.h .o v28.xx 鸿蒙内核源码分析(进程通讯篇) | 九种进程间通讯方式速揽 | 51.c.h .o v29.xx 鸿蒙内核源码分析(信号量篇) | 谁在负责解决任务的同步

百篇博客系列篇.本篇为: v24.xx 鸿蒙内核源码分析(进程概念篇) | 进程在管理哪些资源 | 51.c.h .o 进程管理相关篇为: v02.xx 鸿蒙内核源码分析(进程管理篇) | 谁在管理内核资源 | 51.c.h .o v24.xx 鸿蒙内核源码分析(进程概念篇) | 进程在管理哪些资源 | 51.c.h .o v45.xx 鸿蒙内核源码分析(Fork篇) | 一次调用,两次返回 | 51.c.h .o v46.xx 鸿蒙内核源码分析(特殊进程篇) | 龙生龙凤生凤老鼠生儿会打洞 |

百篇博客系列篇.本篇为: v02.xx 鸿蒙内核源码分析(进程管理篇) | 谁在管理内核资源 | 51.c.h .o 进程管理相关篇为: v02.xx 鸿蒙内核源码分析(进程管理篇) | 谁在管理内核资源 | 51.c.h .o v24.xx 鸿蒙内核源码分析(进程概念篇) | 进程在管理哪些资源 | 51.c.h .o v45.xx 鸿蒙内核源码分析(Fork篇) | 一次调用,两次返回 | 51.c.h .o v46.xx 鸿蒙内核源码分析(特殊进程篇) | 龙生龙凤生凤老鼠生儿会打洞 |

最近几周都在解决程序不稳定的问题,具体表现为程序(多进程)时不时的Hang住,同时伴随某个进程的High CPU.跟踪下来,基本都是各种死锁引起的.这里选取一个典型的场景进行分析. 1.抓dump分析 由于这个问题不能稳定重现,所以比较靠谱的方法是出现后抓Dump再分析.老方法:ProcDump -ma [ProcessName].这是个多进程Hang住的情况,具体表现为主进程Main点击退出时,子进程Mkt不响应.到底是哪个进程挂掉了呢? 2.先看Main 首先!syncblk: 0:000>

1.提取Dump格式文件 有两种方式: 第一种,程序崩溃时,启动任务管理器,选择崩溃的*.exe进程,右键选择创建转储文件,通过 开始—运行—输入 %temp% --确定--在打开Temp窗口中即可找到*.dmp文件. 第二种,通过windbg生成dump 文件. 步骤:       1) 打开Windbg并将之Attach 到crash的程序进程       2) 输入产生dump 文件的命令        Windbg产生dump 文件的命令是 .dump ,可以选择不同的参数来生成不同类型

写在前面的话: 继续上篇,在获得了Kernel32.dll基址的基础上,分析它的导出表结构: 对PE结构不太熟悉的同学,可以参考看雪论坛里的一篇帖子:https://bbs.pediy.com/thread-224265.htm 零.思路说明 分析之前,要明确我们的目的是,为了能在程序里获得某些API的地址: I)   遍历导出名称表(下面统称为ENT),匹配到需要的函数[匹配过程中,设置一个自增的变量,这样找到后,变量里就是该函数在ENT里的下标] II)  根据导出序号表(下面统称EOT),

A.利用工具umdh(user-mode dump heap)分析:此处以程序MemoryLeak.exe为例子 1.开启cmd 键入要定位内存泄露的程序gflags.exe /i memroyleak.exe +ust,如图成功后,开启memoryleak.exe程序. 2.利用UMDH创建Heap快照                  命令格式:umdh -pn:memoryleak.exe -f:snap1.log 程序运行一段时间后或者程序占用内存增加时,然后再次创建heap快照,命令行