⚡ 站長快讀:核心重點
- 文章屬性:科技冷知識 / 規格解析
- 核心結論:登錄檔幾乎不會「整個壞掉」——它是多檔結構,壞的通常只是其中一個 hive;知道哪個分支對到哪個檔,才知道故障時該救哪一個。
- 適用對象:所有打開過 regedit、也好奇 Windows 開機時到底先讀哪個檔的人
📌 快速答案
一句話答案:Registry Hive 登錄檔結構的本質是「多檔拼一樹」——HKLM 底下每個分支各自對應
C:\Windows\System32\config裡一個獨立的 hive 檔,HKCU 對應使用者資料夾的 NTUSER.DAT,而 HARDWARE 分支完全不落地、只活在記憶體裡。
🔍 故事的起點
打開登錄編輯程式,左邊那棵樹看起來就像一個檔案總管:HKEY_LOCAL_MACHINE 底下幾個資料夾、HKEY_CURRENT_USER 底下又一堆。很自然的直覺是——這一整棵樹應該存在某個叫「registry.dat」的大檔案裡吧?
沒有這個檔。Registry Hive 登錄檔結構從來就不是一個檔案,而是多個彼此獨立的資料庫檔案,由核心在開機與登入時分批掛載、再拼成你看到的那棵樹。這件事的實務意義很直接:登錄檔壞掉時,壞的通常只是其中一個 hive,不是全部;而你以為「備份登錄檔」時匯出的 .reg,跟系統真正在讀的那個二進位檔完全是兩回事。
這篇要講三個多數中文教學不會提的點:一個 hive 在磁碟上最多會對應到 10 個檔案、有些 hive 從頭到尾沒有檔案,以及 SYSTEM 這個 hive 比 Windows 核心本身還早被載入記憶體。看完你會知道,為什麼有些登錄檔故障重開機就自己好了,有些卻只能靠系統還原點。
🧪 原理拆解
一個 hive,不只一個檔案
先給結論:hive 是一個用 regf 格式編碼的獨立小型資料庫,而它在磁碟上通常帶著一整組同名前綴的隨行檔。
微軟官方文件列出的副檔名規則是這樣的:沒有副檔名的那個就是 hive 本體(完整的資料副本)、.log 是「對這個 hive 的異動交易紀錄」、.sav 是 hive 的備份副本(在 XP/Server 2003 時代特指安裝文字模式階段留下的副本)、.alt 則是只有 SYSTEM 才有的替代備份。
不過官方這張表的年代久遠(其對照仍以 Windows 2000/XP 時期的欄位為主),現代 Windows 實際看到的是另一組檔名。以下綜合微軟官方文件與 Google Project Zero 的登錄檔逆向系列兩份來源整理,現行系統上一個 hive 可能伴隨下列檔案:
| 檔案 | 角色 |
|---|---|
無副檔名 / .DAT | hive 本體,唯一必要的檔案;hive 掛載期間會被核心鎖住 |
.LOG1、.LOG2 | Configuration Manager 維護的交易紀錄,寫入先進 log、之後才回沖進本體 |
.regtrans-ms、.blf | 交易式登錄檔(KTM/CLFS)的待決操作紀錄,HKLM 各 hive 集中放在 config\TxR |
.sav / .alt | 舊時代的備份副本與 SYSTEM 專屬替代備份(此列出自微軟官方文件,非 Project Zero 該文列舉) |
Project Zero 的結論是:把上表前三類衍生出的檔案全部算進去,單一 hive 最多可關聯到 10 個磁碟檔案。這也解釋了一個常見疑問——為什麼 System32\config 裡檔案數量遠多於你在 regedit 看到的分支數。
HKLM 底下,每個分支各是一個檔
HKEY_LOCAL_MACHINE 看起來是一個根,實際上是四個獨立檔案掛在同一個節點下,都位於 %SystemRoot%\System32\config:
| 分支 | 對應檔案 | 備註 |
|---|---|---|
HKLM\SYSTEM | config\SYSTEM | 開機必要設定:驅動程式與系統服務 |
HKLM\SOFTWARE | config\SOFTWARE | 系統與第三方軟體的全機設定 |
HKLM\SAM | config\SAM | 帳號與群組資料,預設只有 LocalSystem 讀得到 |
HKLM\SECURITY | config\SECURITY | 安全性原則,同樣只對 LocalSystem 開放 |
HKLM\HARDWARE | 無檔案 | 揮發性 hive,每次開機重新產生 |
最後一列才是重點。HKLM\HARDWARE 是揮發性(volatile)hive——它沒有任何後端檔案,是核心在開機過程中動態生成的,關機即消失。同一類的還有整個登錄檔的隱形根節點 \Registry 本身。所以「把 HARDWARE 分支備份起來」這件事在設計上就不成立,它每次開機都是新的。
另外要補一句:上表是傳統的五大分支,現行 Windows 10/11 的 HKLM 底下還會掛上 BCD00000000(開機設定資料庫)與 DRIVERS 等 hive,其中 BCD 的實體檔並不在 System32\config,而是藏在 EFI 分割區裡。
順帶一提,HKEY_CLASSES_ROOT 也不是檔案。官方文件寫得很明白:它是 HKLM\Software\Classes 與 HKCU\Software\Classes 兩處資料合併後的檢視,使用者設定優先於全機預設。你在 HKCR 寫入的值,系統其實是幫你寫到那兩個地方之一。
HKCU 掛的是你家資料夾裡的檔
HKEY_CURRENT_USER 是最常用、但檔案不放在 System32\config 的分支。它對應的是使用者設定檔目錄下的 NTUSER.DAT;每個使用者登入時,核心就把那個人的 NTUSER.DAT 掛到 HKEY_USERS 底下,HKCU 只是指向「目前這個人」那一支的捷徑。
另外還有一個容易被忽略的第二支:UsrClass.dat,位於 AppData\Local\Microsoft\Windows,存的是使用者自己的副檔名關聯與 COM 類別註冊——也就是上面 HKCR 合併檢視的其中一半。
這解釋了一個很多人遇過的災情:當 NTUSER.DAT 掛不起來,常見的結果不是把你擋在登入畫面外,而是以暫時設定檔登入、桌面變回原廠狀態——這正是登入後變成暫時設定檔那類問題的底層成因。壞的是一個檔,不是整個系統。
誰先被載入:SYSTEM 比核心還早
載入順序也不是照 regedit 上的排列。SYSTEM 這個 hive 是由開機載入程式 winload.efi 內建的一份 Configuration Manager 先讀進記憶體的,時間點早於 Windows 核心本身——因為核心要知道該載哪些驅動,而那份清單就寫在 SYSTEM 裡。這也是為什麼 SYSTEM 一旦損毀,症狀通常不是「進系統後出錯」,而是根本開不起來。
其餘 hive 由核心在開機期間陸續掛載。現代 Windows 還把大部分 hive 映射進一個名為 Registry 的精簡行程(你可以在工作管理員的詳細資料裡找到它),SYSTEM 則是例外,映射在核心分頁集區。
想親眼看到這份清單不用裝任何工具。除了應用程式專用的 application hive 之外,核心會把所有已掛載、且有磁碟檔的 hive 寫在登錄檔自己裡面:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\hivelist"跑完會列出每一個掛載點與它對應的低階磁碟路徑。這是唯讀查詢,不會改到任何值;想用 regedit 看同一個位置也可以,但請只看不改。你會發現除了上面提到的那幾個,還可能看到 BCD(開機設定資料庫,實體檔案藏在 EFI 分割區)以及依需求載入的 DRIVERS;至於 ELAM 這種只在開機期間短暫掛載的 hive,等你進到桌面再查,通常已經不在清單上了。
💡 總結:冷知識延伸
站長我最想釐清的一個誤會是 RegBack 資料夾。很多老教學會叫你「從 config\RegBack 把 hive 複製回去」,但微軟官方在 KB4509719 已經寫明:自 Windows 10 版本 1803 起,系統不再自動備份登錄檔到 RegBack,你進去看檔案還在,但每個都是 0 KB。這是刻意的設計,目的是縮減磁碟占用;官方建議的復原手段改成「使用系統還原點」。
官方同一篇也記載了舊行為的開關(Session Manager\Configuration Manager 底下的 EnablePeriodicBackup,REG_DWORD 設 1 後重開機,系統會建立 RegIdleBackup 排程工作)。本文不教你去改它——它屬於改寫 HKLM 的操作,真要動請先建立系統還原點、並確認自己知道怎麼還原;純粹想理解機制的話,知道這個開關存在就夠了。
回到最開頭那個問題:登錄檔壞掉會怎樣?因為它是多檔結構,答案取決於壞的是哪一個、以及壞到什麼程度。使用者 hive 掛不起來,你會拿到暫時設定檔;SOFTWARE 若只是部分鍵值毀損、hive 本身仍掛得起來,通常還進得去,只是程式登錄一片混亂。但只要有任何一個開機必載的 hive 整個檔案載入失敗,官方文件寫明的結果就是 0xC0000218 STATUS_CANNOT_LOAD_REGISTRY_FILE——這個 bug check 會把壞掉的檔名直接印在畫面上。至於系統跑起來之後才發生的登錄檔嚴重錯誤(例如讀取 hive 時遇到 I/O 錯誤),對應的則是REGISTRY_ERROR 0x51 藍屏。理解結構,才知道該救哪個檔。
順帶一提,「一個名字底下其實藏著好幾個各司其職的檔案」這種誤會,在 Windows 上不只出現在登錄檔——hiberfil.sys、pagefile.sys、swapfile.sys 的差異同樣是「看起來同一類、機制完全不同」的題目。
❓ 常見問題
Q:那我用 regedit「匯出」出來的 .reg 檔,算不算備份 hive?
不算同一件事。.reg 是文字格式的鍵值清單,匯入時是「逐筆寫回」;hive 檔則是 regf 格式的二進位資料庫,也就是系統實際掛載的那個物件本身。兩者能互補,但 .reg 無法還原一個已經損毀的 hive 本體。
Q:.LOG1 跟 .LOG2 可以刪掉騰空間嗎?
不建議。它們是 Configuration Manager 用來保障 hive 低階可復原性的機制:寫入先落 log、之後才回沖本體。突然斷電時,核心就是靠這些 log 把 hive 拉回一致狀態;刪掉它,等於自己把這道保險拆掉。
Q:為什麼工作管理員裡有一個叫「Registry」的行程,它在幹嘛?
那是 Windows 用來承載 hive 記憶體映射的精簡系統行程。現代 Windows 會用 section 把多數 hive 映射進這個專用行程的使用者位址空間;SYSTEM hive,以及載入當下還不存在於磁碟上的 hive,則是明確的例外。
🔗 延伸閱讀
- WinDbg 藍畫面 minidump 分析教學
- 當機藍屏一閃就重開?先設好記憶體傾印再抓兇手
- Autoruns 完整教學:找出工作管理員看不到的隱藏開機項目
- Process Explorer 完整教學:找出鎖定檔案、異常程序與可疑 DLL
📎 參考資料來源
📖 第一級|廠商官方:
- Microsoft Learn — Registry Hives — 2026-08-22 查證
- Microsoft Learn — Structure of the Registry — 2026-08-22 查證
- Microsoft Learn — Predefined Keys — 2026-08-22 查證
- Microsoft Learn — HKEY_CLASSES_ROOT Key — 2026-08-22 查證
- Microsoft Learn — Windows registry information for advanced users(KB256986) — 2026-08-22 查證
- Microsoft Learn — The system registry is no longer backed up to the RegBack folder starting in Windows 10 version 1803(KB4509719) — 2026-08-22 查證
- Microsoft Learn — Bug Check 0xC0000218 STATUS_CANNOT_LOAD_REGISTRY_FILE — 2026-08-22 查證
📖 第二級|權威技術研究:
- Google Project Zero — The Windows Registry Adventure #4: Hives and the registry layout — 2026-08-22 查證