in Windows ~ read.

找出引發 Windows BSOD (藍屏死機) 當機原因

大家應該都有過這個經驗,螢幕上出現藍底白字,也就是所謂的藍屏死機畫面(Blue Screen Of Death)。這種情況通常都不是因為我們自身操作錯誤而引起的,因為這種錯誤通常都是 Kernel-mode component 或是硬體錯誤才會引起的。

硬體錯誤的話沒轍,不是找出錯誤來源換新的就是只好買台新電腦。但是 Kernel-mode component 指得是什麼呢?最常見的就是 driver 了。在這篇文章裡分享一下前幾天發生 BSOD 的解決方法:

其實 Windows 7 的確是目前最穩定的版本,從發行至今,這是我第一次看過 BSOD,而且還是發生在我剛灌完作業系統不久的新電腦上!這種情況,十之八九會是驅動程式惹得禍,因為驅動程式一定得跑在 Kernel-mode,只要程式本身有 bug 沒有發現,很容易導致 BSOD 的狀況發生(而這類 bug 又屬非法記憶體存取最多)。

回到正題來,該如何知道是哪裡出錯呢?發生 BSOD 的時候,依電腦設定不同,有些可能是出現 BSOD 之後把 memory dump 存起來之後就自動重開機了,你可能甚至還沒能看到裡面到底寫了些什麼。
即使沒有重開機,可能寫了一堆不相干的話,告訴你錯誤的記憶體位址,最後叫你去找供應商
… ╮(-_-)╭

你可能也已經從文章中看出一點端倪,memory dump?? 沒錯,他會把當機時的記憶體完整的(也是依照設定不同而定)存入硬碟之中,因此我們可以:

  1. 到預設的目錄中找出 memory.dmp:C:\Windows\
  2. 下載 windbg
  3. 開啟 windgb -> Open Crash Dump (詳細步驟也可以參考這裡,不過如果只是要找錯誤來源還用不到這麼複雜的功能)
  4. 在命令列中輸入 !analyze -v
******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* VIDEO_TDR_FAILURE (116) Attempt to reset the display driver and recover from timeout failed. Arguments: Arg1: 850540f8, Optional pointer to internal TDR recovery context (TDR_RECOVERY_CONTEXT). Arg2: 8e0279b0, The pointer into responsible device driver module (e.g. owner tag). Arg3: 00000000, Optional error code (NTSTATUS) of the last failed operation. Arg4: 0000000d, Optional internal context dependent data. Debugging Details: ------------------ FAULTING_IP: igdkmd32!DxgkDdiCollectDbgInfo+0 8e0279b0 55 push ebp DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_TDR_FAULT BUGCHECK_STR: 0x116 PROCESS_NAME: System CURRENT_IRQL: 0 STACK_TEXT: 8aa4bb74 8e5a007b 00000116 850540f8 8e0279b0 nt!KeBugCheckEx+0x1e 8aa4bb98 8e594937 8e0279b0 00000000 0000000d dxgkrnl!TdrBugcheckOnTimeout+0x8d 8aa4bbbc 8dc3a92c 00000000 00000102 8635b3c0 dxgkrnl!TdrIsRecoveryRequired+0xb8 8aa4bc34 8dc64972 fffffcfb 0028af66 00000000 dxgmms1!VidSchiReportHwHang+0x3c0 8aa4bc5c 8dc65065 00000000 00000000 00000000 dxgmms1!VidSchiCheckHwProgress+0x96 8aa4bc98 8dc418f0 8aa4bc90 862eb9b0 8638edd0 dxgmms1!VidSchiWaitForSchedulerEvents+0x1b1 8aa4bd28 8dc663c9 8635b3c0 8288b509 8635b3c0 dxgmms1!VidSchiScheduleCommandToRun+0xaa 8aa4bd3c 8dc66485 8635b3c0 00000000 86391948 dxgmms1!VidSchiRun_PriorityTable+0xf 8aa4bd50 82a5cfda 8635b3c0 a38ee8de 00000000 dxgmms1!VidSchiWorkerThread+0x7f 8aa4bd90 829051f9 8dc66406 8635b3c0 00000000 nt!PspSystemThreadStartup+0x9e 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19 STACK_COMMAND: .bugcheck ; kb FOLLOWUP_IP: igdkmd32!DxgkDdiCollectDbgInfo+0 8e0279b0 55 push ebp SYMBOL_NAME: igdkmd32!DxgkDdiCollectDbgInfo+0 FOLLOWUP_NAME: MachineOwner MODULE_NAME: igdkmd32 IMAGE_NAME: igdkmd32.sys DEBUG_FLR_IMAGE_TIMESTAMP: 4a01d354 FAILURE_BUCKET_ID: 0x116_IMAGE_igdkmd32.sys BUCKET_ID: 0x116_IMAGE_igdkmd32.sys Followup: MachineOwner ---------
從 Windbg 幫我們分析出來的結果中,我們可以得到三個資訊: - 引發錯誤的動作:Attempt to reset the display driver and recover from timeout failed. - 錯誤原因:GRAPHICS_DRIVER_TDR_FAULT - 錯誤來源:IMAGE_NAME: igdkmd32.sys
如果不夠詳細的話,我們還可以輸入 [.lmr](http://www.networkworld.com/news/2005/041105-windows-crash.html?page=4) ,可以列出當初 OS 幫我們載入的模組詳細資訊,甚至可以幫助我們找出詳細的驅動程式名字及生產商。但是在這個案例中是沒有太大幫助的,因為許多驅動程式都是內建於 OS 之中的,而這種驅動只會顯示是內建的,並不會列出其餘有用資訊。
透過這些訊息,我們可以發現這是 Intel 的整合顯示晶片驅動程式所造成的錯誤,Intel 也對這個錯誤提供了[新版驅動下載](http://www.intel.com/p/en_US/support/detect/graphics),解決~!
看完這篇文章,有感覺到你的好人技能提升了嗎XD?
comments powered by Disqus