内存对很多人来说感觉是个很熟悉的东西,因为我们在用VC调试程序时,很多时候都会察看内存中变量的值。但是,很多时候我们的思维也就因此局限在有源码的模块,当遇到一些跨模块或是没有源代码的Bug,我们还是无从下手。因此,很有必要我们要对整个程序内存有个比较全局性的认识,这样遇到任何问题,你都能从容面对。
我这里以32位的程序为例,我们知道32位程序总共有4G内存空间,其中低2G是用户地址空间,高2G是内核地址空间,下面我们借助WinDbg工具来分析低2G用户地址空间的内存分布。
因为所有程序的内存分布都大同小异,我这里用WinDbg分析任务管理器进程的内存分布。打开任务管理器,然后用WinDbg Attach到taskmgr.exe进程。
输入 !address -summary 察看内存的使用情况, 结果如下:
从上图可以看到,程序内存根据使用情况大致分为:
Free - 没有被使用的
Image - 加载到内存的模块(dll,exe等)
MappedFile - 内存映射文件
unclassified - 实际上应该是堆(heap)
Stack - 堆栈
TEB - 线程环境块(thread environment block)
PEB - 进程环境块(process environment block)
内存根据使用类型又可以分为:
MEM_IMAGE - 加载到内存的模块(dll, exe等)
MEM_MAPPED - 内存映射
MEM_PRIVATE - 私有(stack, heap, teb, peb等)
内存根据使用状态又可分为:
MEM_FREE - 空闲
MEM_COMMIT - 已经提交
MEM_RESERVE - 保留
根据页面属性又可分为只读,可读写,可执行,写时拷贝等。
实际上我们可以通过!address命令来查看更详细的内存使用情况:
可以看到上面列出了所有2G用户空间的页面使用情况(截图只是开始的一部分),我们可以根据某个地址来分析该地址属于那块内存区域。当然也可以通过命令来分析某个地址所属的内存区域, 比如输入!address 7c554来分析地址7c554的情况,会显示:
上面告诉我们7c554是某个堆栈(Stack)空间的地址.
对我们程序来说最常接触的内存应该是: Module, Heap, Stack,接下来依次分析.
(1)Module
Module在上面被叫住Image,实际上就是被加载到内存的Exe和DLL文件, 我们可以通过lm命令来查看所有的模块分布情况:
上面可以看到每个模块的内存起始地址,那么各个模块具体内部又是如何分布,它和磁盘上的DLL(exe)文件又是什么关系呢?
实际上内存的中DLL和磁盘上的DLL文件非常相似,系统在加载时只是根据页面大小(一般4K)作了一些对齐,另外有些数据节如果运行时用不到(比如dll的重定位节)就不会被加载.
我们在!address查看内存空间时,可以看到taskmgr.exe模块的内存分布如下:
上面可以看到taskmgr.exe模块在内存中分为4块,第一块是只读的, 实际上是PE文件头;第二块是可执行的,实际上就是代码节(.text);第三块是可读写的,实际上数据节(.Data); 最后一块也是只读的,实际上资源节(.rsrc)。
要详细的了解taskmgr.exe模块的文件头属性,可以通过!dh [module address]来查看, 输入!dh 1000000,查看结果:
上面的运行结果可以验证我们关于taskmgr.exe模块内部分布的猜想.
(2)Heap
Heap实际上就是堆,我们所有new(malloc)出来的内存就是分布在堆里,每个程序会有若干个堆,有些是系统创建的,也有的是C/C++运行库创建的,当然我们自己也可以创建私有堆.我们可以通过!heap命令来查看堆的使用情况.
可以看到taskmgr.exe一共有9个堆。
!heap命令非常强大,通过开启页堆功能,可以很方便的让我们跟踪所有堆内存的分配和使用情况,以后有机会再细说heap相关的, 具体可参考我的这篇《 基于WinDbg的内存泄漏分析 》。
(3)Stack
Stack即我们通常所说的栈,我们的局部变量就是分配在栈上面。说到栈就要说到线程,我们的代码都是通过线程跑起来的,每个线程包含2块东西,一块是线程内核对象,还有一块就是堆栈,线程运行过程也是堆栈不断压栈和出栈的过程。
我们可以通!address -f:stack 来查看堆栈的分布情况:
从上图我们可以看到taskmgr.exe一共有4个线程, 对应着4个堆栈, 同时也可以看到每个堆栈内存的起始地址。
如果有兴趣,我们也可以看下每个线程的堆栈情况, 输入~* kp
可以看到相应的4个线程堆栈,最后一个线程(debugBreakPoint)看起来有些奇怪,实际上它是调试器为调试而插入的,不是真正的属于taskmgr.exe, 所以任务管理器实际上一共应该有3个线程.
通过上面的介绍,相信大家对程序内存有了比较全局的理解,以后大家分析问题,遇到一个地址,首先要判断这个地址分布在哪里:
如果是Image上,那么是在哪个模块中,这个地址是属于该模块的代码段(.text)还是数据段(.data),如果是代码段,又是属于哪个函数?
如果是Heap上,那么究竟是在哪个堆里面,是我们new出来的吗,是在什么时候new的(new时堆栈状况)?
如果是在Stack上,那么究竟是属于哪个线程的堆栈,当时线程的堆栈是怎么样?
总之,程序在内存中运行,只有你真正理解了内存,你才能真正懂计算机。
我这里以32位的程序为例,我们知道32位程序总共有4G内存空间,其中低2G是用户地址空间,高2G是内核地址空间,下面我们借助WinDbg工具来分析低2G用户地址空间的内存分布。
因为所有程序的内存分布都大同小异,我这里用WinDbg分析任务管理器进程的内存分布。打开任务管理器,然后用WinDbg Attach到taskmgr.exe进程。
输入 !address -summary 察看内存的使用情况, 结果如下:
![](https://i-blog.csdnimg.cn/blog_migrate/211535207ae39da605fef4be71c5a744.png)
从上图可以看到,程序内存根据使用情况大致分为:
Free - 没有被使用的
Image - 加载到内存的模块(dll,exe等)
MappedFile - 内存映射文件
unclassified - 实际上应该是堆(heap)
Stack - 堆栈
TEB - 线程环境块(thread environment block)
PEB - 进程环境块(process environment block)
内存根据使用类型又可以分为:
MEM_IMAGE - 加载到内存的模块(dll, exe等)
MEM_MAPPED - 内存映射
MEM_PRIVATE - 私有(stack, heap, teb, peb等)
内存根据使用状态又可分为:
MEM_FREE - 空闲
MEM_COMMIT - 已经提交
MEM_RESERVE - 保留
根据页面属性又可分为只读,可读写,可执行,写时拷贝等。
实际上我们可以通过!address命令来查看更详细的内存使用情况:
![](https://i-blog.csdnimg.cn/blog_migrate/c09d1b2d13ee9cd676e25a85e96faffb.png)
可以看到上面列出了所有2G用户空间的页面使用情况(截图只是开始的一部分),我们可以根据某个地址来分析该地址属于那块内存区域。当然也可以通过命令来分析某个地址所属的内存区域, 比如输入!address 7c554来分析地址7c554的情况,会显示:
![](https://i-blog.csdnimg.cn/blog_migrate/eb264c49cd76ddc81b9a6f5a68cc1687.png)
上面告诉我们7c554是某个堆栈(Stack)空间的地址.
对我们程序来说最常接触的内存应该是: Module, Heap, Stack,接下来依次分析.
(1)Module
Module在上面被叫住Image,实际上就是被加载到内存的Exe和DLL文件, 我们可以通过lm命令来查看所有的模块分布情况:
![](https://i-blog.csdnimg.cn/blog_migrate/d6bb505523845cb9754693a27d3efc86.png)
上面可以看到每个模块的内存起始地址,那么各个模块具体内部又是如何分布,它和磁盘上的DLL(exe)文件又是什么关系呢?
实际上内存的中DLL和磁盘上的DLL文件非常相似,系统在加载时只是根据页面大小(一般4K)作了一些对齐,另外有些数据节如果运行时用不到(比如dll的重定位节)就不会被加载.
我们在!address查看内存空间时,可以看到taskmgr.exe模块的内存分布如下:
![](https://i-blog.csdnimg.cn/blog_migrate/6973551cf23af43babdab21f97128dfb.png)
上面可以看到taskmgr.exe模块在内存中分为4块,第一块是只读的, 实际上是PE文件头;第二块是可执行的,实际上就是代码节(.text);第三块是可读写的,实际上数据节(.Data); 最后一块也是只读的,实际上资源节(.rsrc)。
要详细的了解taskmgr.exe模块的文件头属性,可以通过!dh [module address]来查看, 输入!dh 1000000,查看结果:
![](https://i-blog.csdnimg.cn/blog_migrate/c777546913ecb7282e01432261c6ba41.png)
![](https://i-blog.csdnimg.cn/blog_migrate/a0aebab76e37b6f402a64b08fbb195d9.png)
上面的运行结果可以验证我们关于taskmgr.exe模块内部分布的猜想.
(2)Heap
Heap实际上就是堆,我们所有new(malloc)出来的内存就是分布在堆里,每个程序会有若干个堆,有些是系统创建的,也有的是C/C++运行库创建的,当然我们自己也可以创建私有堆.我们可以通过!heap命令来查看堆的使用情况.
![](https://i-blog.csdnimg.cn/blog_migrate/b9f569f91ab7e3eeb73aead14248260a.png)
可以看到taskmgr.exe一共有9个堆。
!heap命令非常强大,通过开启页堆功能,可以很方便的让我们跟踪所有堆内存的分配和使用情况,以后有机会再细说heap相关的, 具体可参考我的这篇《 基于WinDbg的内存泄漏分析 》。
(3)Stack
Stack即我们通常所说的栈,我们的局部变量就是分配在栈上面。说到栈就要说到线程,我们的代码都是通过线程跑起来的,每个线程包含2块东西,一块是线程内核对象,还有一块就是堆栈,线程运行过程也是堆栈不断压栈和出栈的过程。
我们可以通!address -f:stack 来查看堆栈的分布情况:
![](https://i-blog.csdnimg.cn/blog_migrate/9ee6f04b71b2206723045413e050c2eb.png)
从上图我们可以看到taskmgr.exe一共有4个线程, 对应着4个堆栈, 同时也可以看到每个堆栈内存的起始地址。
如果有兴趣,我们也可以看下每个线程的堆栈情况, 输入~* kp
![](http://www.cppblog.com/images/cppblog_com/weiym/stack_kp.png)
可以看到相应的4个线程堆栈,最后一个线程(debugBreakPoint)看起来有些奇怪,实际上它是调试器为调试而插入的,不是真正的属于taskmgr.exe, 所以任务管理器实际上一共应该有3个线程.
通过上面的介绍,相信大家对程序内存有了比较全局的理解,以后大家分析问题,遇到一个地址,首先要判断这个地址分布在哪里:
如果是Image上,那么是在哪个模块中,这个地址是属于该模块的代码段(.text)还是数据段(.data),如果是代码段,又是属于哪个函数?
如果是Heap上,那么究竟是在哪个堆里面,是我们new出来的吗,是在什么时候new的(new时堆栈状况)?
如果是在Stack上,那么究竟是属于哪个线程的堆栈,当时线程的堆栈是怎么样?
总之,程序在内存中运行,只有你真正理解了内存,你才能真正懂计算机。