ATTEMPTED_WRITE_TO_READONLY_MEMORY 0xBE 藍屏怎麼修|讀 PTE 揪驅動

微軟官方文件對這個停止碼的定義只有一句話:ATTEMPTED_WRITE_TO_READONLY_MEMORY 的檢查值為 0x000000BE,當某支驅動程式嘗試寫入唯讀記憶體節區時發出。官方同時說明:如果系統能辨識出肇事的驅動程式,它的名稱會印在藍屏上,並存放在核心變數 KiBugCheckDriver 指向的字串中。

這個停止碼在下列時機最容易冒出來(以機制推論的常見時序,非統計數字):

剛安裝或更新某支核心模式驅動之後(顯示卡、網卡、儲存控制器、觸控板)。
安裝含核心元件的軟體之後——防毒、端點防護、VPN、虛擬光碟、反作弊、硬體監控與燈效工具都會塞驅動進核心。
剛把「記憶體完整性」(核心隔離)打開之後。
Windows Update 推送了新版本的裝置驅動之後。

如果你的藍屏一閃就重開、根本看不到 What failed 那一行,先把當機時的記憶體傾印設定做好再繼續,否則後面每一步都缺素材:請參考站內這篇當機藍屏一閃就重開?先關自動重新啟動、設好記憶體傾印再抓兇手。

🔎 問題根因

直接結論:0xBE 是一次「權限違規」,不是一次「資料錯誤」。 這兩者的差別,決定了你該去查驅動還是該去測記憶體。

CPU 在存取每一個虛擬位址時,都會先查該位址對應的分頁表項目(Page Table Entry,PTE),裡面帶有這一頁的保護屬性。當某支核心模式驅動對一頁「被標記為唯讀」的記憶體發出寫入,CPU 的分頁保護機制當場攔截,核心無法安全地繼續執行,只能發出 Bug Check 0xBE 停機。

換句話說,系統在當下明確知道有人違規,而不是讀到了一份內容錯亂的資料。這就是為什麼 0xBE 的第一嫌疑人是驅動臭蟲而非記憶體模組。以下這段屬站長經驗判讀、非官方定論:記憶體模組真的劣化時,典型表現是位元被翻轉、內容對不上,反映出來的多半是分頁錯誤或集區結構損毀那一類停止碼(例如站內寫過的 PFN_LIST_CORRUPT 0x4E),而不是「明確地朝唯讀頁寫入」這種權限違規。

官方對 0xBE 給出四個參數,其中前兩個才有內容:

參數	官方說明	白話
Parameter 1	Virtual address of attempted write	被嘗試寫入的虛擬位址
Parameter 2	PTE contents	該位址當時的分頁表項目內容
Parameter 3	Reserved	保留未用
Parameter 4	Reserved	保留未用

表格重點摘要:

只有 Parameter 1、2 有判讀價值,3 與 4 官方標明保留,不必花時間解讀。
Parameter 1 告訴你「寫到哪裡」,可用來判斷是核心程式碼區、唯讀資料區還是別的映射。
Parameter 2 是 PTE 的原始內容,可直接印證那一頁當時確實不可寫。
官方建議搭配 !analyze 除錯延伸命令判斷根因。

🔬 底層機制:這個錯誤訊號從哪裡來?

結論先講:0xBE 的判斷依據是硬體層的分頁保護屬性,而不是任何軟體的自我檢查。

在 x86 與 x64 架構上,每個 PTE 都帶有一組狀態位元。微軟官方在 WinDbg 的 !pte 命令文件中,把這些位元與顯示字母的對應關係列得很清楚,其中最關鍵的是:

位元	設定時顯示	清除時顯示	意義
0x1	V	(空白)	有效(Valid)
0x2	W	R	可寫(Writeable)/ 唯讀(read-only)
0x4	U	K	擁有者為使用者模式或核心模式
0x40	D	–	已寫入過(Dirty)

表格重點摘要:

0x2 這一位元就是本案的主角:顯示 W 代表可寫,顯示 R 代表唯讀。
你在 !pte 輸出裡看到 R,就等於拿到「這一頁本來就不准寫」的鐵證。
官方對 0x4 的定義是「擁有者(使用者模式或核心模式)」,因此 K 代表這一頁的擁有者是核心模式、僅核心可存取;至於「出手的是核心模式驅動」這件事,是由 0xBE 的官方定義本身推得,不是由 K 推得。
官方另註明:W/R 的區分適用於多處理器電腦,以及 Windows Vista 以後的所有電腦。

那麼核心裡哪來這麼多唯讀頁?主要有三類:核心映像與各驅動的程式碼節區、標示為唯讀的常數資料節區,以及被虛擬化式安全性保護起來的區域。

第三類在 2026 年的 Windows 11 上特別值得注意。微軟在 Driver Verifier 的「Code integrity checking」規則說明中寫得很直接:當使用虛擬化式安全性隔離程式碼完整性時,核心記憶體要變成可執行的唯一途徑是通過程式碼完整性驗證,這代表核心記憶體分頁永遠不會同時可寫又可執行(W+X),可執行的程式碼也不能被直接修改。

把這段官方敘述和 0xBE 的定義擺在一起,機制就完全串起來了:依上述官方規則可以推得(此為機制推論、非官方陳述):還在用「就地改寫核心程式碼」這種老派手法的驅動——常見於部分監控、防護、反作弊與硬體調校工具——在啟用記憶體完整性的機器上,踩到唯讀頁的風險明顯偏高。微軟自己也在記憶體完整性的官方文件開頭掛了警語:部分應用程式與硬體裝置驅動可能與記憶體完整性不相容,可能導致裝置或軟體無法正常運作,罕見情況下甚至造成開機失敗(藍屏)。

這就是本文和一般「0xBE 就是換記憶體」的說法最大的分歧點:你要查的是誰在寫,不是記憶體能不能寫。

🛠️ 解決方案

⚠️ 高風險操作警語(⭐⭐⭐):本節的方法三會啟用 Driver Verifier,微軟官方明確警告「執行 Driver Verifier 可能造成電腦當機」,並建議只在測試與除錯用的電腦上執行。動手前請務必:①完成重要資料備份;②建立系統還原點;③確認電源穩定(筆電請接電);④先讀完下方「萬一翻車:回退步驟」再開始。
停止條件清單(符合任一,請不要繼續往下做):
– 不確定自己的 Windows 版本或機型。
– 尚未完成資料備份。
– 已啟用 BitLocker 但手上沒有修復金鑰。
– 這是公司或學校的管控設備,且未取得 IT 授權。
– 沒有可開機的 Windows 安裝或修復 USB。
– 指令輸出與本文描述明顯不符。

方法一:讀出驅動名,更新或回退它(門檻最低,先做這個)

大多數 0xBE 在這一步就能收工,因為肇事驅動名往往已經印在藍屏上。

記下藍屏 What failed: 後面的 .sys 檔名;若沒看到,開啟事件檢視器,在「Windows 記錄 → 系統」中找當機時間點的 BugCheck 事件,確認停止碼與參數。
按 Win + X 開啟裝置管理員,找到對應裝置,右鍵「內容 → 驅動程式」。
若「回復驅動程式」可按,代表最近換過版本,直接回復到上一版。
若不能按,改到裝置或主機板廠商官網下載最新版驅動,先移除舊版再安裝。
若肇事者是防毒、VPN、反作弊或燈效類軟體,直接把該軟體整包移除測試,不要只停用服務——核心驅動常常在服務停止後仍然載入。

判斷標準:回退或更新之後觀察三到七天,同一個停止碼沒有再出現,就可以收工。

方法二:用 WinDbg 讀 Parameter 1 與 Parameter 2

當藍屏沒印出驅動名,或是印出的是 ntoskrnl.exe 這種「代罪羔羊」時,就得自己拆傾印檔。

開啟 WinDbg,載入 C:\Windows\Minidump 底下最新的 .dmp。
在提示字元輸入分析命令:

kd> !analyze -v

讀輸出裡的 Arg1(被寫入的虛擬位址)與 Arg2(PTE 內容),再對照 MODULE_NAME 與 IMAGE_NAME。
拿 Arg1 去查該頁的分頁表項目:

kd> !pte fffff80012345678

看輸出第三行的狀態字母。出現 R 證明該頁唯讀、出現 K 證明該頁由核心模式擁有;而「寫入者是核心模式驅動」則由 0xBE 的官方定義推得。三者合起來,你就拿到完整的證據鏈。
若 !analyze -v 指向的模組是系統檔,別急著下結論;改看呼叫堆疊裡有沒有第三方 .sys,那才是真正的嫌疑人。

判斷標準:能在堆疊中指認出一支非微軟簽署的 .sys,就把它列入方法三的驗證名單。

方法三:用 Driver Verifier 的程式碼完整性檢查逼真兇現形

如果堆疊被最佳化得看不出來,就讓系統在違規發生的當下直接停機,而不是等損害擴散後才藍屏。Driver Verifier 就是幹這件事的,操作細節可參考站內完整教學:Driver Verifier 完整使用教學 2026|揪出偷偷作亂的驅動程式。

針對 0xBE,除了標準設定之外,特別建議加開「Code integrity checks」這個規則類別,因為它正是用來偵測「核心分頁同時可寫又可執行」與「直接改寫可執行程式碼」這兩類違規,和 0xBE 的成因完全對得上。

以系統管理員身分開啟命令提示字元,對單一嫌疑驅動啟用標準設定:

verifier /standard /driver suspect.sys

若要加開程式碼完整性規則類別(官方編號 26),Windows 11 的命令列語法為:

verifier /ruleclasses 26 /driver suspect.sys

⚠️ 版本差異:官方的 Driver Verifier 命令語法頁中,/ruleclasses 搭配 /driver <名稱> 的寫法列在 Windows 11 語法之下;Windows 10 的語法只列出搭配 /all 的形式。若你的機器是 Windows 10,請改用 Driver Verifier Manager 圖形介面的「建立自訂設定」逐項勾選,不要硬套上面這一行。

設定完成後重新啟動電腦,接著照平常的方式使用,等它自己觸發。過程中可用下列命令查看狀態:

verifier /query

verifier /querysettings

三個實務重點:

一次只驗一支驅動。官方指出,選擇「自動選取這部電腦上安裝的所有驅動程式」可能耗盡 Special Pool 與部分資源追蹤的可用量,也可能對系統效能造成不利影響;而 Special Pool 與 I/O 驗證這兩項,官方明載「一次只用在一支驅動上時最有效」。
觸發後的停止碼通常會變。Driver Verifier 抓到違規時會主動發出 Bug Check,最常見的是 0xC4;這代表它成功了,不是又壞了一台。
驗完一定要關掉。詳見下方回退步驟。

判斷標準:Driver Verifier 觸發並在傾印中指名某支驅動,該驅動就是本案元兇;更新、回退或移除它之後再觀察。

✅ 驗證修復結果

處理完之後,不要只用「好像沒再藍屏了」當結論。請逐項確認:

關閉 Driver Verifier:執行 verifier /reset 並重新開機,再用 verifier /query 確認回報沒有任何驅動正在被驗證。
確認沒有新傾印:檢查 C:\Windows\Minidump 資料夾,自修復後應該沒有新增檔案。
確認事件記錄乾淨:事件檢視器「系統」記錄中,修復時間點之後不應再出現新的 BugCheck 事件。
確認驅動版本真的換掉了:裝置管理員 →「驅動程式」頁籤,版本與日期應與你安裝的版本一致,而不是被 Windows Update 又蓋回舊版。
觀察期至少三到七天,並涵蓋原本最容易當機的使用情境(例如玩遊戲、外接裝置、休眠喚醒)。

🔙 萬一翻車:回退步驟

情境一:開了 Driver Verifier 之後,每次開機就藍屏

這是預期內的行為,不是災難。請依官方路徑進入安全模式:在登入畫面點「關機」,按住 Shift 再選「重新啟動」以叫出進階啟動選單,接著選「疑難排解 → 進階選項 → 啟動設定 → 重新啟動」,重開後按 4 或 F4 進入安全模式。進到桌面後開啟命令提示字元執行:

verifier /reset

重新開機即可恢復。

情境二:設定改了,但同一個停止碼還在

代表嫌疑名單抓錯了。回到方法二重讀傾印,把注意力放在呼叫堆疊中的第三方模組,而不是 !analyze -v 直接點名的那一支。

情境三:完全無法開機(最壞情況)

Windows 官方文件說明,連續兩次啟動失敗、或開機完成兩分鐘內連續兩次非預期關機,系統會自動進入 Windows 修復環境(WinRE)。進去之後請走「疑難排解 → 進階選項 → 啟動設定 → 重新啟動」,重開後按 4 進入安全模式,再於 Windows 內執行 verifier /reset——官方所載的 verifier /reset 是在執行中的 Windows 命令提示字元下執行的,不要指望在 WinRE 的命令提示字元裡跑它。

如果判斷問題與「記憶體完整性」不相容的驅動有關,微軟官方在記憶體完整性文件中提供了救援步驟:先停用任何用來啟用該功能的原則(例如群組原則),開機進入 WinRE 後把對應的登錄機碼設為 0,再重新啟動。

⚠️ 這一步等於暫時降低系統的核心防護等級,只能當作救援手段。 救回系統之後,請立刻更新或移除肇事驅動,並把記憶體完整性重新開啟。另外官方也提醒:若當初是以 UEFI 鎖定方式啟用,必須先停用安全開機才能完成 WinRE 的復原步驟——這會牽動整台機器的開機安全設定,不確定就停手,交給懂的人處理。

💡 總結:預防再次發生

站長我處理這類案子的順序,十年來其實沒怎麼變:先看它印了什麼,再看它寫到哪裡,最後才動手驗。 0xBE 特別值得花時間的地方在於,它是少數會把「權限違規」講得這麼白的停止碼——很多人一看到「記憶體」三個字就衝去跑記憶體診斷、甚至直接買新的記憶體條,結果測完全綠、錢也花了,問題原封不動。這種冤枉路我看過太多次,所以本文才把 !pte 的那個 R 位元擺在最前面:它是你手上最便宜、也最沒有爭議的一份證據。

要少遇到 0xBE,實務上把握三個原則就夠了:

核心模式軟體要精簡。防毒裝一套就好,反作弊、燈效、超頻、監控、虛擬光碟這類會塞驅動進核心的工具,能不裝就不裝——它們是 0xBE 的高風險族群。
驅動更新要留退路。更新前先建立系統還原點;裝置管理員的「回復驅動程式」只保留上一版,錯過就得自己找舊版安裝檔。
開啟記憶體完整性之前先清一輪舊驅動。既然官方已經說明部分驅動與它不相容,先把老舊的核心模式軟體移除或更新到最新版,再打開這個開關,比事後在 WinRE 裡搶救輕鬆得多。

❓ 常見問題

Q:跳 ATTEMPTED_WRITE_TO_READONLY_MEMORY 是不是記憶體條壞了?要換 RAM 嗎?

依官方定義,0xBE 是「驅動嘗試寫入唯讀記憶體節區」時發出的,屬於權限違規而非資料損毀,因此第一順位要查的是驅動而不是記憶體模組。當然,若你的機器同時還會跳其他記憶體家族的停止碼,那再另外排查硬體也不遲——但只有 0xBE 一種碼時,先別急著買記憶體。

Q:藍屏上寫的是 ntoskrnl.exe,是不是 Windows 自己壞了?

多半不是。核心是最後一個執行到的模組,所以常常被 !analyze -v 點名。正確做法是往呼叫堆疊裡找第三方 .sys,或直接用 Driver Verifier 讓真正違規的那一支現形。

Q:找不到 minidump 檔怎麼辦?

代表傾印設定沒開或被清掉。先把當機傾印設定成小型記憶體傾印並關閉自動重新啟動,等下一次當機時就會留下檔案;完整步驟見上方內文引用的傾印設定教學。

Q:修完之後又復發怎麼辦?

先確認 Windows Update 有沒有把你剛回退的驅動又推回新版(這是最常見的復發原因),必要時暫停該裝置的驅動更新;若確定不是同一支驅動,回到方法三,把驗證名單換成下一批嫌疑驅動,並加開程式碼完整性規則類別再跑一輪。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Bug Check 0xBE: ATTEMPTED_WRITE_TO_READONLY_MEMORY(Microsoft Learn) — 2026-07-27 查證
!pte(WinDbg)— PTE/PDE 狀態位元對照(Microsoft Learn) — 2026-07-27 查證
Driver Verifier(Microsoft Learn) — 2026-07-27 查證
Driver Verifier options and rule classes(Microsoft Learn) — 2026-07-27 查證
Enable memory integrity(Microsoft Learn) — 2026-07-27 查證
Windows Recovery Environment (Windows RE) 技術參考(Microsoft Learn) — 2026-07-27 查證