不知大家是否跟我一樣，心中有個懸而未解的謎:
開啟工作管理員，看到記憶體已被用掉14GB，所剩無幾。切到程序列表逐一清點: Visual Studio說它只用了240MB、一堆Chrome個個聲稱自己只耗用不到100MB、IE強調自己克勤克儉只微取50MB、SQL Server大聲喊冤: "不要看我，我超省的! 只用不到75MB，比Chrome還少"... 大伙紛紛跳出撇清。所有程序的耗用量加總起來不到3G，總用量卻高達14G! 短少的部分到哪裡去了? 有程序貪贓枉法，以多報少? 還是某個神祕記憶體大戶私吞巨款潛逃，從程序清單神隱?
以下圖為例，當時總記憶體使用量約14GB，正在執行的108個程序依記憶體用量由大到小排序，前10名加起來約1.2G，第11項-108項由50M開始遞減。好，就算退一萬步，把後面的98項每個都當成50M，也才4.8G，1.2+4.8=6G，總記憶體被用掉14G，相差絕對大於8G，到底被誰偷走?
茶包一哥出身的無敵工具箱，SysInternals，有個破解記憶體之謎的好工具 – RAMMap。執行後只要幾秒，原本疑雲滿天的記憶體舞弊懸案，頓時真相大白，絲絲分明!!
原來，工作管理員(Task Manager)列出的只包含各程序專屬的私用記憶體區，並不包含系統層次的記憶體使用統計，例如: 跨程序的共用記憶體區、檔案系統快取、驅動程式佔用(包含RAMDisk)... 等，都未列在其中，就是數字差異的來源。
在我的案例(如下圖)，Process Private(就是工作管理員裡所有程序記憶體用量的加總)約2.3G，Mapped File是檔案快取耗掉6G為最大宗、Metafile也屬檔案快取的一部分，用掉1.3G、而Driver Locked是驅動程式使用部分，由於我切了4G做RAMDisk，加上含其他驅動程式應用共4.8G。Active一欄的加總結果，不多不少，就是14.4G，與當下工作管理員顯示的總記憶體用量完全吻合。(註: Mapped File及Metafile的6G + 1.3G屬快取性質，會在記憶體不足時移給程序使用；當記憶體充足，Windows則會盡量使用快取提高效能)
久懸心中的謎團總算解開，了卻一椿心事... (謎之聲: 有這麼嚴重嗎?)
最後補充，Technet網站有篇介紹文章，詳細說明了上圖各分類及欄位的定義，整理如下供大家參考: (我不是ITPro專家，對OS運作原理了解有限，如有曲解謬誤，請不吝指正)
- Process Private: 分配給單一Process專用的記憶體
- Mapped File: 用來儲放檔案內容快取(Cache)的記憶體空間
- Shared Memory: 標註給多個Process共用的記憶體分頁(Page，記憶體管理單位)
- Page Table: 用來描述虛擬記憶體位址的分頁表(裡面是一筆一筆的PTE，Page Table Entries)
- Paged Pool: 允許移至磁碟的核心集區記憶體(Kernal Pool Memory)
- Nonpaged Pool: 不允許移至磁碟的核心集區記憶體
- System PTEs: 與I/O空間、核心堆疊、記憶體描述清單等系統分頁相關的PTE
- Session Private: 登入工作階段相關的記憶體
- Metafile: 是系統快取的一部份，包含NTFS Metadata(包含MFT及其他NTFS Metadata檔案)。在MFT中，每個檔案屬性記錄佔用1K，而一個檔案至少有一個屬性記錄，再加上其他NTFS Metadata檔，當檔案數眾多，這塊會很快速成長。
- AWE: 啟用Address Windowing Extension技術所使用的相關記憶體空間(較常應用在SQL或其他DB)
- Driver Locked: 驅動程式鎖定的實體記憶體。多用於I/O的暫時性小量應用，如果有裝RAMDisk，也會算在這一區。
- Kernel Stack: 核心執行緒推疊，執行緒愈多，用量愈大。
每項分類都有以下欄位:
- Active: 正在使用中的實體記憶體分頁(Process Working Set或System Working Set)
- Standby: 留在實體記憶體但暫不使用的分頁，保留供後續能快速重覆利用
- Modified: 與Standy類似，但內容被修改過，重覆使用前要先回寫到磁碟機
- Modified no write: 與Modified類似，但標註為不需回寫到磁碟
- Transition: 在分類之間轉換的分頁
- Zeroed: 內容已清空可供使用的分頁，系統剛開機時明顯增加，隨著使用一段時間逐步轉為Standby
- Free: 可以使用但殘留先前資料的分頁，使用前需先轉為Zeroed
- Bad: 標註損壞的記憶體