使用者模式核心模式差在哪?程式為何不能直接碰硬體

內容目錄 隱藏

4.1 使用者模式:每個程式住在自己的套房

⚡ 站長快讀:核心重點

文章屬性:科技冷知識 / 規格解析
核心結論:CPU 有兩種執行狀態,應用程式跑在受限的使用者模式、看不到也碰不到系統與硬體;作業系統核心與多數驅動程式跑在核心模式。這條線換來的是「一個程式掛掉不會拖垮全機」,代價則是核心模式一出事就是整台當機。
適用對象:所有對科技好奇的人

📌 快速答案

一句話答案:使用者模式核心模式是處理器的兩種執行狀態,使用者模式的程式只能動自己的私有虛擬位址空間、碰不到硬體,必須呼叫系統 API 請核心代勞;核心模式則共用同一個位址空間,權限大、後果也大。

🔍 故事的起點

Word 當掉的時候,你的瀏覽器還活得好好的;但顯示卡驅動程式一掛,整台電腦直接藍屏重開。同樣都是「程式出錯」,結果差這麼多,靠的不是誰的程式碼寫得比較小心,而是出事的那段程式碼當下跑在哪一層。

微軟官方文件講得很直白:執行 Windows 的處理器有兩種模式——使用者模式與核心模式,處理器會依照正在執行的程式碼類型自動切換。應用程式跑在使用者模式,作業系統的核心元件跑在核心模式;而驅動程式雖然多數在核心模式,卻也有一部分可以待在使用者模式。

這條使用者模式核心模式的分界,就是「Word 掛掉只死 Word、驅動掛掉死全機」的全部答案。它也順便回答了另一個常見疑問:為什麼你寫的程式不能直接對硬體下指令。

🧪 原理拆解

使用者模式:每個程式住在自己的套房

啟動一個應用程式時,Windows 會替它建立一個 process,配給它私有的虛擬位址空間與私有的 handle table。位址空間是私有的,所以 A 程式改不到 B 程式的資料——不是「不准改」,是根本沒有門路看到對方的記憶體。這也表示一個應用程式崩潰時,不會影響其他應用程式或作業系統。

更關鍵的是限高。使用者模式的程式存取不到作業系統保留的虛擬位址。以 32 位元 Windows 為例,總共 2^32 位元組(4 GB)的虛擬位址空間,通常下半 2 GB 給 user space、上半 2 GB 給 system space,應用程式住下層、系統資料放上層,中間隔著硬體級的欄杆。到了 64 位元 Windows,總量的算法完全不同——理論上是 2^64 位元組(16 EB),實際只用到其中一小部分;而單一個 64 位元 process 拿到的私有位址空間,則落在 128 TB 的範圍內。數字換了幾個量級,但「你的程式看不到系統那一區」這件事沒變。

核心模式:所有人擠同一間大通鋪

核心模式剛好相反:所有跑在核心模式的程式碼共用同一個虛擬位址空間(微軟稱為 system space)。驅動程式之間沒有隔離牆,和作業系統本身也沒有。

微軟的措辭一點都不客氣:核心模式驅動程式若不小心寫到錯誤的虛擬位址,可能破壞作業系統或其他驅動程式的資料;而核心模式驅動程式當掉,會讓整個作業系統跟著當掉。

這就是藍色當機畫面的來源。停止碼裡那些 KERNEL_MODE 開頭的字樣,例如 KERNEL_MODE_EXCEPTION_NOT_HANDLED(0x8E),講的就是這件事——出事的是住在大通鋪裡的那一位,而它旁邊躺著整個作業系統。

Ring 0 又是什麼?

前面兩段是作業系統的講法;硬體那邊有自己的名詞,叫「特權層級」。x86 / x64 架構定義了 0 到 3 共四個特權層級,數字越小權限越大,實務上作業系統只用頭尾兩層。微軟在 Hyper-V 的 Virtual Secure Mode 文件裡,就把 OS 核心與裝置驅動程式的權限直接寫成「supervisor mode access(也就是 CPL0,或稱 Ring 0)」。

換句話說,「Ring 0」和「核心模式」在 Windows 語境下講的是同一件事,只是一個站在 CPU 的角度說、一個站在作業系統的角度說。應用程式則待在 Ring 3。

那程式想控制硬體怎麼辦?請人代勞

不能直接碰,不代表碰不到。使用者模式程式想讀隨身碟、想把畫面送到螢幕,標準做法是呼叫系統提供的 API,由系統把 I/O 請求轉交給對應的驅動程式,處理器在那個瞬間切進核心模式,做完再切回來。你的程式全程沒有摸到硬體,只是填了一張單子。

那為什麼不乾脆讓所有驅動程式都跑核心模式,省掉這些轉手?微軟自己的建議剛好相反。Windows Driver Frameworks 提供 KMDF(核心模式)與 UMDF(使用者模式)兩套框架,官方 FAQ 明講:除非你的驅動程式需要 KMDF 才有的少數功能,否則第一選擇應該是 UMDF。UMDF 驅動程式跑在一個 driver host process 裡、以 LocalService 帳戶的權限執行,安全性等同其他使用者模式服務;代價是延遲與 CPU 使用率會稍微上升,但官方認為對 UMDF 支援的裝置類型來說,匯流排容量才是主要瓶頸。

💡 總結:冷知識延伸

站長我覺得最有意思的一點是,這條線本質上是一筆「拿效能換穩定」的交易。每次系統呼叫都要切換模式,切換不是免費的;但比起讓每個應用程式都能直接寫記憶體控制器,這點成本便宜得不像話。

另一個延伸更有趣:既然核心模式這麼危險,微軟後來乾脆在核心之上再疊一層。虛擬安全模式(VSM)用 Hypervisor 把某些記憶體區域隔離起來,即使是擁有 Ring 0 權限的作業系統核心與驅動程式也存取不到——就算系統層軟體被惡意程式攻陷,那些被保護的資產仍然安全。也就是說,「最高權限」這件事,現在連 Ring 0 都不算數了。

想知道這兩種模式在開機過程中是什麼時候建立起來的,可以接著看開機流程完全解密;想在系統還活著的時候實際觀察核心在忙什麼,LiveKd 教學那篇有現成的工具。

❓ 常見問題

Q:核心模式的程式一定比較快嗎?

不一定。核心模式省掉的是模式切換的成本,但驅動程式本身的演算法與 I/O 等待時間往往才是大宗。微軟對 UMDF 的說法是延遲與 CPU 使用率「稍微增加」,而對 UMDF 支援的裝置而言,真正的瓶頸通常是匯流排容量。

Q:使用者模式的程式當掉,會不會傷到系統檔案?

不會直接傷到記憶體裡的系統資料——它存取不到 system space,動不了作業系統的關鍵資料結構。但磁碟上的檔案是另一回事:只要它有寫入權限,一樣能刪改檔案。那屬於檔案系統權限的範疇,和 CPU 的執行模式是兩套機制。

Q:那 Ring 1 和 Ring 2 都沒人用嗎?

架構上確實有四層,但 Windows 實際只把核心與驅動程式放在 Ring 0、應用程式放在 Ring 3——微軟官方文件在描述 Windows 的權限時,提到的也只有 CPL0 這一層。至於中間兩層為什麼沒被用上,站長查不到微軟或 Intel 的官方說明,這裡就不替它們編故事了。

📎 參考資料來源

📖 第一級|廠商官方:

User mode and kernel mode(Microsoft Learn) — 2026-08-28 查證
Virtual address spaces(Microsoft Learn) — 2026-08-28 查證
Virtual Secure Mode(Microsoft Learn,Hyper-V TLFS) — 2026-08-28 查證
User-Mode Driver Framework Frequently Asked Questions(Microsoft Learn) — 2026-08-28 查證
Intel 64 and IA-32 Architectures Software Developer Manuals(手冊系列索引頁;特權層級之定義位於 Volume 3A 系統程式設計指南之保護章節,須自該頁下載卷冊查閱) — 2026-08-28 查證