找出引發 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?? 沒錯，他會把當機時的記憶體完整的（也是依照設定不同而定）存入硬碟之中，因此我們可以：
- 到預設的目錄中找出 memory.dmp：C:\Windows\
- 下載 windbg
- 開啟 windgb -> Open Crash Dump （詳細步驟也可以參考這裡，不過如果只是要找錯誤來源還用不到這麼複雜的功能）
- 在命令列中輸入 !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
---------
- 引發錯誤的動作：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?