DebugDiag

AutomatedQA AQTime分析CPU占用,API调用序列,多种形式分析报告(AutomatedQA AQTime v6.20.355 x86.rar)
Windbg:logger.exe, logviewer.exe记录Windows API调用,umdh(User-Mode Dump Heap)
LeakDiag -- MS的查Leak工具,未用过
DebugDiag通过生成Dump文件来分析Crash, DeadLock, MemLeak, DeadLoop/BigLoop,还可以分析.Net程序的内存问题
根据经验,DebugDiag分析Debug程序时,即使有Pdb也定位不准确;Release程序配合Pdb分准确分析

DebugDiag分析Debug程序的结果:
msvcr80d.dll is responsible for 401.66 KBytes worth of outstanding allocations. The following are the top 2 memory consuming functions:
msvcr80d!operator new[]+d: 400.00 KBytes worth of outstanding allocations.
msvcr80d!_heap_alloc_base+5c: 1.66 KBytes worth of outstanding allocations.

DebugDiag分析Relase程序的结果:
MemLeakTest.exe is responsible for 800.00 KBytes worth of outstanding allocations. The following are the top 2 memory consuming functions:
MemLeakTest!GenMemLeak+46: 800.00 KBytes worth of outstanding allocations.

Windbg分析Debug Leak比较准确,但是分析Relase时,调用堆栈信息到msvcr*.dll时就没了
Windbg分析方法一(分析大程序时比较卡,rease不行,适用于debug):
1、用gflags打开create user mode stack trace database
2、!heap -s
3、执行操作
4、!heap -s
5、比较-s结果,用!heap -stat -h 0xHeapHandle
6、!heap -flt s 有可能泄露的size
7、!heap -p -a 0x内存地址

release时stack trace丢失例子:
0:001> !heap -p -a 08c78708
address 08c78708 found in
_HEAP @ 3e0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
08c78700 0203 0000 [07] 08c78708 01000 - (busy)
Trace: 009e
7c98cf9a ntdll!RtlDebugAllocateHeap+0x000000e1
7c969564 ntdll!RtlAllocateHeapSlowly+0x00000044
7c938f01 ntdll!RtlAllocateHeap+0x00000e64
78134d83 MSVCR80!malloc+0x0000007a

Windbg分析方法二(只对relase,一样的stack trace丢失):
1、用gflags去掉full page heap
2、!heap -l

BTW: full page heap可以检查数组等内存块越界访问情况!

DebugDiag使用方法:
一、准备:
1、菜单/Tools/Options And Settings,设置分析及调试(crash)的pdb路径。
2、_NT_SOURCE_PATH、_NT_SYMBOL_PATH环境变量

二、得到dump文件
1、常规使用方法是使用向导,向导里有Crash, Performance, Memory/Handle的Rule生成方法!
2、在进程中点右键选择Monitor for Leaks或Create Full Dump,这里产生的dump文件在logs\misc目录中.
注:performance里可以分析.net, iis/com+, web application pool, executable等

三、分析dump文件
1、添加dump文件
2、选择/双击分析脚本,便会得到分析结果(如果是perfomance等有多个dump的,在rule右键菜单点分析)

时间: 2024-07-28 12:34:52

DebugDiag的相关文章

查看内存使用情况

NET Memory Profiler 查看内存使用情况 1 简介 .Net Memory Profiler(以下简称Profiler):专门针对于.NET程序,功能最全的内存分析工具,最大的特点是具有内存动态分析(Automatic Memory Analysis)功能. 2 安装 http://memprofiler.com/download.aspx 下载好后 直接下一步下一步 3 使用方法 支持7种类型.NET程序 启动跟踪(Profiler Application) 选定对应的调试方式

一次显式GC导致的High CPU问题处理过程

项目现场反馈系统出现性能问题,具体表现为:所有的客户端响应极其卡顿. 第一反应推测,难道是DB层面出现阻塞?检查v$session会话状态及等待类型未见异常,应该可以排除DB层面原因导致的可能. 继续检查,难道是应用服务器层面出现资源瓶颈?检查任务管理器,w3wp.exe进程占用在10%-20%之间,整体占用也在30%以下(项目现场服务器环境为某通运营商云服务器,此处有坑),内存占用不到4G,w3wp.exe只占了1G多点,服务器的内存好像是48G这个应该也不是瓶颈.继续...难道是网络?显然不

几个调试工具

1. PAL    http://pal.codeplex.com/ 2. debugDiag   https://www.microsoft.com/en-us/download/details.aspx?id=26798 3. Adplus   https://developer.microsoft.com/en-us/windows/hardware/windows-driver-kit

常见问题_站点出现严重的句柄泄漏问题

1.       句柄泄漏问题 1.1问题描述 现网正在运行的IIS虚拟目录存在严重的句柄泄漏问题,一般一周句柄会增长到1万多 1.2修复方法 (1)将.NET版本由4.0切换为2.0,并优化代码中所有非托管类型的处理 (2)将代码中的日志记录由NLog修改为Log4net 1.3问题原因 原因1:使用NLog第三方dll方式记录日志时导致FILE类型的句柄泄露. 原因2:.NET FrameWork 4.0中clr.dll存在大量线程未释放句柄,以及存在泛型导致资源未释放的问题 1.4问题分析

Windbg程序调试--转载

WinDbg是微软发布的一款相当优秀的源码级(source-level)调试工具,可以用于Kernel模式调试和用户模式调试,还可以调试Dump文件. WinDbg是微软很重要的诊断调试工具: 可以查看源代码.设置断点.查看变量, 查看调用堆栈及内存情况. ? 调试应用程序(用户模式 user mode) ? 调试操作系统及驱劢程序(内核模式 kernel mode) ? 调试非托管程序(native program) ? 调试托管程序(managed program) ? 实时调试 (JIT:

How can I create a dump of SQL Server?

https://blogs.msdn.microsoft.com/askjay/2009/12/29/basic-debugging-concepts-and-setup/ You can create a memory dump of the SQL Server process space in several ways.  There are many external tools that can help you accomplish this such as userdump.exe

常用性能相关工具

Fiddler ProcDump DebugDiag windbg Redgate ILSpy SqlDbx WizTree ... http://pan.baidu.com/s/1hq10arE

调用.NET Serviced Component引发的性能问题及其解决

  在企业用户环境里,.NET Serviced Component使用广泛.它比较好的把传统COM+封装和.NET应用逻辑衔接了起来,在服务器端应用起到重要作用..NET Serviced Component 的使用需要注意到很多方面,特别是要做到对象资源合理应用(pooling)和及时释放(Dispose).现有文章就这方面有很多具体讨论. 在这里,我要分析的是一种以前处理过的特定情况下.NET Serviced Component的引发的High CPU的问题.不只一个客户遇到此类问题,觉

debugging tools

https://blogs.msdn.microsoft.com/debugdiag/ https://blogs.msdn.microsoft.com/debuggingtoolbox/2012/10/04/tools-for-your-debugging-toolbox/ TOOLS –        Performance Monitor – PAL –        Process Monitor –        Process Explorer –        MPSReport