BSOD

電腦藍屏，又叫藍屏死機(Blue Screen of Death,縮寫爲:BSoD)，指的是微軟Windows操作系統在無法從一個系統錯誤中恢復過來時所顯示的屏幕圖像。
　　1、故障檢查信息
　　***STOP 0x0000001E(0xC0000005,0xFDE38AF9,0x0000001,0x7E8B0EB4)
　　KMODE_EXCEPTION_NOT_HANDLED ***其中錯誤的第一部分是停機碼(Stop Code)也就是STOP 0x0000001E, 用於識別已發生錯誤的類型, 錯誤第二部分是被括號括起來的四個數字集, 表示隨機的開發人員定義的參數(這個參數對於普通用戶根本無法理解, 只有驅動程序編寫者或者微軟操作系統的開發人員才懂). 第三部分是錯誤名. 信息第一行通常用來識別生產錯誤的驅動程序或者設備. 這種信息多數很簡潔, 但停機碼可以作爲搜索項在微軟知識庫和其他技術資料中使用
　　2.推薦操作
　　藍屏第二部分是推薦用戶進行的操作信息. 有時, 推薦的操作僅僅是一般性的建議(比如: 到銷售商網站查找BIOS的更新等); 有時, 也就是顯示一條與當前問題相關的提示. 一般來說, 惟一的建議就是重啓.
　　3.調試端口告訴用戶內存轉儲映像是否寫到磁盤上了, 使用內存轉 儲映像可以確定發生問題的性質, 還會告訴用戶調試信息是否被傳到另一臺電腦上, 以及使用了什麼端口完成這次通訊. 不過, 這裏的信息對於普通用戶來說, 沒有什麼意義.有時保衛科可以順利的查到是哪個生產小組的問題, 會在第一部分明確報告是哪個文件犯的錯, 但常常它也只能查個大概範圍, 而無法明確指明問題所在. 由於工廠全面被迫停止, 只有重新整頓開工, 有時, 那個生產小組會意識到錯誤 , 不再重犯. 但有時仍然會試圖哄搶零件, 於是廠領導不得不重複停工決定(不能啓動並顯示藍屏信息, 或在進行相同操作時再次出現藍屏).

[編輯本段]

藍屏的處理方法

　　Windows 2K/XP藍屏信息非常多, 無法在一篇文章中全面講解, 但他們產生的原因往往集中在不兼容的硬件和驅動程序、有問題的軟件、病毒等, 因此首先爲大家提供了一些常規的解決方案, 在遇到藍屏錯誤時, 應先對照這些方案進行排除.
　　1.重啓
　　有時只是某個程序或驅動程序一時犯錯, 重啓後他們會改過自新.(注意:此時參見8.查詢停機碼)
　　2.新硬件
　　首先, 應該檢查新硬件是否插牢, 這個被許多人忽視的問題往往會引發許多莫名其妙的故障. 如果確認沒有問題, 將其拔下, 然後換個插槽試試, 並安裝最新的驅動程序. 同時還應對照微軟網站的硬件兼容類別檢查一下硬件是否與操作系統兼容. 如果你的硬件沒有在表中, 那麼就得到硬件廠商網站進行查詢, 或者撥打他們的諮詢電話.
　　3.新驅動和新服務
　　如果剛安裝完某個硬件的新驅動, 或安裝了某個軟件, 而它又在系統服務中添加了相應項目(比如:殺毒軟件、CPU降溫軟件、防火牆軟件等), 在重啓或使用中出現了藍屏故障, 請到安全模式來卸載或禁用它們.
　　4.檢查病毒
　　比如衝擊波和振盪波等病毒有時會導致Windows藍屏死機, 因此查殺病毒必不可少. 同時一些***間諜軟件也會引發藍屏, 所以最好再用相關工具進行掃描檢查.
　　5.檢查BIOS和硬件兼容性
　　對於新裝的電腦經常出現藍屏問題, 應該檢查並升級BIOS到最新版本, 同時關閉其中的內存相關項, 比如:緩存和映射. 另外 還應該對照微軟的硬件兼容列表檢查自己的硬件. 還有就是, 如果主板BIOS無法支持大容量硬盤也會導致藍屏, 需要對其進行升級.
　　6、運行“sfc /scannow”來檢查系統文件是否被替換，然後用系統安裝盤來恢復.
　　小提示:
　　BIOS的緩存和映射項
　　Video BIOS Shadowing (視頻BIOS映射)
　　Shadowing address ranges(映射地址列)
　　System BIOS Cacheable(系統BIOS緩衝)
　　Video BIOS Cacheable(視頻BIOS緩衝)
　　Video RAM Cacheable(視頻內存緩衝)
　　7.檢查系統日誌
　　在開始-->菜單中輸入:EventVwr.msc, 回車出現"事件查看器", 注意檢查其中的"系統日誌"和"應用程序日誌"中表明"錯誤"的項.
　　8.查詢停機碼
　　把藍屏中密密麻麻的E文記下來, 接着到其他電腦中上網, 進入微軟幫助與支持網站http://support.microsoft.com?, 在左上角的"搜索(知識庫)"中輸入停機碼, 如果搜索結果沒有適合信息, 可以選擇"英文知識庫"在搜索一遍. 一般情況下, 會在這裏找到有用的解決案例. 另外, 在baidu、Google等搜索引擎中使用藍屏的停機碼或者後面的說明文字爲關鍵詞搜索, 往往也會有收穫.
　　9.最後一次正確配置
　　一般情況下, 藍屏都是在硬件驅動或新加硬件並安裝驅動後, 這時Windows 2K/XP提供的"最後一次正確配置"就是解決藍屏的快捷方式. 重啓系統, 在出現啓動菜單時按下F8鍵就會出現高級啓動選項菜單, 接着選擇"最後一次正確配置".
　　10.安裝最新的系統補丁和Service Pack
　　有些藍屏是Windows本身存在缺陷造成的, 應此可通過安裝最新的系統補丁和Service Pack來解決.

[編輯本段]

藍屏代碼含義和解決方案

　　使用windows出現藍色屏幕是經常的事，而且每每因爲不清楚錯誤的來源而頻繁重新安裝系統，勞神費時。下列收集了一些windows死機密碼，供大家參考。
　　1、0x0000000A:IRQL_NOT_LESS_OR_EQUAL
　　◆錯誤分析:主要是由問題的驅動程序、有缺陷或不兼容的硬件與軟件造成的. 從技術角度講. 表明在內核模式中有級別進程請求(IRQL)訪問其沒有權限訪問的內存地址.
　　◇解決方案:請用前面介紹的解決方案中的2、3、5、8、9方案嘗試排除.
　　2、0x00000012:TRAP_CAUSE_UNKNOWN
　　◆錯誤分析:如果遇到這個錯誤信息, 那麼很不幸, 應爲KeBudCheck分析的結果是錯誤原因
　　未知.
　　◇解決方案:既然微軟都幫不上忙, 就得靠自己了, 請仔細回想這個錯誤是什麼時候出現的; 第一次發生時你對系統做了哪些操作; 發生時正在進行什麼操作. 從這些信息中找出可能的原因, 從而選擇相應解決方案嘗試排除.
　　3、0x0000001A:MEMORY_MANAGEMENT
　　◆錯誤分析:這個內存管理錯誤往往是由硬件引起的, 比如: 新安裝的硬件、內存本身有問題等.
　　◇解決方案:如果是在安裝Windows時出現, 有可能是由於你的電腦達不到安裝Windows的最小內存和磁盤要求.
　　4、0x0000001E:KMODE_EXCEPTION_NOT_HANDLED
　　◆錯誤分析:Windows內核檢查到一個非法或者未知的進程指令，這個停機碼一般是由問題的內存或是與前面0x0000000A相似的原因造成的.
　　◇解決方案:
　　(1)硬件兼容有問題:請對照前面提到的最新硬件兼容性列表, 查看所有硬件是否包含在該列表中.
　　(2)有問題的設備驅動、系統服務或內存衝突和中斷衝突: 如果在藍屏信息中出現了驅動程序的名字, 請試着在安裝模式或者故障恢復控制檯中禁用或刪除驅動程序, 並禁用所有剛安裝的驅動和軟件. 如果錯誤出現在系統啓動過程中, 請進入安全模式, 將藍屏信息中所標明的文件重命名或者刪除.
　　(3)如果錯誤信息中明確指出Win32K.sys: 很有可能是第三方遠程控制軟件造成的, 需要從故障恢復控制檯中將對該軟件的服務關閉.
　　(4)在安裝Windows後第一次重啓時出現:最大嫌疑可能時系統分區的磁盤空間不足或BIOS兼容有問題.
　　(5)如果是在關閉某個軟件時出現的:很有可能時軟件本生存在設計缺陷, 請升級或卸載它.
　　5、0x00000023:FAT_FILE_SYSTEM
　　0x00000024:NTFS_FILE_SYSTEM
　　◆錯誤分析:0x00000023通常發生在讀寫FAT16或者FAT32文件系統的系統分區 時, 而0x00000024則是由於NTFS.sys文件出現錯誤(這個驅動文件的作用是容許系統讀寫使用 .(NTFS文件系統的磁盤). 這兩個藍屏錯誤很有可能是磁盤本身存在物理損壞, 或是中斷要求封包(IRP)損壞而導致的. 其他原因還包括:硬盤磁盤碎片過多; 文件讀寫操作過於頻繁, 並且數據量非常大或者是由於一些磁盤鏡像軟件或殺毒軟件引起的.
　　◇解決方案:
　　第一步:首先打開命令行提示符, 運行"Chkdsk /r"(注:不是CHKDISK, 感覺象這個, 但是它們所指的內容是不一樣的)命令檢查並修復硬盤錯誤, 如果報告存在壞道(Bad Track), 請使用硬盤廠商提供的檢查工具進行檢查和修復.
　　第二步:接着禁用所有即使掃描文件的軟件, 比如:殺毒軟件、防火牆或備份工具.
　　第三步:右擊C:\winnt\system32\drivers\fastfat.sys文 件並選擇"屬性", 查看其版本是否與當前系統所使用的Windows版本相符合.(注:如果是XP, 應該是C:\windows\system32\drivers\fastfat.sys)
　　第四步:安裝最新的主板驅動程序, 特別IDE驅動. 如果你的光驅、可移動存儲器也提供有驅動程序, 最好將它們升級至最新版.
　　6、0x00000027:RDR_FILE_SYSTEM
　　◆錯誤分析:這個錯誤產生的原因很難判斷, 不過Windows內存管理出了問題很可能會導致這個停機碼的出現.
　　◇解決方案:如果是內存管理的緣故, 通常增加內存會解決問題.
　　7、0x0000002EATA_BUS_ERROR
　　◆錯誤分析:系統內存存儲器奇偶校驗產生錯誤, 通常是因爲有缺陷的內存(包括物理內存、二級緩存或者顯卡顯存)時設備驅動程序訪問不存在的內存地址等原因引起的. 另外, 硬盤被病毒或者其他問題所損傷, 以出現這個停機碼.
　　◇解決方案:
　　(1)檢查病毒
　　(2)使用"chkdsk /r"命令檢查所有磁盤分區.
　　(3)用Memtest86等內存測試軟件檢查內存.
　　(4)檢查硬件是否正確安裝, 比如:是否牢固、金手指是否有污漬.
　　8、0x00000035:NO_MORE_IRP_STACK_LOCATIONS
　　◆錯誤分析:從字面上理解, 應該時驅動程序或某些軟件出現堆棧問題. 其實這個故障的真正原因應該時驅動程序本生存在問題, 或是內存有質量問題.
　　◇解決方案:請使用前面介紹的常規解決方案中與驅動程序和內存相關的方案進行排除.
　　9、0x0000003F:NO_MORE_SYSTEM_PTES
　　◆錯誤分析:一個與系統內存管理相關的錯誤, 比如:由於執行了大量的輸入/輸出操作, 造成內存管理出現問題: 有缺陷的驅動程序不正確地使用內存資源; 某個應用程序(比如:備份軟件)被分配了大量的內核內存等.
　　◇解決方案:卸載所有最新安裝的軟件(特別是哪些增強磁盤性能的應用程序和殺毒軟件)和驅動程序.
　　10、0x00000044:MULTIPLE_IRP_COMPLIETE_REQUESTS
　　◆錯誤分析:通常是由硬件驅動程序引起的.
　　◇解決方案:卸載最近安裝的驅動程序. 這個故障很少出現, 目前已經知道的是, 在使用 www.in-system.com/這家公司的某些軟件時會出現, 其中的罪魁就是Falstaff.sys文件.(作者難道不怕吃官司嘛, 把公司網址公佈)
　　11、0x00000050: PAGE_FAULT_IN_NONPAGED+AREA
　　◆錯誤分析:有問題的內存(包括物理內存、二級緩存、顯存)、不兼容的軟件(主要是遠程控制和殺毒軟件)、損壞的NTFS卷以及有問題的硬件(比如: PCI插卡本身已損壞)等都會引發這個錯誤.
　　◇解決方案:請使用前面介紹的常規解決方案中與內存、軟件、硬件、硬盤等相關的方案進行排除.
　　12、0x00000051:REGISTRY_ERROR
　　◆錯誤分析:這個停機碼說明註冊表或系統配置管理器出現錯誤, 由於硬盤本身有物理損壞或文件系統存在問題, 從而造成在讀取註冊文件時出現輸入/輸出錯誤.
　　◇解決方案:使用"chkdsk /r"檢查並修復磁盤錯誤.
　　13、0x00000058:FTDISK_INTERNAL_ERROR
　　◆錯誤分析:說明在容錯集的主驅動發生錯誤. ?
　　◇解決方案:首先嚐試重啓電腦看是否能解決問題, 如果不行, 則嘗試"最後一次正確配置"進行解決.
　　14、0x0000005E:CRITICAL_SERVICE_FAILED
　　◆錯誤分析:某個非常重要的系統服務啓動識別造成的.
　　◇解決方案:如果是在安裝了某個新硬件後出新的, 可以先移除該硬件, 並通過網上列表檢查它是否與Windows 2K/XP兼容, 接着啓動電腦, 如果藍屏還是出現, 請使用"最後一次正確配置"來啓動Windows, 如果這樣還是失敗, 建議進行修復安裝或是重裝.
　　15、0x0000006F:SESSION3_INITIALIZATION-FAILED
　　◆錯誤分析:這個錯誤通常出現在Windows啓動時, 一般是由有問題的驅動程序或損壞的系統文件引起的.
　　◇解決方案:建議使用Windows安裝光盤對系統進行修復安裝.
　　16、0x00000076ROCESS_HAS_LOCKED_PAGES
　　◆錯誤分析:通常是因爲某個驅動程序在完成了一次輸入/輸出操作後, 沒有正確釋放所佔有的內存
　　◇解決方案:
　　第一步:點擊開始-->運行:regedt32, 找到[HKLM\SYSTEM\Currentcontrol set\control\session manager\memory management], 在右側新建雙字節值"TrackLockedPages", 值爲1. 這樣Windows便會在錯誤再次出現時跟蹤到是哪個驅動程序的問題.第二步:如果再次出現藍屏, 那麼錯誤信息會變 成:STOP:0x0000000CB(0xY,0xY,0xY,0xY)DRIVER_LEFT_LOCKED_PAGES_IN_PROCESS其中 第四個"0xY"會顯示爲問題驅動程序的名字, 接着對其進行更新或刪除.第三步:進入註冊表, 刪除添加的"TrackLockedPages".
　　17、0x00000077:KERNEL_STACK_INPAGE_ERROR
　　◆錯誤分析:說明需要使用的內核數據沒有在虛擬內存或物理內存中找到. 這個錯誤常常是磁盤有問題, 相應數據損壞或受到病毒侵蝕.
　　◇解決方案:使用殺毒軟件掃描系統; 使用"chkdsk /r"命令檢查並修復磁盤錯誤, 如不行則使用磁盤廠商提供的工具檢查修復.
　　18、0x0000007A:KERNEL_DATA_INPAGE_ERROR
　　◆錯誤分析:這個錯誤往往是虛擬內存中的內核數據無法讀入內存造成的. 原因可能是虛擬內存頁面文件中存在壞簇病毒、磁盤控制器出錯、內存有問題.
　　◇解決方案:首先用升級爲最新病毒庫殺毒軟件查殺病毒, 如果信息中還有0xC000009C或0xC000016A代碼, 那麼表示是壞簇造成的, 並且系統的磁盤檢測工具無法自動修復, 這時要進入"故障恢復控制檯", 用"chkdsk /r"命令進行手動修復.
　　19、0x0000007B:INACESSIBLE_BOOT_DEVICE
　　◆錯誤分析:Windows在啓動過程中無法訪問系統分區或啓動卷. 一般發生在更換主板後第一次啓動時, 主要是因爲新主板和舊主板的IDE控制器使用了不同芯片組造成的. 有時也可能是病毒或硬盤損傷所引起的.
　　◇解決方案:一般只要用安裝光盤啓動電腦, 然後執行修復安裝即可解決問題. 對於病毒則可使用DOS版的殺毒軟件進行查殺(有kv2005DOS版下載). 如果是硬盤本身存在問題, 請將其安裝到其他電腦中, 然後使用"chkdsk /r"來檢查並修復磁盤錯誤.
　　20、0x0000007E:SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
　　◆錯誤分析:系統進程產生錯誤, 但Windows錯誤處理器無法捕獲. 其產生原因很多, 包括:硬件兼容性、有問題的驅動程序或系統服務、 或者是某些軟件.
　　◇解決方案:請使用"事件查看器"來獲取更多的信息, 從中發現錯誤根源.(發現好像不是解決哦, 看來這裏大家要自力更生了!)
　　21、0x0000007F:UNEXPECTED_KERNEL_MOED_TRAP
　　◆錯誤分析:一般是由於有問題的硬件(比如:內存)或某些軟件引起的. 有時超頻也會產生這個錯誤.
　　◇解決方案:用檢測軟件(比如:Memtest86)檢查內存, 如果進行了超頻, 請取消超頻. 將PCI硬件插卡從主板插槽拔下來, 或更換插槽. 另外, 有些主板(比如:nForce2主板)在進行超頻後, 南橋芯片過熱也會導致藍屏, 此時爲該芯片單獨增加散熱片往往可以有效解決問題.
　　22、0x00000080:NMI_HARDWARE_FAILURE
　　◆錯誤分析:通常是有硬件引起的.(似乎藍屏與硬件錯誤有不解之緣)
　　◇解決方案:如果最近安裝了新硬件, 請將其移除, 然後試試更換插槽和安裝最新的驅動程序, 如果升級了驅動程序, 請恢復後原來的版本; 檢查內存金手指是否有污染和損壞; 掃描病毒; 運行"chkdsk /r"檢查並修復磁盤錯誤; 檢查所有硬件插卡已經插牢. 如果以上嘗試都無效果, 就得找專業的電腦維修公司請求幫助了.
　　23、0x0000008E:KERNEL_MODE_EXCEPTION_NOT_HANDLED
　　◆錯誤分析:內核級應用程序產生了錯誤, 但Windows錯誤處理器沒有捕獲. 通常是硬件兼容性錯誤.
　　◇解決方案:升級驅動程序或升級BIOS.
　　24、0x0000009C:MACHINE_CHECK_EXCEPTION
　　◆錯誤分析:通常是硬件引起的. 一般是因爲超頻或是硬件存在問題(內存、CPU、總線、電
　　源).
　　◇解決方案:如果進行了超頻, 請降下CPU原來頻率, 檢查硬件.
　　25、0x0000009FRIVER_POWER_STATE_FAILURE
　　◆錯誤分析:往往與電源有關係, 常常發生在與電源相關的操作, 比如:關機、待機或休睡.
　　◇解決方案:重裝系統, 如果不能解決, 請更換電源.
　　26、0x000000A5:ACPI_BIOS_ERROR
　　◆錯誤分析:通常是因爲主板BIOS不能全面支持ACPI規範.
　　◇解決方案:如果沒有相應BIOS升級, 那麼可在安裝Windows 2K/XP時, 當出現"press F6 if you need to install a third-party SCSI or RAID driver"提示時, 按下F7鍵, 這樣Windows便會自動禁止安裝ACPI HAL, 而安裝 Standard PC HAL.
　　27、0x000000B4:VIDEO_DRIVER_INIT_FAILURE
　　◆錯誤分析:這個停止信息表示Windows因爲不能啓動顯卡驅動, 從而無法進入圖形界面. 通常是顯卡的問題, 或者是存在與顯卡的硬件衝突(比如:與並行或串行端口衝突).
　　◇解決方案:進入安全模式查看問題是否解決, 如果可以, 請升級最新的顯卡驅動程序, 如果還不行, 則很可能是顯卡與並行端口存在衝突, 需要在安全模式按下WIN+break組合鍵打開"系統屬性", 在硬件-->設備管理器中找到並雙擊連接打印的LPT1端口的選項, 在"資源"選項卡中取消"使用自動配置"的勾選, 然後將"輸入/輸出範圍"的"03BC"改爲"0378".
　　28、0x000000BE:ATTEMPTED_WRITE_TO_READONLY_MEMORY
　　◆錯誤分析:某個驅動程序試圖向只讀內存寫入數據造成的. 通常是在安裝了新的驅動程序, 系統服務或升級了設備的固件程序後.
　　◇解決方案:如果在錯誤信息中包含有驅動程序或者服務文件名稱, 請根據這個信息將新安裝的驅動程序或軟件卸載或禁用.
　　29、0x000000C2:BAD_POOL_CALLER
　　◆錯誤分析:一個內核層的進程或驅動程序錯誤地試圖進入內存操作. 通常是驅動程序或存在BUG的軟件造成的.
　　◇解決方案:請參考前面介紹的常規解決方案相關項目進行排除.
　　30、0x000000CERIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS
　　◆錯誤分析:通常是由有問題的驅動程序或系統服務造成的.
　　◇解決方案:請參考前面介紹的常規解決方案相關項目進行排除.
　　31、0x000000D1RIVER_IRQL_NOT_LESS_OR_EQUAL
　　◆錯誤分析:通常是由有問題的驅動程序引起的(比如羅技鼠標的Logitech MouseWare 9.10和9.24版驅動程序會引發這個故障). 同時,有缺陷的內存、 損壞的虛擬內存文件、 某些軟件(比如多媒體軟件、殺毒軟件、備份軟件、DVD播放軟件)等也會導致這個錯誤.
　　◇解決方案:檢查最新安裝或升級的驅動程序(如果藍屏中出現"acpi.sys"等類似文件 名, 可以非常肯定是驅動程序問題)和軟件; 測試內存是否存在問題; 進入"故障恢復控制檯", 轉到虛擬內存頁面文件Pagefile.sys所在分區, 執行"del pagefile.sys"命令, 將頁面文件刪除; 然後在頁面文件所在分區執行"chkdsk /r"命令;進入Windows後重新設置虛擬內存.如果在上網時遇到這個藍屏, 而你恰恰又在進行大量的數據下載和上傳(比如:網絡遊戲、BT下載), 那麼應該是網卡驅動的問題, 需要升級其驅動程序.
　　32、0x000000EA:THREAD_STUCK_IN_DEVICE_DRIVER
　　◆錯誤分析:通常是由顯卡或顯卡驅動程序引發的.
　　◇解決方案:先升級最新的顯卡驅動, 如果不行, 則需要更換顯卡測試故障是否依然發生.
　　33、0x000000ED:UNMOUNTABLE_BOOT_VOLUME
　　◆錯誤分析:一般是由於磁盤存在錯誤導致的, 有時也建議檢查硬盤連線是否接觸不良, 或是沒有使用合乎該硬盤傳輸規格的連接線, 例如ATA-100仍使用ATA-33的連接線, 對低速硬盤無所謂, 但告訴硬盤(支持ATA-66以上)的要求較嚴格, 規格不對的連線有時也會引起這類沒辦法開機的故障. 如果在修復後, 還是經常出現這個錯誤, 很可能是硬盤損壞的前兆.
　　◇解決方案:一般情況下, 重啓會解決問題, 不管怎麼樣都建議執行"chkdsk /r"命令來檢查修復硬盤
　　34、0x000000F2:HARDWARE)INTERRUPT_STORM
　　◆錯誤分析:內核層檢查到系統出現中斷風暴, 比如:某個設備在完成操作後沒有釋放所佔用的中斷. 通常這是由缺陷的驅動程序造成的.
　　◇解決方案:升級或卸載最新安裝的硬件驅動程序.
　　35、0x00000135:UNABLE_TO_LOCATE_DLL
　　◆錯誤分析:通常表示某個文件丟失或已經損壞, 或者是註冊表出現錯誤.
　　◇解決方案:如果是文件丟失或損壞, 在藍屏信息中通常會顯示相應的文件名, 你可以通過網絡或是其他電腦找到相應的文件, 並將其複製到系統文件夾下的SYSTEM32子文件夾中. 如果沒有顯示文件名, 那就很有可能是註冊表損壞, 請利用系統還原或是以前的註冊表備份進行恢復.
　　36、0x0000021A:STATUS_SYSTEM_PROCESS_TERMINATED
　　◆錯誤分析:用戶模式子系統, 例如Winlogon或客服服務運行時子系統（CSRSS）已損壞, 所以無法再保證安全性, 導致系統無法啓動. 有時, 當系統管理員錯誤地修改了用戶帳號權限, 導致其無法訪問系統文件和文件夾.
　　◇解決方案:使用"最後一次正確的配置", 如果無效, 可使用安裝光盤進行修復安裝.
　　37、STOP 0xC0000221 or STATUS_IMAGE_CHECKSUM_MISMATCH
　　◆錯誤分析:通常是由於驅動程序或系統DLL文件損壞造成的. 一般情況下, 在藍屏中會出現
　　文件名稱
　　.sys文件；
　　3. 將其重命名，如：XXXintelppm.sys；
　　4. 重啓。^[5]
　　-----------------------------------------------
　　人有的時候都會鬧情緒，更何況是機器呢。Windows有時候也會跟我們鬧鬧情緒，小則是“應用程序遇到問題需要關閉”，搞不好還可能給您臉色看看。但是，這臉色可不是紅的白的，而是一張“藍臉”，您見過嗎？首先，我們介紹以下三個重要的問題：
　　一、到底什麼是“藍臉”？
　　這裏指的就是大家經常稱之爲“藍屏”、“系統崩潰”之類的東西，外國人又叫它 BSOD(Blue Screen of Death)。從專業的角度講，這一術語被定義爲“是指當Microsoft Windows崩潰或停止執行（由於災難性的錯誤或者內部條件阻止系統繼續運行下去）時所顯示的藍色屏幕”。而我們平常所說的“系統崩潰(system crash)”或者“內核錯誤(kernel error)”抑或“停止錯誤(Stop error)”的專業術語爲“程序錯誤檢查(Bug Check)”。
　　二、爲什麼一定要給您“藍臉”？
　　一旦遇上系統藍屏崩潰，大多數的人都會以爲Windows不行了所以就癱瘓了，有點罪魁禍首是 Windows或者Windows不夠強悍、不夠穩定的意思。可是，Windows在默默地喊冤您知道嗎？要知道，每當有內核模式設備驅動程序或者子系統 引發了一個非法異常，Windows就會面臨這個艱難的抉擇，雖然Windows最終還是選擇了崩潰，但是這並不代表它就不能夠忽略該異常，讓設備驅動程 序或者子系統繼續往下執行。Windows之所以要選擇“亡我”，是因爲它不知道該錯誤是否能被隔離出來從而不傷害系統的其它程序與數據，或者該組件將來 是否能夠恢復正常，而且，Windows深知，這個異常更有可能來源於更深層的問題，比如由於內存的常規破壞(General Corruption)，或者由於硬件設備不能正常工作。允許系統繼續運行可能導致更多的異常，而且，存儲在磁盤或其他外設中的數據可能也會遭受破壞。 Windows意識到，這樣做的風險太大了，爲了您的程序、數據安全與完整，爲了將您的損失在第一時間減小至最低，Windows於是忍痛做出了自我犧 牲……
　　三、怎樣給出“藍臉”？
　　當系統檢測到引發崩潰的致命錯誤時，Windows自己執行崩潰函數 “KeBugCheckEx”。該函數接受一個停止代碼(STOP Code，也稱爲錯誤檢查碼“Bug Check Code”），以及四個根據停止代碼來解釋的參數(下文中會有圖例)。在調用KeBugCheckEx之後，首先該系統所有處理器上的所有中斷將被屏蔽， 然後系統將顯示器切換到低分辨率的VGA圖形模式（因爲這是所有Windows平臺顯卡均支持的通用模式），繪製一個藍色背景，然後顯示此停止代碼，並且 後面緊跟一些對用戶診斷錯誤有幫助的關鍵信息。最後，KeBugCheckEx調用所有已註冊的設備驅動程序錯誤檢查回調函數(這種回調函數通過調用 KeRegisterBugCheckCallback函數來註冊)，從而讓這些驅動程序停止運行它們所支配的設備(有系統數據結構已經被破壞得太嚴重以 至於藍屏都顯示不出來的可能性）。
　　以下情況會引發系統藍屏崩潰：
　　 1、運行在內核模式下的設備驅動程序或者操作系統函數引發了一個未被處理的異常，比如內存訪問違例（由於企圖寫一個只讀頁面或者企圖讀一個當前未被映射的內存地址(即無效地址)而引起）。
　　 2、調用一個內核支持例程導致了重新調度，比如當中斷請求級別(IRQL)爲DPC/Dispatch級別或更高級別時等待一個標記爲需要等待的調度對象。
　　 3、在DPC/Dispatch級別或更高的IRQL級別時由於數據存在於頁面文件或內存映射文件中而發生了頁面錯誤(Page Fault)。（這將要求內存管理器必須等待一個I/O操作發生。但正如上面一項所說，在DPC/Dispatch級別或更高IRQL級別上不能夠進行等 待，因爲那將要求一次重新調度）。
　　 4、當檢測到一個內部狀態表明數據已遭受破壞或者在保證數據不被破壞的情況下系統無法繼續執行時，設備驅動程序或操作系統函數明確地要求系統崩潰（通過調用系統函數KeBugCheckEx）。
　　 5、發生硬件錯誤，比如處理器的計算機檢查異常功能(Machine Check)報告有異常或者發生不可屏蔽中斷(NMI)。
　　在瞭解以上三點知識之後，相信您對Windows的大無畏犧牲精神會有所讚賞，也會原諒它的“ 藍臉”了。其實，在絕大多數情況下均是第三方設備驅動程序導致了Windows的崩潰。對於Windows XP用戶提交給微軟在線崩潰分析(Microsoft OCA, Microsoft Online Crash Analysis)站點的內存轉儲文件，微軟對引起崩潰的原因進行了統計分類，如下圖所示：（數據於2004年4月份生成）。
　　既然Windows向我們露出了無奈的“藍臉”，我們就應該打破沙鍋問到底，儘早將引發系統崩潰的罪魁禍首緝拿歸案，讓我們的系統早日康復。下面，我們來看看Windows想通過這張“藍臉”告訴我們些什麼。
　　如上圖所示，這是一張顯示了所有參數的藍屏圖像。當然，我們所遇到的藍屏圖像與之可能存在差異，比如少了一些信息等，但是大致是相同的，我們就以它爲例進行全面地闡述。
　　首先，我們看看圖中用數字1標註的區域，這裏列出了傳遞給KeBugCheckEx函數的停止 代碼和四個參數。此圖中的停止代碼爲0x000000D1，四個參數爲後面括號內的用逗號分隔的四段16進制數字；接下來，我們來看看圖中用數字2標註的 區域，這裏顯示的是該停止代碼0x000000D1對應的英文解釋；最後，我們看看圖中用數字3標註的區域，這個區域當且僅當停止代碼的四個參數中的一個 參數包含了操作系統或設備驅動程序代碼的地址時纔會顯示，顯示的內容爲、該地址所處模塊的基地址以及日期戳。如此例中，該設備驅動程序的文件名爲 “myfault.sys”。
　　這些信息對我們排錯有何作用呢？如果上圖中的區域3出現了，那是最好的結果了，因爲您直接就看 到了罪魁禍首——“myfault.sys”文件。但是，區域3往往是不出現的，那麼我們就要在Microsoft的在線幫助和支持 (http://support.microsoft.com)中查找該停止代碼等信息或者使用我們的利器——WinDbg進行手動分析了。筆者推薦後 者，因爲同一個停止代碼可能由各種各樣的驅動程序錯誤造成，得到了停止代碼並不等於得到了問題文件名稱，另外，微軟的在線幫助和支持中不是所有的錯誤都能 夠搜索到，而WinDbg正好克服了這兩個弱點，直接能夠抓出罪魁禍首文件，讓您痛快將其斬首。
　　WinDbg是免費軟件，其微軟官方下載地址是 http://www.microsoft.com/whdc/devtools/debugging/default.mspx，具體項目爲 Install Debugging Tools for Windows 32/64-bit Version。
　　使用WinDbg分析崩潰時的內存轉儲文件的前提是您要讓系統在崩潰時自動生成一個內存轉儲文件，做法如下：
　　1、單擊開始，然後單擊運行。
　　2、鍵入 control sysdm.cpl
　　複製代碼
　　，然後單擊確定。您將會打開系統屬性，請切換到高級選項卡。結果如下圖所示：
　　3、在高級選項卡上，在啓動和故障恢復部分中單擊設置。這將打開啓動和故障恢復對話框，如下圖所示：
　　4、在寫入調試信息列表中，選擇“小內存轉儲(64 KB)”或“核心內存轉儲”，這樣系統在崩潰時將會自動生成對應的內存轉儲文件。如果您不想讓藍屏只閃爍一下，而是想看清楚它直到您手動重新啓動計算機，請清除系統失敗部分中自動重新啓動(R)項目前的複選框。然後單擊確定。
　　5、在啓動和故障恢復對話框中，單擊確定。
　　6、單擊確定關閉系統屬性對話框。
　　7、在系統設置更改對話框中，如果要立即重新啓動計算機，則單擊是；如果要稍後重新啓動計算機，則單擊否。
　　注：
　　Vista用戶請類似操作。 對於原版操作系統，以上設置是默認的(除了禁止自動重新啓動)。 對於第4點中的寫入調試信息列表內容，現給出以下參照釋義：
　　（以上三種轉儲文件的大小依次增大，關於三者的比較不在本文討論範圍之內，筆者僅推薦設置爲“ 小內存轉儲”或者“核心內存轉儲”，一般性錯誤“小內存轉儲”就足夠了，如不能完好分析請選擇“核心內存轉儲”。爲了數據的豐富性，您也可以直接選擇“核 心內存轉儲”，但筆者強烈不推薦完全內存轉儲。）
　　值得注意的是，爲了確保崩潰時自動生成內存轉儲文件，您可能還須啓用虛擬內存頁面文件。特別 地，當您選擇記錄核心內存轉儲時，您必須啓用虛擬內存頁面文件，而且由於核心內存轉儲文件的大小取決於該機器上操作系統和所有活動驅動程序已經分配的內核 模式內存的數量，因此沒有很好的辦法來預測內核內存轉儲的大小。下表僅給出該情況下的參考虛擬內存大小設置值：
　　另外，除了頁面文件佔用的磁盤空間，內存轉儲文件(*.DMP)的生成位置所在的磁盤還要有足夠的空閒空間來提取這個轉儲文件，否則一樣會“生成不了”(實際上是丟失了)。
　　設置好這些之後，一旦您的系統發生藍屏崩潰，系統就會在以上設置中選中的相應內存轉儲文件類型下對應的目錄處生成轉儲文件。您所要做的就是立刻拿出利器——啓動WinDbg進行分析。
　　筆者在此將結合一個實例進行詳細說明，過程中包含了WinDbg調試藍屏用到的一些命令，這些命令將不再額外整理，請於閱讀過程中注意識記。
　　首先，您要配置WinDbg將要使用的調試符號文件(Symbol File)的位置。什麼是調試符號文件呢？符號文件隨DLL文件或者EXE文件建立時產生，提供包含在可執行文件和動態鏈接庫 (DLL) 中的函數的佔位空間。此外，符號文件還可以表示達到失敗點的函數調用路線圖。當我們使用各種Microsoft工具調試應用程序時，必須擁有符號信息，這 樣才能正確分析出問題根源。那我們該如何設置調試符號文件的位置呢？我們既可以從微軟官網下載完整的符號文件包(同位於WinDbg下載頁面)，也可以使 用微軟的符號文件服務器(Microsoft Symbol Server)。筆者推薦後者，因爲一次分析所要用到的符號文件侷限於有限的幾個而已，使用後者可以讓程序自動下載，既節省時間，又可以確保符號文件是最 新的並且是正確的。在WinDbg中點擊“File”菜單，選擇“Symbol File Path …”，在打開的對話框中輸入
　　SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols
　　複製代碼
　　後點擊“OK”按鈕即可。當然，還有一步就是再次點擊“File”菜單，選擇“Save Workspace”來保存當前的設置。
　　設置了符號文件之後，您就可以進行內存轉儲文件的分析了。同樣點擊“File”菜單，這次要選 擇“Open Crash Dump …”，然後通過文件打開對話框打開生成的待分析的內存轉儲文件。本例中設置的是核心內存轉儲類型，於是應該定位至“%SystemRoot%”(即系統盤 Windows文件夾下)，打開MEMORY.DMP文件。但是筆者已經事先將其轉移至“E:\Memory Dump\MEMORY.DMP”，因此在後續的圖片中，您看到的是這個地址。此時WinDbg會滾動顯示一些信息並且會稍有掛起的感覺，直到從微軟符號 文件服務器下載完分析這個崩潰文件所需要的所有符號文件。
　　在上圖中，我們看到就是這個打開的調試器命令窗口(Debugger Command Window)(已經將符號文件加載完畢，待命)，我們先看看位於底部的區域6，這個小的長方條就是WinDbg的命令輸入處(Command Entry)，它又分爲兩個區域，左邊顯示“0: kd>”的是提示區，右邊空白區是命令輸入區。當剛打開這個窗口而符號文件尚未下載/加載完畢時，提示區域會什麼都不顯示，而命令輸入區域將顯示 “Debuggee not connected”。直到符號加載完畢，窗口中顯示出最後一行“Followup: MachineOwner”纔會變爲空閒狀態。在空閒狀態時，它將顯示爲與上圖中類似的模樣。爲什麼說類似呢？因爲這個空閒待命提示根據調試類型、計算機 處理器硬件配置不同，比如此例中，進行的是內核調試，於是顯示“kd>”(kernel debug)，系統爲多(核)處理器，因此在“kd>”之前還顯示一個“0:”，表明當前位於編號爲0的處理器。在執行了某個命令之後，如果命令需 要處理的任務較多(如“!analyze -v”)，提示區域將顯示爲忙碌狀態的“*BUSY*”，一旦顯示爲這個狀態，您不論輸入什麼命令都不會立即執行，而是等待變爲空閒狀態時延緩執行。
　　如上圖所示，圖中區域1處將顯示打開的這個內存轉儲文件的物理路經；區域2處顯示的則是當前加 載的符號文件的位置，本例中表明是從微軟服務器下載；區域3共有三行，顯示的爲系統信息，第一行表明了系統爲Windows XP，內核版本爲2600(SP3)，多處理器(2顆)，32位，第二行表明了系統類型爲NT系統，客戶端系統，第三行表明系統的詳細版本標識；區域4共 兩行，第一行表明該內存轉儲文件生成的時間，也就是系統崩潰的具體時間，本例中(這是去年12月得到的一個崩潰轉儲文件，現用作本例進行說明)爲星期六 (Sat)，12月(Dec)27日，22:56:31.062，2008年，格林尼治標準時間東八區(GMT+8)，第二行顯示的是崩潰時自系統啓動以 來，系統共運行了0天4小時5分15.797秒。區域5是很關鍵的錯誤信息，它的第一行僅在加載符號文件遇到錯誤時顯示，此例中，它告訴我們“對於 BaseTDI.SYS文件，模塊已經加載完畢但卻不能夠爲其加載符號文件”，如果之前配置了正確的符號文件路徑，這就告訴我們BaseTDI.SYS不 是微軟公司的文件，而是第三方驅動程序文件，這很可能是引起錯誤的原因，值得關注但須進一步分析。區域5的第二行是WinDbg自動分析的結果，它告訴我 們，引起崩潰的原因(Probably caused by:)很可能是HookUrl.sys文件。一般情況下，這就是引起錯誤的罪魁禍首了，但是也有不少的例外，最典型的就是顯示一個微軟自己的文件在此 處，您可要注意了，爲了避免枉殺無辜，最好進一步分析來看看都有哪些模塊牽扯在崩潰的最後一刻，這樣就能夠保證審判無誤了！進一步分析的命令可以從 “!analyze -v”開始。
　　我們既可以在命令輸入區域手動鍵入命令
　　!analyze -v
　　複製代碼
　　，也可以在上圖中的區域7所示位置單擊藍色的這個命令。之後，提示區域將顯示爲“*BUSY*”，WinDbg將分析一段時間直到將結果顯示完畢並再次轉爲空閒狀態。下面我們根據一張例圖闡釋執行“!analyze -v”後顯示的各種結果：
　　WinDbg經過自動的分析，可能會顯示上圖中區域1處所示第一行的錯誤檢查說明(Bug Check Interpretation)，而第二行則給出了詳細的解釋，從圖中信息看得出，此例錯誤由於“驅動程序在隊列工作項目完成之前卸載”造成的。這個 “DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS”就應該是顯示在藍屏上方的錯誤說明字 樣，後面的Arguments1~4就是藍屏時停止代碼後面的四個參數。圖中區域2所示的BUGCHECK_STR是WinDbg中分了類別的錯誤檢查 (Bug Check)的一項，此例中爲0xCE，也是停止代碼的分類簡寫，我們在命令輸入區執行
　　.bugcheck
　　複製代碼
　　命令，可以得到停止代碼及其參數，這和上圖的區域1、藍屏上的信息是一致的。本例中可以得到如下結果：
　　0: kd> .bugcheck
　　Bugcheck code 000000CE
　　Arguments bacb0a4e 00000008 bacb0a4e 00000000
　　我們在Bugcheck code值前補上“0x”就可以得到藍屏上的信息“***STOP: 0x000000CE (bacb0a4e, 00000008, bacb0a4e, 00000000)”。當然，關於這個錯誤如果您想了解更多，一個是可以在微軟在線幫助和支持網站上搜索字符串“0x000000CE”，再就是可以利用 上圖中區域2的BUGCHECK_STR值“0xCE”執行
　　.hh bug check 0xCE
　　複製代碼
　　命令，在打開的窗口左欄右下角點擊“Display”按鈕。如果要在WinDbg中顯示一個停止代碼或者錯誤檢查類的詳細說明(以此錯誤爲例)，鍵入命令
　　!analyze -show 0x000000CE
　　複製代碼
　　或者
　　!analyze -show 000000CE
　　複製代碼
　　，也可以是
　　!analyze -show 0xCE
　　複製代碼
　　。區域3中顯示的就是二審判決的重要信息——線程堆棧信息。特別注意紅色框內的部分，第一行是 “WARNING: Frame IP not in any known module. Following frames may be wrong.”意思就是“警告：堆棧幀IP(InstructionPtr，僅x86處理器，用於決定幀的堆棧回朔的指令指針)不存在於任何已知的模塊 中，下面的幀可能出現錯誤”。這個意思的解釋已超出本文討論範圍，筆者僅告訴大家，這行文字下面的一行右側的模塊是系統藍屏崩潰時刻使用的最後一個模塊 (除了Windows內核最後調用KeBugCheckEx犧牲自己，就是警告文字上方的三行)，往往就是它引起了崩潰！我們來細看。大家如果瞭解了堆棧 的數據結構或是Windows內存分配機制就應該知道，Windows爲線程分配額外內存時是從高地指向低地址進行的，就是說，藍色區域3中的堆棧信息我 們得倒過來由下往上看，這樣纔是系統崩潰之前的一刻內核態函數的調用和傳遞情況，比如此例，系統內核執行體(nt!,即Ntoskrnl.exe)通過函 數IopfCallDriver調用了BaseTDI，然後BaseTDI又調用了HookUrl.sys(Unloaded_字樣表示未加載)，再然後 就藍屏了。那麼在這最後一刻就涉及到了兩個非Windows內核的模塊——BaseTDI以及HookUrl.sys。之所以要進行這個“二審判決”，就 是要避免一種情況——萬一HookUrl.sys與BaseTDI是來自兩個公司或者兩個軟件的模塊，而最後加載的HookUrl.sys是沒有問題的， 出錯是因爲BaseTDI給HookUrl.sys傳遞了格式錯誤或者已被破壞的、或者非法的參數信息，HookUrl.sys接受此無效數據而引發了崩 潰。如果我們不看線程棧，就根據之前的“Probably Cause by：HookUrl.sys”進行判決，我們很有可能枉殺無辜而讓兇手逍遙法外。只有通過線程棧我們才能發現另一個驅動程序BaseTDI也被牽連進 來。(在應用程序崩潰不致系統崩潰的調試分析中，由於處於用戶態，WinDbg自動分析結果中的“Probably Cause by：”幾乎都是錯誤的。在這種情況下，使用!thread命令是不能顯示出任何信息的，因爲這個命令僅對內核態的崩潰調試有效，然而kb命令也顯示不出 有用的信息，只有用“~*kb”來顯示詳細的全部線程棧纔可能發現問題根源，有的時候還需配合其他命令，本文不作討論)
　　當然，如果您熟練以後，覺得沒有必要使用“!analyze -v”命令的話，可以直接使用
　　!thread
　　複製代碼
　　或者
　　kb
　　複製代碼
　　命令顯示出核心的線程棧信息來二審判決。現在好了，犯罪嫌疑人目標鎖定在BaseTDI和 HookUrl.sys身上。現在，我們來看看它們究竟是什麼、是哪個公司、哪個程序的模塊。(從之前不能夠自動從微軟服務器爲他們加載符號文件就可以知 道，它們一定都是第三方驅動程序)
　　使用命令
　　lm kv m Basetdi*
　　複製代碼
　　(使用lm(列出模塊)命令和內核k選項、詳細v選項以及參數m，配合包含通配符*的字符串 BaseTDI，來列出當時已加載於內核模式的包含字符BaseTDI的所有驅動文件詳細信息。使用通配符來取代完整的文件名後綴可以避免信息的侷限性， 藉此也許可以發現多個相關的模塊以提供更多診斷線索)，我們得到下圖結果：
　　從圖中藍色框選部分，我們可以看出，當時內核態下只有一個叫BaseTDI.SYS的文件，這 個文件的路徑位於System32\Drivers下，屬於名稱爲“瑞星個人防火牆”(ProductName: Rising PFW, PFW=Personal Firewall)的程序組件，軟件公司註冊商標爲“瑞星”(LegalTrademarks: RISING)。文件的這些英文描述信息如果您不知道，可以百度一下。當然，沒有被筆者高亮顯示的信息(如文件時間戳、版本、校驗和等等)也是非常有用 的，比如百度一下文件版本，也許您會發現該軟件已經提供了更新的解決此問題的文件。同樣，我們使用
　　lm kv m hookurl*
　　複製代碼
　　來顯示當時內核態下包含HookUrl的文件及其詳細信息。結果如下：
　　圖示是一個不令人滿意的結果，因爲如高亮部分所示，這個模塊未被加載，因此沒有信息被記錄。不 過我們有百度，不用急，百度一下你就知道。在搜索完HookUrl.sys之後，發現這個也是瑞星個人防火牆的文件。其實這個案例就是著名的“瑞星個人防 火牆跨版本升級到2009版時引發藍屏”事件。您可以通過關鍵字“瑞星防火牆2009升級造成藍屏”進行百度搜索。到目前爲止，瑞星官方都沒有任何針對此 事件的正式答覆，雖然不是每個用戶都出現此問題，但是非常多的用戶都報告了此問題，瑞星也不承認這個是軟件缺陷，只有官方卡卡論壇上有一個不知道是不是工 作人員的人發帖要求大家遇到藍屏就上傳內存轉儲文件。說到這裏，我對瑞星又要失望了，但是通過這個可見藍屏內存轉儲文件的分析是多麼的有用！
　　在這裏，我還要給出兩個要得到更多信息時可能會使用到的命令，一個是
　　!process 0 0
　　複製代碼
　　，它可以列出當時運行着的所有進程的技術信息；另一個則是
　　!vm
　　複製代碼
　　，它能夠顯示出當時的虛擬內存使用情況，這對於分析系統是否耗盡了虛擬內存、換頁內存池或非換頁內存池，並結合進程列表找到可能的內存泄漏錯誤非常有用，不過已超出了本文的討論範圍。
　　最後，我們來看看以下的兩種特殊情況該如何使用WinDbg進行調試分析：
　　第一種情況是系統掛起，也就是“死機”、“系統沒有響應”，在這種情況下，系統是根本無法自動 生成內存轉儲文件的，而且您也不可能操作本地軟件來查明是什麼掛起了系統，這個時候我們需要手動讓系統崩潰，以生成內存轉儲文件。具體做法爲，在系統掛起 之前，打開註冊表編輯器並定位至
　　HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\i8042prt\Parameters
　　複製代碼
　　，在該項下面建立一個名爲
　　CrashOnCtrlScroll
　　複製代碼
　　的DWORD類型鍵值(注意大小寫)，並將其設置爲1，然後重新啓動應用此更改。一旦系統掛 起，就可以通過按住右邊Ctrl鍵的同時擊ScrollLock鍵兩次來生成一個停止代碼爲 0x000000E2(MANUALLY_INITIATED_CRASH)的手動崩潰。得到內存轉儲文件以後按照上面的方法分析。注意，此方法對插入 USB口的USB鍵盤無效。(筆記本計算機鍵盤很多都是通過PS/2接口連接的，因此有效)
　　第二種情況是進不了系統就自動崩潰，無法提取出內存轉儲文件。這種情形以及當有特定的需要時，我們都可以採取雙機調試的方法。我們將發生崩潰的機器稱爲“目標機”，將用來連接到“目標機”進行調試的機器稱爲“調試主機”，調試主機必須安裝有WinDbg。
　　首先，我們需要在兩臺機器間建立連接，在新版的WinDbg中，這裏一共有三種方式連接到目標 機。第一種方式爲通過COM端口連接，使用零調制解調器線纜(Null-Modem)，也就是COM對接線——兩個頭都是孔的RS232線；第二種是利用 IEEE 1394線纜連接，但是這種連接要求兩臺機器運行相同版本的至少爲Windows XP的系統；第三種方式是使用特製的USB 2.0調試線纜連接，這不是普通的USB連接線，是一種內置硬件芯片來支持調試的線纜，而且這種方式要求目標機運行的系統至少爲Windows Vista。使用這三種連接方式進行雙機調試都需要在目標機上作出相應的設置調整，具體參見WinDbg幫助文件，這裏僅討論第一種連接方式的設置，因爲 這是XP及以上系統默認支持的最簡單的方式。此時我們假設已經使用COM線纜連接好了兩臺機器。
　　其次，在調試主機上啓動WinDbg，配製好符號文件之後，我們展開“File”菜單，選擇“Kernal Debug…”，這將會打開如下的“Kernal Debugging”對話框：
　　默認打開的就是COM連接方式的配置頁面。這裏的“Baud Rate(傳輸速率)”以及“Port(端口)”需要根據下一個步驟的操作方式來配置。
　　最後一步，我們可以啓動目標機，在引導Windows之前按下F8，在啓動菜單中選擇“調試模 式”，這樣，傳輸速率被系統默認設爲19200，端口也默認被設爲COM2，因此上一步驟中應該照此設置後點擊“OK”。關於XP修改Boot.ini、 Vista修改Bootcfg的方式啓用指定端口、傳輸速率的調試，請參見WinDbg幫助文件，在此不再贅述。目標機一起動Windows，位於調試主 機的WinDbg就能夠有信息的顯示，然後按照本文介紹的方法進行調試。另外，對於上面提到的系統掛起的情況，也可以採用這種雙機調試，並且有新的命令
　　.crash
　　複製代碼
　　強迫目標機在它的本地硬盤驅動器中生成一個崩潰轉儲，當系統重新引導以後就可以提取此轉儲，當然，也可以使用
　　.dump /m COM.dmp
　　複製代碼
　　命令，在調試主機WinDbg所在目錄下生成一個名叫“COM.dmp”的小內存轉儲文件(命令中的文件名可以改成其它的)。