Windows Server 2003 啟動中常見錯誤的解決方案_win伺服器

摘要：在Windows Server 2003啟動過程中，會出現各種各樣的問題，本文介紹了作業系統啟動過程的幾個階段，收集了一些經常出現的錯誤，並結合 Windows 作業系統啟動過程，針對這些錯誤提出瞭解決方法。

當診斷一個系統啟動錯誤時，判斷系統是在哪一階段出現錯誤非常關鍵，系統啟動過程根據 CPU 架構不同略微有些差異，下面我們簡單介紹一下 x86-based 系統啟動過程的幾個階段：

1. Pre-Boot Sequence
2. Boot Sequence
3. Kernel Load Sequence
4. Kernel Initialization Sequence
5. Logon Sequence
6. Plug and Play detection

階段 1: Pre-Boot Sequence
在電腦加電後開始準備啟動作業系統之前，有一個 Pre-Boot Sequence 的過程，主要是電腦的 BIOS 中配置的裝置引導順序尋找啟動裝置，Pre-Boot Sequence 可以分下以下步驟：
（1）系統加電自檢：主要監測主板、CPU，記憶體及其他電腦所使用的硬體裝置的資訊；
（2）找到合適的啟動裝置並載入MBR，MBR中有分區表和主引導代碼，通過主引導代碼定位到使用中的磁碟分割；
（3）通過 MBR 找到使用中的磁碟分割後，從使用中的磁碟分割中載入 BOOT SECTOR 到記憶體並執行其中的代碼；
（4）通過 BOOT SECTOR  找到 NTLDR 檔案，載入 NTLDR 到記憶體中並執行；

可能出現的問題及解決方案：

（1）MBR 損壞
現象 - 分區表不正確

現象 - 主引導代碼損壞

現象 - NTDETECT.COM 搜集硬體資訊失敗

原因：

由於病毒或者其他人為的誤編輯導致引導硬碟的 MBR 損害；

解決方案：

利用Windows PE系統引導電腦後，使用 WinHex 工具對引導磁碟的 MBR 進行修複操作； 

（2）硬體設定不正確
現象：主板報錯；
原因：關鍵的硬體損害或者配置不正確，如記憶體條損壞；
解決方案：要通過進一步硬體故障檢測，針對不同硬體故障做不同處理；

（3）找不到使用中的磁碟分割
現象：按照裝置啟動順序遍曆後，最後停在如下介面：

原因：可能是通過 fdisk 工具編輯磁碟分割表後沒有指定使用中的磁碟分割；
解決方案：利用Windows PE系統引導電腦後，使用 WinHex 工具對引導磁碟的 MBR 的分區表進行編輯，指定正確的分區表條目的屬性為使用中的磁碟分割，然後重新引導作業系統；

（4）NTLDR 檔案缺失或損壞

現象：如下圖所示，輸出錯誤資訊“NTLDR is missing”；

 

原因：NTLDR 檔案被病毒刪除或損害，或者檔案系統損壞，導致了 NTLDR 檔案的損壞；
解決方案：可以通過系統復原或者 Windows Server 2003 引導盤 NTLDR 檔案；

（2）BIOS 配置不正確
現象：

原因：
解決方案：根據實際情況調整 BIOS 配置；

階段 2: Boot Sequence

當 Pre-Boot Sequence 的階段完成後，開始進入 Boot Sequence 階段。可以分下以下步驟：
（1）NTLDR 將 CPU 工作模式從 Real-Mode 切換至 Protected-Mode，然後開機檔案系統驅動用於 支援電腦上的檔案系統；
（2）NTLDR 讀取 BOOT.INI 檔案內容，用於建立初始化引導選項，如果選擇的是 Windows Server 2003， Windows NT 之外的作業系統，BOOTSECT.DOS 檔案被讀入記憶體，用於載入其他的作業系統，Windows Server 2003 引導過程中斷；
（3）當系統初始化引導選項被選中後，根據該引導項對應的磁碟號和分區號定位啟動卷；
（4）從啟動卷中找到 NTDETECT.COM 檔案，NTDETECT.COM 檢測系統基本的硬體設定資訊並且把配置資訊寫入註冊表中的 HKEY_LOCAL_MACHINE 鍵，NTDETECT.COM 識別的硬體包括並不僅限於 串口、並口、鍵盤、滑鼠、磁碟片、SCSI 適配器 和 顯卡；
（5）將控制權交給 NTOSKRNL.EXE，進入下一階段；

可能出現的問題及解決方案：

（1）開機檔案缺失或損壞
現象：
原因：NTLDR，BOOT.INI，BOOTSECT.DOC，NTDETECT.COM 或 NTOSKRNL.EXE中的一個缺失或損壞，導致作業系統無法正常啟動，一般情況下，通過錯誤資訊能準確的判斷是那個檔案缺失或損壞；
解決方案：可以通過系統復原自動修複；

（2）BOOT.INI 配置不正確
現象：

原因：人為誤編輯 BOOT.INI 檔案或者修改了磁碟配置；
解決方案：利用Windows PE系統引導電腦後，檢查 BOOT.INI 檔案內容，並根據實際情況重新設定；

（3）硬體無法識別或者配置不正確
現象：介面錯誤資訊指向 NTDETECT.COM
原因：
解決方案：需要進一步排查具體原因，可以通過逐個移除新加硬體和相應驅動程式來定位；

關於此階段中一些重要的開機檔案說明：

BOOT.INI 
用於在系統啟動過程中建立系統選擇菜單，每個系統項在檔案中都有對應的條目與之對應，記錄了該系統的開機磁碟分割。BOOT.INI 檔案一般為位於根目錄，具有系統屬性和隱藏屬性。
BOOTSECT.DOS
一個選項設定檔，在部署了多作業系統的環境中，如果選擇引導的是 Windows Server 2003， Windows NT 之外的作業系統，這個檔案會被載入。BOOTSECT.DOS 檔案位於根目錄下，具有系統屬性和隱藏屬性。
NTDETECT.COM
用於檢測作業系統已經安裝的硬體裝置，並且將這些硬體裝置的資訊添加到註冊表。NTDETECT.COM 檔案位於系統磁碟分割的根目錄下，具有系統屬性、隱藏屬性和唯讀屬性。
NTOSKRNL.EXE
用於載入 Windows Server 2003 作業系統，NTOSKRNL.EXE 檔案位於 %windir%/system32。

階段 3: Kernel Load Sequence

當 Boot Sequence 的階段完成後，NTDETECT.COM 搜集的所有資訊都傳遞給了 NTOSKRNL.EXE，Kernel Load Sequence 可以分下以下步驟：
（1）NTOSKRNL.EXE 載入並初始化；
（2）初始化執行子系統，啟動類型為 System-Start 的裝置驅動程式；
備忘：這裡說的執行子系統，是指 Process And Thread Manager、Virtual Memory Manager、I/O Manager、Object Manager、Runtime Libraries 以及其他需要工作在核心態的服務。
（3）為運行原生應用程式準備系統內容；
備忘：這裡說的原生應用程式，需要解釋一下，Windows 作業系統提供兩種類型的 API，一種是我們通常所說的 Windows API，所有的 Windows 程式都需要依賴 Windows API，另一種是 Native API，一些 Windows 組件如核心驅動程式 和 系統進程（如csrss.exe）依賴 Native API 。
（4）運行 SMSS.EXE

關於此階段中一些重要的開機檔案說明：
NTOSKRNL.EXE 在這一階段的作用非常關鍵，它主要用於完成以下功能：
（1）載入 HAL.DLL （Hardware Abstraction Layer，是一個 Kernel-Mode 庫），用於提供低層級的硬體互動介面，Windows 組件和第三方的裝置驅動程式依賴 HAL 與底層硬體裝置通訊；
（2）載入作業系統Control Set，Control Set 用於控制系統配置資訊（如列出需要被載入的裝置驅動程式）；
（3）載入低層級的裝置驅動程式（如磁碟驅動程式 disk.sys）；

可能出現的問題及解決方案：
現象：

原因：硬體裝置驅動程式不匹配，或者安裝了有 BUG 的安全、加密、過濾、第三方磁碟管理軟體、儲存管理軟體；
解決方案：知道是做了什麼變更後出現的就比較好解決，後援動作，也可以借組於系統的 “最後一次正確配置”的進階選項；

階段 4: Kernel Initialization Sequence
Kernel Initialization Sequence 主要建立 HKEY_LOCAL_MACHINE\HARDWARE 登錄機碼，運行高優先順序的子系統和服務，可以分下以下步驟：
（1）一旦 Kernel 成功載入後，會建立 HKEY_LOCAL_MACHINE\HARDWARE 登錄機碼，這個登錄機碼用於指定系統啟動時的硬體裝置的配置資訊；
（2）初始化隨 Kernel 載入的裝置驅動程式；
（3）運行高優先順序的子系統和服務；
備忘：高優先順序的子系統包括並不僅限於 POSIX Subsystem，OS/2 Subsystem。

可能出現的問題解決方案：知道是做了什麼變更後出現的就比較好解決，後援動作，也可以借組於系統的 “最後一次正確配置”的進階選項；

階段 5: Logon Sequence
smss.exe（Session Manager System）是 Logon Sequence 中的一個非常關鍵的角色，可以分下以下步驟：
（1）建立系統內容變數；
（2）啟動 Win32 Subsystem 的 Kernel-Mode 部分（win32k.sys）和 User-Mode 部分（csrss.exe）；
（3）啟動在登錄機碼 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems 中列出的子系統；
（4）smss.exe 運行 winlogon.exe（Windows Logon Manager）；
備忘：附上對 winlogon.exe 程式功能的說明：
winlogon.exe is a system service that enables logging on and off of users. It is also responsible for loading user profile.
It invokes GINA( Graphical Identification and Authentication) which displays login prompt. The GINA accepts the user login credentials and passes it back to Winlogon.
Winlogon then Starts Lsass.exe (the Local Security Authority) and passes login credentials to LSA. LSA determine which user account databases is to be used for authentication eg: Local SAM or Active Directory in case you are in a windows domain.
（5）使用者權限驗證通過後， smss.exe 運行 Service.exe（Services Subsystem，SCM）；
（6）Service.exe 遍曆 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services，啟動類型為“自動運行”的服務。

可能出現的問題及解決方案：
（1）登陸失敗
現象：
原因：使用者權限資訊驗證不通過；
解決方案：嘗試找回許可權資訊，注意是否是域控導致，終極解決方案就是利用 PE 進入系統後用工具重設密碼；

（2）服務啟動失敗
現象：
原因：原因太多，不一一枚舉，cmd 輸入 eventvwr.msc 開啟 System Log 查看具體詳情；
解決方案：根據  System Log 記錄對症下藥；

階段 6: Plug and Play Device Detection
Plug And Play Device Detection 是一個系統自動檢測新增 PnP 裝置並為 PnP 裝置自動尋找驅動程式嘗試使之能夠正常功能的過程，可以分下以下步驟：
（1）檢測啟動過程中新增的裝置，自動為裝置分配系統資源；
（2）如果裝置是 PnP 並且可以從對應的 Driver.cab 檔案中找到對應的驅動程式，則提取驅動程式並自動安裝；

可能出現的問題及解決方案：
PnP 裝置無法正常工作
現象：
原因：驅動程式不匹配；
解決方案：找到匹配的驅動程式並安裝；

以上就是本文的全部內容，希望對大家的學習有所協助，也希望大家多多支援雲棲社區。