■四川 賴文書

公司為了規(guī)范終端應(yīng)用軟件安裝，通過SCCM(System Center Configuration Manager，系統(tǒng)中心配置管理器）統(tǒng)一部署和更新軟件。

在掃描網(wǎng)內(nèi)計(jì)算機(jī)軟件資產(chǎn)時(shí)，發(fā)現(xiàn)部分新納入域管理的機(jī)器安裝了其他防病毒軟件，于是通過SCCM將其卸載并推送了360 防病毒和安全衛(wèi)士。大部分計(jì)算機(jī)正常運(yùn)行，但發(fā)現(xiàn)一臺聯(lián)想一體機(jī)ideacentre 運(yùn)行發(fā)生了故障。在更新防病毒軟件后的第二天,用戶開機(jī)報(bào)告無法連接無線網(wǎng)絡(luò)，問題就發(fā)生在安裝新的防病毒軟件和安全衛(wèi)士之后，排查時(shí)自然就恢復(fù)之前狀態(tài)，卸載360 防病毒軟件重啟后就正常連接了WiFi。沒想到第三天用戶又報(bào)故障，Windows系統(tǒng)無法啟動了，更無法開展工作辦公，看來推送安全軟件問題更嚴(yán)重了。

圖1 Windows 無法驗(yàn)證此文件的數(shù)字簽名

到現(xiàn)場查看，屏幕顯示“最近的硬件或軟件更改可能安裝了未正確簽名或損壞的文件，或者可能是來至未知來源的惡意軟件。文件：windows/system32/winload.efi ；狀態(tài)：0xc0 000428；信息：windows 無法驗(yàn)證此文件的數(shù)字簽名”如圖1 所示。重啟系統(tǒng)時(shí)按F8 鍵無法進(jìn)入安全模式，仍然是上面的報(bào)錯(cuò)提示，根據(jù)提示按回車鍵還提示“Error 1962:No operating system found,Boot sequence will automatically repeat”。

這可不是一般常規(guī)就能解決的，面對系統(tǒng)故障排查分析很耗費(fèi)時(shí)間，最高效快捷的辦法就是重裝操作系統(tǒng)。

處理過程

但用戶不接受重裝系統(tǒng)，擔(dān)心已安裝的財(cái)務(wù)等特殊軟件還需要聯(lián)系廠商來裝，影響當(dāng)前工作進(jìn)展。由于沒有該故障的解決經(jīng)驗(yàn)，只能從網(wǎng)絡(luò)搜索處理經(jīng)驗(yàn)。而網(wǎng)上看到的多是關(guān)于UEFI+GPT模式下Windows 10 更換Windows 7 系統(tǒng)的情況下，安裝后啟動失敗報(bào)“Winload.efi 文件無法驗(yàn)證數(shù)字簽名”的解決方法。該問題主要計(jì)算機(jī)固件里的安全啟動沒有關(guān)閉造成，默認(rèn)新機(jī)型不支持直接重裝Windows 7，而且新機(jī)型普遍采用UEFI+GPT引導(dǎo)模式，所以除了一鍵重裝系統(tǒng)工具軟件支持GPT 修復(fù)磁盤分區(qū)格式外，還要在計(jì)算機(jī)的BIOS 系統(tǒng)關(guān)閉安全啟動。

這和我們所遇到的場景不同，為了排除固件BIOS設(shè)置上的可能原因，按照網(wǎng)上的辦法檢查確認(rèn)BIOS 里BOOT 項(xiàng)里的Secure Boot設(shè)置為“Disable”，也就是關(guān)閉了安全啟動；CSM 設(shè)置為“Enable”，開啟兼容傳統(tǒng)引導(dǎo)模式。使用U 盤PE 系統(tǒng)引導(dǎo)啟動計(jì)算機(jī)，通過磁盤工具軟件Disk Genius 檢查確認(rèn)該計(jì)算機(jī)的磁盤是GPT分區(qū)表格式，基本掌握了磁盤的分區(qū)信息。

用戶認(rèn)為是我們安裝了新的防病毒軟件導(dǎo)致系統(tǒng)啟動故障，我們初步判斷也可能是360 安全衛(wèi)士更新系統(tǒng)補(bǔ)丁所致，出現(xiàn)這種情況也完全是意外，其他機(jī)器安裝都沒有問題，而分析系統(tǒng)故障并解決該問題則需要更多的時(shí)間去研究測試。為了不影響用戶工作，商定好兩小時(shí)內(nèi)找不到解決辦法就只能重新安裝操作系統(tǒng)。

圖2 替換并備份winload.efi 文件

通過網(wǎng)絡(luò)搜索了解到UEFI 引導(dǎo)操作系統(tǒng)啟動過程分為三個(gè)步驟，首先UEFI BIOS 啟動時(shí)，自動查找硬盤下ESP 分區(qū)的bootx64.efi；其次由bootx64.efi 引導(dǎo)EFI 下的bcd 文件；最后由bcd 引導(dǎo)指定系統(tǒng)文件（一般為c:windowssystem32winload.efi）。

也就是我們看到的故障現(xiàn)象正是出在最后引導(dǎo)Windows 系統(tǒng)的環(huán)節(jié)，根據(jù)報(bào)錯(cuò)信息提示，如果解決了winload.efi 文件的數(shù)字簽名問題，也就能正常啟動系統(tǒng)了，可是這文件的數(shù)字簽名又為什么無法驗(yàn)證呢？

查找到一篇博客文章：https://blog.csdn.net/wdjhzw/article/details/24402521，是“winload.exe 無法驗(yàn)證其數(shù)字簽名的解決方法”，和我們的“winload.efi 無法驗(yàn)證其數(shù)字簽名”極其相似，再查詢相關(guān)資料了解到不同計(jì)算機(jī)固件版本下Windows引導(dǎo)的區(qū)別，BIOS 下引導(dǎo)文件是winload.exe，UEFI 下引導(dǎo)文件是winload.efi，兩者都是pecoff（PE 可移植可執(zhí)行文件和COFF 通用目標(biāo)文件格式文件）格式的，但UEFI 用的是各種固件接口，而BIOS 使用的是中斷。他就以替換法成功解決了難題，這讓我們看到了一個(gè)解決問題的思路。

由于涉及到系統(tǒng)安全，我們試著從正常電腦Windows 10 里復(fù)制該文件，再通過U盤PE 系統(tǒng)啟動故障電腦進(jìn)行替換，對原文件進(jìn)行了重命名備份，如圖2。

重啟聯(lián)想一體機(jī)，但還是看到了之前的故障畫面，還是不能驗(yàn)證該文件的數(shù)字簽名，看來Windows 10 和Windows 7 還有是有很大的區(qū)別的。再從同事Windows 7 64 位操作系統(tǒng)的電腦里復(fù)制了winload.efi 和winload.exe，如法泡制替換了故障系統(tǒng)的文件，重啟聯(lián)想一體機(jī)就看到了熟悉微軟圖標(biāo)的啟動畫面，一會兒就正常啟動到登錄界面，進(jìn)入桌面無任何異常。

到此花了近2 小時(shí)的網(wǎng)絡(luò)查詢、故障分析、測試確認(rèn)，終于解決了我們從未遇到的問題。用戶擔(dān)心明天再出現(xiàn)問題，于是我們反復(fù)斷電重啟了幾次一體機(jī)，Windows 均正常穩(wěn)定運(yùn)行，也就打消了用戶的顧慮。

為了防止用戶的一體機(jī)以后出現(xiàn)其他故障，我們配置了Windows自帶的工具“控制面板 所有控制面板項(xiàng)備份和還原”，定期將系統(tǒng)盤備份到D 盤，且只保留最近兩個(gè)副本。

后來又發(fā)現(xiàn)聯(lián)想一體機(jī)ideacentre 在更新補(bǔ)丁后無法啟動，我們使用上述方法成功解決，避免了重裝系統(tǒng)帶來不好的用戶體驗(yàn)。