windbg heap

regedit状态位:0x02001000, 0x2,此时为常规页堆,但感觉无法准确输出call stack,-p -a访问失败,dph_block_information不准确.
regedit状态位:0x02001000, 0x3,此时为完全页堆,完全页堆中heap -l命令不可用、 heap -x命令没有结果。

完全页堆时,申请的内存粒度为0x1000(4K),且在申请的内存块后面再加个4K的栏栅内存。
完全页堆时,HEAP_ENTRY变为DPH_HEAP_BLOCK,且不跟用户内存连续:

(heap -p -h xx部分输出结果)Busy allocations
DPH_HEAP_BLOCK : UserAddr UserSize - VirtAddr VirtSize
00151634 : 00198fd8 00000024 - 00198000 00002000
MSCTF!CSharedBlockNT::`vftable‘
0015183c : 0017eff8 00000008 - 0017e000 00002000
001534d4 : 01efafe0 00000020 - 01efa000 00002000
00153074 : 01f57ff0 0000000c - 01f57000 00002000
001531dc : 01f3bf88 00000074 - 01f3b000 00002000
00152a0c : 01f24f88 00000074 - 01f24000 00002000
00152c3c : 01f20f88 00000074 - 01f20000 00002000

heap -p -h heap_handle,输出heap中的所有entry
heap -i heap_entry指针,打印(_heap_entry)结构体内容,共8字节,需要注意的是,这里的size单位为8字节

+ust时,用户申请的内存指针前是0x20字节的dph_block_information,再往上是heap_entry,否则直接是heap_entry
dph_block_information,dph_heap_block, heap -p -a都可以输出stacktrace
heap -p -a 内存地址,开启页堆(完全或常规)时,报访问错误输出不了call stack,不开启时relase又输出不完整;只有debug下才有用。

heap-p-a访问失败示例:
0:001> !heap -p -a 0218ef20
ReadMemory error for address eeddccee
Use `!address eeddccee‘ to check validity of the address.

heap -l fullpage 不可用, normal page正常, debug正常
heap -x fullpage 无输出, noraml page正常, debug正常
heap -flt / -p -h 中第一项在full heap page时,是dph heap block,在normal heap page时,是heap entry

normal page时,!heap -x输出示例:
0:001> !heap -x 02140180
Entry User Heap Segment Size PrevSize Unused Flags
-----------------------------------------------------------------------------
02140158 02140160 01df0000 02140000 118 118 14 busy extra
其中:118: 包含14字节填充空间,8字节heap_entry,0x20字节_dph_block_information

时间: 2024-08-01 21:09:17

windbg heap的相关文章

Windbg Extension NetExt 使用指南 【3】 ---- 挖掘你想要的数据 Managed Heap

摘要 : NetExt中有两个比较常用的命令可以用来分析heap上面的对象. 一个是!wheap, 另外一个是!windex. !wheap 这个命令可以用于打印出heap structure信息. heap 上 object汇总后的信息. 这个命令也可以按照一些条件过滤出objects, 不过执行速度比较慢. 在这一点上, 更推荐!windex.!windex是一个非常常用的命令. 这个命令可以用来查找heap上面实现某个interface, 继承某个abstract class 或者clas

Windbg找出memory leak的一种笨办法

以下内容是转自 http://www.cnblogs.com/fbird/p/5889596.html 以前做项目碰到过一个问题,在客户的站点上面发现有严重的内存泄漏.幸运的是我们找到了重现的步骤,一轮下来大概有几十兆的泄漏,但是以下常规方法却没啥用. 用windbg把heap上面的object全部dump下来,和上一轮操作作比较,并不能发现什么有用的东西. 大对象heap上面也没啥有用的东西. 像.net memory profiler这种比较智能的工具也用不上,因为一轮操作下来已经能使工具o

Windbg(2)

摘抄于:http://www.cnblogs.com/awpatp/category/228209.html Debug相关的一些小技巧 摘要: 1. 如何Debug一个进程的子进程? 答: 使用WinDBG attach到父进程, 然后输入命令".childdbg 1"(无引号). 这样子进程在刚刚被加载的时候, WinDBG就Attach上去了. 这两个进程的debug session都在一个WinDBG的窗口里, 如果想要切换当前进程, 可以使用命令"|"来查

基于WinDbg的内存泄漏分析

在前面C++中基于Crt的内存泄漏检测一 文中提到的方法已经可以解决我们的大部分内存泄露问题了,但是该方法是有前提的,那就是一定要有源代码,而且还只能是Debug版本调试模式下.实际上很 多时候我们的程序会用到第三方没有源代码的模块,有些情况下我们甚至怀疑系统模块有内存泄露,但是有没有证据,我们该怎么办? 这时我们就要依靠无所不能的WinDbg了. WinDbg的!heap命令非常强大,结合AppVerifier可以对堆(heap)内存进行详细的跟踪和分析, 我们接下来对下面的代码进行内存泄漏的

windbg命令详解

DLL 该扩展仅在内核模式下使用,即使它是在Ext.dll中的. Windows NT 4.0 Ext.dll Windows 2000 Ext.dll Windows XP和之后 Ext.dll 注释 如果不提供参数,调试器会列出所有进程,以及时间和优先级统计.这和使用!process @#Process 0 作为CommandString值一样. To terminate execution at any point, press CTRL+BREAK (in WinDbg) or CTRL

如何使用windbg检测内存泄漏

1.设置符号路径 打开windbg,在菜单Symbol File PATH设置 "SRV*d:\symbols*http://msdl.microsoft.com/download/symbols" d:\symbols是你本地磁盘的一个文件夹,用于下载微软的符号文件 另外,把调试的目标程序的PDB文件路径加到后面 例如:SRV*d:\symbols*http://msdl.microsoft.com/download/symbols;d:\Develop\projects\Servi

WinDbg Command-Line Options

http://msdn.microsoft.com/zh-cn/library/ff561306(v=vs.85).aspx The WinDbg command line uses the following syntax: windbg [ -server ServerTransport | -remote ClientTransport ] [-lsrcpath ] [ -premote SmartClientTransport ] [-?] [-ee {masm|c++}] [-clin

OD: Heap Overflow

Windows 堆溢出 MS 没有完全公开 Windows 的堆管理细节,目前对 Windows 堆的了解主要基于技术狂热者.黑客.安全专家.逆向工程师等的个人研究成果. 目前 Windows NT4/2000 SP4 上的堆管理策略基本(与攻击相关的数据结构和算法)研究清楚. 堆溢出的重要研究者: Halvar Flake:2002 年 Blach Hat 上首次挑战 Windows 的堆溢出,揭秘了堆中一些重要的 Data Structure 和算法.演讲"Third Generation

windbg sos版本不匹配问题解决

dumpheap 时提示: 0:105> !dumpheap -stat The garbage collector data structures are not in a valid state for traversal. It is either in the "plan phase," where objects are being moved around, or we are at the initialization or shutdown of the gc h