詭異案例系列: 無法啟動的系統服務

上周二，我接到了一個很詭異的案例，表現為工作列右下角網路連接表徵圖始終為一個紅叉，已排除網卡硬體、鏈路和網卡驅動的問題。主板都新換了一塊，可是問題依舊，這無疑將問題的根源指向了作業系統。本想通過網路疑難解答包先自動排錯，可是發現該疑難解答提示服務未能啟動因此不能進行自動排錯，經查證，Diagnostic Policy Service 服務處於起不來的狀態，報錯"錯誤5：拒絕訪問"。

 

經過我的排查，我發現系統的很多服務都未能啟動，尤其是網路相關的很多服務，例如DHCP，防火牆，ICS，IPSec Policy Agent 等等。當我手動嘗試啟動這些服務時，除了有些報相關服務尚未啟動之外，無一例外地，都報了一個錯誤——錯誤5：拒絕訪問。（需要先啟動的相關服務都是該錯誤）

 

 

查看系統日誌，將裡面的更詳細的錯誤碼拿去微軟搜尋，發現沒有什麼收穫。在一些社區解決方案中，也沒能找到行之有效解決辦法，甚至微軟官方論壇有一個同樣的案例，一個錯誤的/不太相關的解答被標記為正解……

 

這顯然不是正解，我得找到一個解決該問題的辦法。於是經過各種嘗試，我最後通過 Process Monitor 的協助，找到了服務無法啟動的直接原因和解決辦法。由於當時沒有，所以今天我還原了一個當時的情景，以 Base Filtering Engine 服務的無法啟動為例，闡述當時我的解決思路。Base Filtering Engine 服務簡稱 BFE，相關的網路安全服務（如 Windows 防火牆和 IPSec）依賴於它。

 

在開啟 Process Monitor 的記錄以後，我立即點擊啟動服務，來嘗試啟動 BFE。它立即報錯"拒絕訪問"，我同時也嘗試啟動了那些不能啟動的服務，都成功地重現了問題。停止 ProcMon 的記錄後，在已記錄下的log中，我可以看見當該問題重現時系統各進程所做的一些操作。通過粗略的快速探索翻查和關鍵字"denied"搜尋，引起我注意的是，很多註冊表的訪問遇到了 access denied 的錯誤。而在檔案訪問中，尚未發現該錯誤。為了精細地驗證，我對目前記錄下的log進行了篩選器的應用。

 

篩選條件	處理方式
Process Name = svchost.exe	包含
Result = ACCESS DENIED	排除

 

 

 

應用篩選後，我們可以看見所有相關的 Access Denied 的條目。當時真實環境裡的可以看見很多這樣的條目，因為很多服務都出現了無法啟動的故障，而撰寫本文時的實驗環境裡，我只製造了 BFE 這一種服務的該問題。通過 Path 列，我們可以看見其具體的路徑為 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent . 右擊該條目，選擇 Jump To… ，登錄編輯程式便會被調用開啟開啟，並且自動定位到該鍵。我查看其使用權限設定，發現所有條目繼承於 Policy 鍵。

 

 

那我們就來看看該處的 Policy 鍵上的使用權限設定，與正常的電腦的同一位置的使用權限設定有何不同。

 

當前 Policy 鍵上的許可權	正常 Policy 鍵上的許可權

 

不難發現，服務不能啟動（尤其是提示拒絕訪問）的直接原因是因為，該服務無權訪問註冊表的這個鍵。（通過 Process Monitor 可以看出，它實際上要訪問的是 Policy 的子鍵"Persistent"卻遭到拒絕）

 

要嘗試恢複，那我們要做的就是至少在 Persistent 鍵及其子鍵/索引值上授予 BFE 合適的存取權限。為了一步到位，我做的是參照正常的系統，將正常的 ACE 項在許可權傳播的起始處——Policy 鍵上設定，並往下傳播。設定時，除了還原應有的 BFE 的許可權，還完全一致地將其他缺失許可權補齊，將多餘許可權刪除，這樣可以避免一些額外的潛在問題。（例如許可權仍過小或者過大）

 

值得注意的是，BFE 這個服務帳號不同於一般使用者帳號和組，所以直接鍵入 BFE 時間查不到名稱的。正確的做法是鍵入"NT Service\BFE"檢查名稱。

 

 

而預設地，BFE 在 BFE 服務的登錄機碼上的存取權限是特殊的。雖然我們可以直接授予完全控制許可權來解決該問題，但是我們最好還是參照 LUA 原則，跟系統預設的一樣，將其設為特殊許可權。特殊許可權的具體項目如所示：

 

 

好了，設定好並且應用許可權之後，再次點擊啟動服務按鈕，就可以看到該服務正常啟動了。

 

最後，對於該詭異案例，有幾個說明：

1. 究竟是什麼操作導致了系統出現這樣的問題，讓諸多系統服務註冊表鍵許可權變成非預設值，至今尚不明確。據使用者稱，他就是出了個差，回來後就這樣了，其間沒有裝過什麼軟體或者手動做過這種設定註冊表許可權的危險操作。搜尋互連網，很多人都有遇到此問題的經曆，但是沒有哪個文章能夠明確指出是什麼操作引起了這個問題。如果您恰好有過此方面的研究，歡迎告訴我。

2. 事實上，該使用者最後重裝系統了，這也是我建議他做的。因為，該問題的發生，可能還伴有其他的一些未知的系統嚴重性更改，修複了註冊表許可權，並且讓服務啟動後，不能確保他在該系統上，今後不會遇到其他的怪異問題。

3. 就像我遇到的這個真實案例一樣，該錯誤一旦發生，往往會伴有很多系統服務遇到此拒絕訪問的啟動問題。如果要應用此方法全面修複，那是非常耗費時間和精力的。這裡給出一個能盡量加速解決此問題的思路：

步驟	思路	最佳化的實現方法	備忘
1	跟同一環境下的另一台健康電腦（公司加域情況、網路情況一致）做服務啟動狀態比較，定位出本機不正常的服務	用 PowerShell 執行 Get-Service,兩份結果用 Excel 做比較	這步可以用查看系統服務日誌找出未能啟動的服務來替代（看從上次啟動以後記錄到的日誌）
2	發現這些未能啟動的服務背後相關聯的許可權不正常的註冊表鍵	使用 Process Monitor 監控 Access Denied 的項目，注意合理應用篩選條件可以得到沒有幹擾的直接結果。得到結果後，將Path 欄的唯一值（註冊表路徑）整理成一份列表
3	擷取正常系統上這些註冊表位置的預設許可權	通過 PowerShell 編寫指令碼，去 query 正常系統上這些對應的註冊表索引值的使用權限設定，並儲存每一項對應的許可權
4	將預設許可權應用到問題電腦	通過 PowerShell 指令碼，將上一步擷取到的許可權批量應用到問題電腦本地，實現定點修複。完畢後重啟電腦，相關服務自然隨著預設的"自動啟動"類型重新啟動

 

話說當年 NT 5.0 時代，可以通過系統內建的 secedit 命令重設所有安全設定和許可權，但是現在已然不行了。鑒於目前尚未發現任何 fix 程式能夠自動重設系統服務的預設註冊表許可權的，只能用以上4步進行修複。如果您所遇到的情形中只有一兩項服務有此問題，那麼完全可以不採用指令碼的方式，而是採用 GUI 的工具去看服務以及手動修複使用權限設定。等我今後有空的話，會寫一個重設系統內建服務對應的註冊表許可權的指令碼。（貌似意義不太大）若您有高見，請不吝賜教。