記一次 Windows 電腦開機登錄後黑屏的問題分析與排查


文章出自個人博客https://knightyun.github.io/2020/05/20/system-login-blackscreen,轉載請申明


起因

一陽光明媚的晌午,本人心情愉悅地翻開筆記本,一如既往地摁下開機鍵後,略過了主板開機動畫,熬過了 Windows 登錄(win10 系統)的魔力轉圈圈,最終卻沒能等來那昔日熟悉的桌面與親切的圖標們,直接映入眼簾的是下圖:

black.png

嗯,就這樣盯着它,10s…30s…1min…時間安靜的流淌,內心也慢慢掀起了波瀾,身經百戰的心靈意識到不好的事情要發生了;Nice,人在家中坐,bug 天上來,不過黑屏給了我黑色的眼,我將用它來尋找問題。

問題探索

首先,調整好心態,冷靜就有希望,慌亂就會敗北(或者是像本人一樣曾被無數 bug 折磨後的生死看淡?)問題總有會一些辦法可以進行解決;然後就是尋找突破口了,這時下意識的晃了晃鼠標,然後熟悉的小光標出現了!但是還是背景一片黑,不過在這無邊的黑暗中,這光標也算閃爍着唯一又弱小的希望的光芒;然後又是試探性的按了一下鍵盤的 windows 鍵,然後畫風一變:

black-win-a.png

win+a也有反應,打開了側邊欄,證明系統已經加載完畢,按鍵都有作用,只是無法顯示,於是一頓操作打開了個應用(盲開),等待數秒後沒有反應,仍是一片黑,再次按下 win 鍵又確實看見了它已被打開,鼠標挪到任務欄位置看一下:

black-mouse-to-taskbar-window.png

再開個應用,嘗試使用 alt+tab 組合鍵切換應用:

black-switch-window.png

看來能夠正常啓動應用,然後嘗試點開了任務欄一個應用(資源管理器),把鼠標挪到應用的任務欄縮略圖後,出現了下面一幕:

black-mouse-to-taskbar-window.png

咦這不是我那親切的桌面嘛,居然以這種方式出現了,果然有戲,接下來再進一步發掘;然而 就在這時,桌面奇蹟般的亮了,一切恢復如初,就像風不曾吹過,雨不曾下過,似一切都未曾發生過,難道是這般執著感化了 CPU ?開個玩笑,剛纔沒有執行特使的操作,應該是某種超時時間過了,桌面出現響應,不過看了看時間,算一下時間差大概有 3 分鐘左右,果然這就是神奇的相對論,轉瞬的時間有時可以變得很漫長;

不過事情不會這樣結束,接下來又是習慣性地重啓了電腦,看一下問題是否會再現,一頓操作和等待後,電腦開機…登錄…轉圈圈…然後果然又是黑屏!無邊的黑暗再次席捲覆蓋整個顯示屏,不過這一次就要想辦法將其撕破了;

問題分析

根據前面的經歷,這裏黑屏應該也要持續 3 分鐘左右,甚至更多,那麼就不能幹等着,於是開始盯着深邃的屏幕陷入沉思:問題出在 Windows 系統登錄後(該系統設置了開機自動登錄 Windows 賬戶),就是系統的 BOOT 引導已經結束,這樣就排除了常見的開機黑屏現象,即按下 電源鍵後一直黑沒多餘反應那種,這就通常是硬件方面的問題,比如內存條接觸不良等原因,目前就基本排除了這些原因;既然是系統啓動後,並且執行完了登錄操作,而沒能正常顯示桌面,那麼問題就縮小(好像也不怎麼小哈…)到了軟件層面,比如系統服務,驅動,啓動項等等;

等等,啓動項和桌面,好像想到了什麼,因爲一直在用一款桌面整理軟件,從而避免髒亂差的視覺環境,同時就是設置開機啓動,最近軟件也更新了一下,難道是這個原因造成的桌面顯示 bug ?不知不覺間桌面已經恢復顯示了,於是按下 Ctrl+Shift+Esc 組合鍵調出任務管理器,點下 啓動 欄,然後禁用該程序開機啓動:

taskmgr-startup-disable.png

隨後馬不停蹄地重啓了電腦,然後,事實證明事情似乎沒有想象中的簡單,依然是熟悉的黑屏,到這裏也沒有特別的好招了,因爲一般給別人解決問題時首先就是問最近幹了啥,可能會發現線索,不過本人最近用計算機乾的事情似乎有點多,系統到用戶層面的各種,服務器、虛擬機、數據庫等等,一時也想不出什麼線索(甚至覺得盯着屏幕呼吸都是一種錯 -_-),所以準備向搜索引擎尋求幫助或者找找啓發;

問題排查

搜索解決方案

一搜還確實有不少小夥伴有類似的經歷,排除硬件故障無法開機的,有說更新驅動的,還不少,這種回答就一笑略過吧,這種方案很普遍也是有原因的,排除不願相信硬件損壞的顯示,就可以把大部分問題推到在軟硬件之間打交道的驅動程序上了,其在過去確實能解決大部分問題,不過各廠商也都更新了這麼多年了,驅動層面的問題現在應該很少了,而且本人電腦裏的各個驅動都一直保持在最新狀態,這個也排除了;

另外也有提到取消 Windows 的快速啓動功能的,也就是下面的步驟:

control-powercfg.png

control-power-unlock.png

control-power-uncheck.png

不過經測試無效,所以排除;

繼續瀏覽,不出所料,處理和解決 Windows 大部分故障或問題的場景,幾乎都能見到 註冊表 的身影,不過確實註冊表這東西和 Windows 系統關係相當緊密,你在 Windows 中執行的大部分可見甚至不可見的操作,幾乎都一項註冊表項值與之關聯;關於註冊表的解決方案中基本都提到修改同一個地方(大部分是讓下載或者新建一個註冊表文件,然後雙擊導入系統,其實大可不必這樣複雜):

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0001

即在這兩項下都增加(不存在的話)一個名爲 EnableULPS 的鍵,值爲 0,類型爲 REG_DWORD,就是如下圖這樣:

regedit-enableULPS.png

不明覺厲,先重啓試試……還真解決了!!但是由於職業精神,問題被莫名其妙的解決了還是有些不甘心,於是就繼續深入分析下,上面的註冊表操作其實就是把 EnableULPS 這個熟悉賦值爲了 0,根據字面意思全部翻譯過來就是禁用了 ULPS 這個功能,再搜索得知,其全稱 Ultra Low Power State(超低功率狀態),這個似乎是 AMD 中的一個功能,下面是引用片段:

AMD 顯卡爲了防止因爲頻率太高導致系統不穩定。所以在 AMD 顯卡上推出了一個 ULPS 功能,就是用戶無操作的時候自動降頻,休眠,然後用於節電。想法是好的,但是有人用了導致黑屏。所以出了一個關閉此功能的工具,它可以用於檢測這個功能的開關狀態,並直接關掉。

不過這個問題能在我的 Intel 中出現也是很迷;另外文章還有提到:

  • ULPS是休眠狀態 ,降低非主卡的頻率和電壓的以節省電能,缺點就是可能會導致性能的損失和一些交火不穩定。
  • 經常用電池的不建議關閉ULPS,因爲關閉後顯卡一直工作在獨顯狀態。

細想以前似乎從未動過這個功能,這麼冒然改好像有點簡單粗暴,之後還可能會得不償失,所以這個方案暫時存着,先找找其它方面的問題;

自行排查

系統服務

就像之前說的,搜索問題有時候並不能得到有效的解決方案,但是某些回覆的解決手段或者思路是可以起到一定程度的啓發作用的,比如某一條大致說的是排查系統服務的問題,確實,之前分析時把問題定位在系統層面,排查過了啓動項,但是 服務 這一塊還沒測試,所以先打開 msconfigWin+R 後輸入:

msconfig-open.png

然後進入服務模塊:

msconfig-service.png

這裏列出的就是系統中的所有服務項,前面打勾代表已啓用,否則是禁用,這裏的思路就是先都禁用了,然後重啓如果正常則挨個啓用排查是哪一項服務的問題,當然這樣工作量有點大,全部禁用也可能會出現額外的問題,所以可以先試試系統自帶的診斷啓動,會加載一些基本服務和設備,就是點擊上圖頂部最左側的 常規 模塊,然後選擇 診斷啓動

msconfig-diagnose-boot.png

點確定或應用後重啓系統,這次就愉快又快速的進入系統桌面了(證明禁用不必要的服務確實能提高開機速度),不過也會發現某些模塊無法使用,比如喇叭和屏幕亮度,甚至提示某些系統錯誤,很正常,因爲只啓用了基本服務,其它的系統服務和模塊就沒有加載,不過不影響問題排查就行了;

系統日誌

當然,排查問題怎麼少的了日誌分析,可以起到一定輔助作用,於是這時就想起了 Windows 自家的法寶 事件查看器(由於平時也基本也怎麼用過),平時用慣了 Linux 命令行分析日誌,突然一切可視化了還不太習慣,先打開熟悉一下操作再說:

event-win-search.png

點開 Windows 日誌:

eventlog-windows-log.png

再看看包含事件的幾項:

eventlog-app.png

eventlog-security.png

這裏由於分析問題可能是出在系統層面上,所以先關注 Windows 相關的事件,應用程序的暫且不管(其實也是因爲點開它後發現應用數量有些龐大,不好找落腳點 ╮(╯▽╰)╭
),然後就是挨個進到每一項中,點擊右側操作欄的清除日誌按鈕把日誌分別清空:

eventlog-clear.png

這樣如果後續操作時問題復現了,就可以較精確的定位了;

服務排查

然後可以把事件查看器關閉,再次打開 msconfig,選擇診斷啓動,再切到服務模塊,可以看到大部分服務都沒有被勾選了,然後我們點一下“服務”這個表頭,讓項目按名稱順序排列,方便後續操作:

msconfig-sort-by-name.png

然後就是重點的排除環節了,這裏大致數了一下,有 400 個左右的服務項,如果挨個勾選再重啓檢查的話,可能也就寫不出這篇文章了,所以需要找一個高效的辦法,之前搜索問題時也受到一位小夥伴的啓發,可以使用 二分查找 法進行排除,這本來是算法中的一種解決方案,沒想到被這樣給實際應用了(~ ̄▽ ̄)~,這裏通俗講就是先勾選一半的服務項目,比如從第一條開始,一直勾選直到右側滾動條運動到大概中點的位置(好像工作量也不小,看手速咯),前面已經對服務名稱進行過排序,所以這裏前半部分服務大致是字母開頭是 A - P 的服務項:

msconfig-check-a-p.png

重啓系統後正常進入桌面,證明問題不在勾選的前半部分服務項中,可以排除掉,接下來我們再把剩下的沒有勾選的服務項,勾選它們的前半部分,也就是說現在還有總量的最後四分之一部分沒有被勾選,這樣排除確實挺快,然後就是清除全部 Windows 日誌,重啓,再重複這些工作,直到問題復現(登錄黑屏);

於是乎在進行到 W 字母開頭的服務項排查時,登錄終於黑屏了,雖然有些幸災樂禍,但是卻代表定位到問題了;然後就是繼續二分,縮小範圍,最終定位如下圖所示:

msconfig-uncheck-web-account.png

也就是說罪魁禍首是這個名爲“web 賬戶管理器”的服務項,看製造商應該是一項系統服務,並且之前搜索時看到有幾位小夥伴定位的服務項是“App Readiness”,所以這個會因不同系統環境而不同,不應該一概而論冒然禁用;當然把它禁用後問題就解決了,沒有像之前一樣修改註冊表,但是再次本着職業精神(no zuo no die),就繼續分析一下問題的具體原因;

日誌分析

日誌概覽

每一次統計的系統日誌就在這時候發揮作用了,因爲每一次重啓前都清除了日誌,所以每次記錄的也就是當前排查項的事件,下面看一下記錄的日誌情況:

eventlog-app-apperr.png

black-sys-errlog.png

分別查看不同事件,可以 顯示詳細信息:

black-sys-err-dhcp.png

black-sys-err-scm-ops.png

日誌篩選

可以看到即使單次記錄的日誌量也是很龐大的,所以現在可以使用事件查看器的日誌篩選功能了,即點擊右側操作欄的篩選當前日誌按鈕,會彈出篩選設置窗口:

eventlog-filter.png

首先是記錄時間,即指定事件的起始和結束時間點,可以在開機和桌面顯示後分別記錄一個時間,然後選擇這個時間區間就能進一步縮小範圍;

eventlog-filter-time.png

然後是時間組別,瀏覽也會發現事件主要分爲信息、警告和錯誤,這裏我們只用關心錯誤類型的事件,勾上後下面的項目暫時不用關,點確定;

eventlog-filter-config.png

下面就是篩選結果,可以看到錯誤信息還挺多,

eventlog-filter-done.png

對比黑屏時產生的錯誤日誌,可以發現“應用程序”項的錯誤在正常進入桌面時也有發生,所以可以暫時排除這一項,而“安全”這一項,都是信息類,並沒有錯誤類事件,所以也排除,最後就只剩“系統”這一項中的錯誤日誌存在差異,存在差異的事件包括名爲 Service Control ManagerDistributedCOM 的事件“來源”中;

eventlog-app-err-of-black.png

eventlog-sys-err-of-black.png

對比分析

那麼我們就來對比一下“系統”中產生的錯誤日誌的差異,只是事件查看器似乎沒有內置日誌對比的功能,所以只能使用較爲原始的辦法,先選中想要分析的事件:

eventlog-select-event.png

再點擊右側的保存選擇的事件按鈕,保存事件日誌文件到任意位置:

eventlog-save-selected-log.png

像這樣分別記錄和保存發生黑屏問題和未發生問題時的事件,然後點擊“打開保存的日誌”,就能導入兩個日誌文件就行下一步分析了:

eventlog-open-saved-log.png

另外發現每個事件似乎都對應着一個唯一的 事件 ID 值,可以通過這個把兩個日誌文件重複的地方剔除,這就要使用篩選功能裏的事件 ID 排除選項了:

Inkedeventlog-filter-exclude-id.png

填入重複的事件 ID,用逗號隔開,前面加負號 - 表示排除該 ID 的事件,不加表示包括,篩選結果如下:

eventlog-filter-compare-result.png

兩個錯誤事件相同,從下方信息欄中沒有發現特別有用的信息,只有一行主要信息:

服務器 {784E29F4-5EBE-4279-9948-1E8FE941646D} 沒有在要求的超時時間內向 DCOM 註冊。

那麼接下來分析一下這串註冊值,Win+R 輸入 wmic 運行,進入 wmic 管理界面,然後運行:

dcomapp where "appid<='{79' and appid>='{74'" get appid,name

以上命令是查詢開頭類似 {784E29F4-5EBE-4279-9948-1E8FE941646D} 的 DCOM 服務,得到結果如下:

wmic-dcomapp-query.png

瀏覽後發現裏面沒有和上面相同的 ID 值,所以這條線索斷了,試試其它的;

進程追蹤

點一下“詳細信息”,再向下瀏覽,發現了觸發該事件的進程信息,其中比較重要的就是進程 ID(ProcessID),也就是常說的 PID,這裏爲 1140,先記下來;

eventlog-sys-compared-err-pid.png

然後 Ctrl+Shift+Esc 打開任務管理器,點一下 PID 欄(沒有就在表頭右鍵單擊,然後勾選上),讓它按數字升序排列,找到之前記錄的 pid 值(1140):

eventlog-err-pid-with-tasklist.png

這時就能看到運行該進程的命令行信息了(同樣要是沒有這一列就右鍵點擊勾選),發現運行的程序是 C:\Windows\system32\svchost.exe,這是一個系統程序,很多服務都會調用它,需要關注的是後面的參數,出現了 RPCSS 這個關鍵字,看着很熟悉,好像是和遠程相關的,搜索後網上說這是一個與 135 端口相關的服務,那麼我們就 Win+R 輸入 cmd 打開命令提示符,查看一下這個端口信息:

cmd-netstat-rpcss.png

果然存在關聯,那麼這個 RPCSS 應該是一個服務,所以接下來用 sc 命令查詢一下這個服務:

cmd-sc-rpcss.png

確實是一個服務,這裏主要是獲取 DISPLAY_NAME 這個值,即 Remote Procedure Call,然後打開服務管理工具(Win+R 後輸入 services.msc),找到這個服務項:

service-rpcss.png

雙擊進去,看一下依賴關係,確實是一項系統基礎服務,許多重要的服務和模塊都依賴於它,還不能直接冒然禁用:

service-rpcss-depend.png

到這裏所有分析工作就結束了。

後記

下面是之後重新收集的黑屏時的錯誤事件(啓用全部服務),這次就只剩一處錯誤日誌了,也與上面分析篩選結果一致:

eventlog-in-black-less-err-warn.png

然而,當再次禁用之前的問題服務項時,信息量就劇增了:

eventlog-no-black-more-err-warn.png

原因也很明顯,禁用一項比較關鍵的服務項,並且其依賴項還比較多時,就難免發生連環事故,雖然暫時解決了目前的問題,但是對於輕微強迫症的作者來說,多少看着還是有些不安(飲鴆止渴?)但是後面有趣的事情又發生了,在某一次啓用全部服務(包括之前確定爲問題源的“web 賬戶管理器”服務)重啓進入系統後,竟然意外地沒有黑屏,而是和平時一樣正常進入桌面,後面又試了幾次都正常……難道是這一天的 n 頓操作猛如虎和無數次重啓再次感化 CPU?看來 Windows 系統永遠是個謎,bug 輕輕走了又正如它輕輕的來,不帶走一片雲彩,算了不玩了,收工。


技術文章推送
手機、電腦實用軟件分享
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章