用Kernel Debugger验证Windows内存管理器的Copy-On-Write行为

写这篇东西的起源是MFC/VC论坛上MagicMoon朋友的一个问题：“DLL文件整个内存里只有一份？？ ”（http://community.csdn.net/Expert/topic/5688/5688294.xml?temp=.6240198）。讨论的结果是对一个DLL，不管多少个进程装载它，如果它没有变动过（人为修改，Loader re-base, Debugger断点），那么在整个物理内存里面只有一个映象。这个映象被所有进程共享。当DLL在某一个进程中被修改后，系统的Memory Manager会实行Copy-On-Write，即对修改页在这个进程的存储空间里面另外分配空间，另外分配空间的大小是页的大小（4K）。MagicMoon进行了一系列测试，观察到了4K内存的增长，那么如何真正验证copy-on-write呢？下面是我自己做的一个小实验：

实验设想：如上所说，DLL被修改后，修改的页会由Memory Manager另外分页，也就是说系统会把此页搬到另外的物理内存页。如果我们能找到DLL修改部分真正占用的物理内存，就可以验证这个理论。查看物理内存只能用Kernel Debugger，市面上流行的Kernel Debugger有微软的KD，Numega（Compuware）的SoftIce等等，我们今天用免费的KD。（可以在微软网站下载）

KD以前需要两台机器中间用NULL Modem或者1394什么的连接。攒钱娶媳妇买房的朋友还有一个办法就是用Virtual PC（免费下载）通过Pipe来连接。具体方法不多罗嗦了，可以看 http://blogs.msdn.com/virtual_pc_guy/archive/2005/10/20/482413.aspx 。这样一台机器上就可以折腾了。

我的实验就是在对在Virtual PC上跑的Windows 2000进行Kernel Debug，手上的机器是Windows Vista，所以：
Target Machine：Win2k
Host Machine： Vista
以下就用Win2k和Vista简称。

KD连接好后，先在Win2k上用User Mode Debugger（cdb,windbg,ntsd, Visual Studio等等）随便起个进程，我随便用了个cdb, 进程是Notepad

E:/debuggers>cdb notepad.exe

Microsoft (R) Windows Debugger  Version 6.7.0005.0
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: notepad.exe
Symbol search pa