Windows Blue Screen of Death (BSOD) ไม่ใช่สิ่งที่คุณอยากเห็นบนหน้าจอ เว้นแต่คุณใช้ Screensaver หรือทดสอบซอฟต์แวร์ แต่บางครั้งผู้ใช้ Windows พบกรณีล้มเหลวสูงสุดของซอฟต์แวร์ คือ Kernel เอง ทำให้ระบบค้างและ Crash ท้ายที่สุด

ในลินุกซ์ เรียกว่า Kernel panic ใน Windows เรียกว่า BSOD แต่นี่คือสิ่งเดียวกัน: Exception วิกฤตที่ไม่สามารถกู้คืนได้ในแกนกลางของระบบ คือ Kernel และไดรเวอร์ที่มาด้วย

บทนำสั้นๆ

หลังจากทำ Series ลินุกซ์ Crash ยาวนานและ Geek มาก เริ่มจาก Kernel crash dump tools ต่อกับ Setup บน openSUSE และ CentOS จนถึงการวิเคราะห์เชิงลึก ผมอยากเสนอ Windows users เวอร์ชันสั้นกว่าและ Geek น้อยกว่าสำหรับการวิเคราะห์ BSOD มีสองเหตุผล: 1) ไม่สามารถลึกได้เท่าที่อยาก เพราะ Windows Source ปิด 2) ผมไม่เก่งใน Windows Kernel เท่าลินุกซ์ แต่บทช่วยสอนนี้ยังค่อนข้าง Nerdy และเกินความต้องการของผู้ใช้ทั่วไป หากอยากเรียนรู้ Windows internals และได้ทักษะใหม่ช่วยวินิจฉัยปัญหา Core system คุณมาถูกที่แล้ว

เริ่มกันเลย

สารบัญ

1. คำถาม
2. เปิดใช้งานการเก็บ BSOD
3. การเก็บ BSOD
   1. Driver Verifier
4. การวินิจฉัย BSOD
   1. Windows Symbol Packages
   2. เครื่องมือวิเคราะห์ BSOD 1: WhoCrashed
   3. เครื่องมือวิเคราะห์ BSOD 2: Nirsoft
   4. เครื่องมือวิเคราะห์ BSOD 3: Windows Debugger (WinDbg)
5. ตัวอย่าง BSOD
   1. เรียกใช้ BSOD (ด้วย StartBlueScreen)
6. การวิเคราะห์ BSOD
   1. ผลลัพธ์ WhoCrashed
   2. ผลลัพธ์ Nirsoft BlueScreenView
   3. ผลลัพธ์ Windows Debugger
   4. ดึง Symbols ที่ถูกต้องออนไลน์!
   5. คำสั่งและตัวเลือก Debugger อื่นๆ
   6. ต่อไปทำอะไร?
   7. ส่งข้อมูล Kernel dump เพื่อวิเคราะห์
7. สิ่งเพิ่มเติม
   1. การตรวจสอบหน่วยความจำ
8. อ้างอิง
   1. วิธีใช้ Symbols ออนไลน์
   2. ทรัพยากรอื่นๆ ที่มีประโยชน์
9. สรุป

คำถาม

ก่อนลงลึกลงไปใน Tech jargon มาตอบคำถามเกี่ยวกับ BSOD ก่อน

อะไรคือสาเหตุของ Blue Screen of Death?

ไม่มีคำตอบง่ายๆ ผู้ใช้ Windows มานานจะรู้ว่าบางคนเจอ BSOD บ่อย บางคนไม่เห็นเลย แม้รัน Windows เดียวกัน

ความหลากหลายของประสบการณ์มาจากข้อเท็จจริงที่ว่า BSOD เกือบไม่เคยเกิดจาก Microsoft Windows components แม้คนส่วนใหญ่เคารพ Windows แต่ Crash เกิดจาก OS เองได้น้อยมาก

ประสบการณ์ส่วนตัวของผม:

บนเครื่อง Windows สองเครื่อง Uptime รวม 10 ปี ผมเจอ BSOD เพียงสองครั้ง ครั้งละเครื่อง เกิดห่างกันน้อยกว่า 1 ชั่วโมง

อาจคิดว่าเกิดจาก Windows update ล่าสุด หรือโปรแกรมที่รันอยู่ นำไปสู่ Hardware และ Software setup ที่เกือบเหมือนกัน แต่ไม่ใช่ Software fault

สาเหตุจริง: การ์ดจอร้อนเกินเก้า วันร้อนมาก การ์ดจอเกิน Normal temperature range

BSOD อื่นๆ ที่เจอบนเครื่องอื่น เกี่ยวกับ Bad, malfunctioning หรือ Buggy drivers ที่ติดตั้งโดย Software หรือ Hardware รวมถึง Wireless card, Security programs ฯลฯ ไม่เคยเห็น Core Windows components squeak แค่ใช้งานบ้าน

ตอนนี้เรารู้เรื่องแล้ว มาเป็นวิทยาศาสตร์กัน

เปิดใช้งานการเก็บ BSOD

เพื่อใช้ Built-in tools ให้มีประโยชน์ ต้องเปิดให้ Windows เก็บ Crash dumps เรียกว่า Minidumps คล้าย Enable LKCD หรือ Kdump ในลินุกซ์ โดย Default Windows kernel memory dumps เปิดอยู่ ต้องตรวจสอบให้ถูกต้อง

ตั้งค่าที่ Right-click Computer ใน Explorer > Properties > System > Advanced > Startup and Recovery ส่วนล่าง System failure ตั้งค่าพารามิเตอร์

เลือก Log crashes to system log, Auto restart, Overwrite existing files แนะนำไม่ Overwrite เก็บข้อมูลไว้เปรียบเทียบวิเคราะห์ภายหลังดีกว่า

สำคัญ: Write debugging information dropdown box ระบุส่วนของ Memory ที่จะบันทึกเมื่อ Crash คล้าย Kdump DUMPLEVEL

ตัวเลือก:

• Small memory dump - ไฟล์พื้นฐานข้อมูล Crash เท่านั้น ความมีค่าจำกัด ไม่มี Trace ของ Executables และ DLLs ที่โหลดใน Memory Windows XP: 64K, Windows 7: 128K
• Kernel memory dump - Dump ส่วนของ Memory ที่มี Kernel เท่านั้น เพียงพอในส่วนใหญ่ เพราะ Kernel crashes เกิดจาก Kernel bug หรือ Drivers
• Complete memory dump - Dump ทั้ง RAM

คลิก OK ตอนพอใจ เริ่มวิเคราะห์ได้แล้ว

การเก็บ BSOD

การหา Root cause อาจไม่ง่าย Hardware problems ทำให้เกิดพฤติกรรม Erratic และ Unpredicted อาจ manifest ในอาการต่างๆ โดยไม่ให้ Pinpoint issue Software problems ควรวินิจฉัยง่ายกว่า

เมื่อ BSOD เกิดขึ้น งานแรก: พยายามแยก Component ที่มีปัญหา และทำให้มัน Trigger BSOD อีกครั้ง หาก Replicate ได้ จะแก้ได้

Driver Verifier

หาก Troubleshoot BSOD ควรใช้ Driver Verifier

Driver Verifier เป็นเครื่องมือทรงพลัง ทำได้มาก: รัน Drivers ใน Isolated memory pool, Extreme memory pressure, Validate parameters, Unload checking, และอื่นๆ

เริ่ม Verifier: หา Executable รัน Windows XP: Start > Run > Verifier Windows 7: พิมพ์ Verifier ใน Search box Enter

Configure Verifier: สร้าง Standard settings (เหมาะสำหรับส่วนใหญ่) หรือ Custom settings (สำหรับ Developers) แสดง Tasks, ลบ Tasks, แสดงข้อมูล Drivers ที่ Verified อยู่

เลือก Drivers ที่จะตรวจสอบ: Unsigned drivers, Drivers สำหรับ Windows เก่า, หรือ All drivers เนื่องจากยังไม่รู้ปัญหา เลือก All

Reboot Verifier จะใช้ CPU มาก ช้าลง อาจ Crash เพิ่ม Verifier จะ Disable faulty drivers ระหว่าง BSOD และ Reboot จนถึง Desktop คุณจะได้ Minidumps หลายไฟล์

ปิด Verifier: รัน App ลบ Existing settings

หากไม่ Boot เข้า Desktop เพราะ Verifier ให้ Disable ด้วย Last Known Good configuration หรือ Boot เข้า Safe mode

ได้ Minidumps แล้ว มาวิเคราะห์กัน

การวินิจฉัย BSOD

ต้องการเครื่องมือหลายอย่าง หากจำบทช่วยสอนลินุกซ์ Prerequisite ของ Crash คือ Kernel compile ด้วย Debug symbols และ Debuginfo packages

Windows Symbol Packages

Windows ไม่ต่างกัน ต้องมี Symbols สำหรับการวิเคราะห์ที่ถูกต้อง ต้อง Download และ Install Symbols ที่ตรงกับ Windows Kernel version อย่างแม่นยำ ไม่เช่นนั้นการวิเคราะห์จะไม่แม่นยำ เหมือนลินุกซ์ในแง่นี้

จะแสดงตัวอย่างภายหลัง

หลังติดตั้ง Symbols ต้องการ Tool อ่านและแปล Crash data จะแสดง 3 เครื่องมือ เริ่มจากง่ายไปยาก

เครื่องมือวิเคราะห์ BSOD 1: WhoCrashed

WhoCrashed เครื่องมือ Simple, Effective ให้รู้ว่า Driver ไหนทำให้ Crash ใช้ง่าย ไม่ต้องการ Expertise แม้การวิเคราะห์ที่ถูกต้องต้องการ ต้องการ Windows Debugger ติดตั้ง

เครื่องมือวิเคราะห์ BSOD 2: Nirsoft

หาก Semi-serious เกี่ยวกับ Windows ควรรู้จัก Nirsoft tools ชุด Utilities เยอะมาก พัฒนาโดย Nir Sofer โดยเฉพาะ BlueScreenView สำหรับวิเคราะห์ Kernel memory dumps สิ่งดีคือรวมอยู่ใน Nirlauncher Swiss Army knife style toolbox มากกว่า 100 แอปจาก Nir ไม่ไร้เหตุผลที่เว็บ Nir อยู่ใน Greatest list ของผม

Nir Sofer ยังมี Tool สำหรับเรียก BSOD เรียกว่า StartBlueScreen อยู่ใน Nirlauncher อ่าน Review Nirlauncher ของผมเพื่อรายละเอียด

จะพูดถึงทั้งสองโปรแกรมเร็วๆ นี้

เครื่องมือวิเคราะห์ BSOD 3: Windows Debugger (WinDbg)

Windows Debugger เครื่องมือหลายวัตถุประสงค์ ใช้ Troubleshoot Drivers, Applications, Services บน Windows

Windows Debugger อยู่ใน Windows SDK

Windows 7 ตอนติดตั้ง Debugger อาจได้ .NET Framework 4 error ข้ามได้ ถ้าไม่ทำงานกับ .NET apps ในกรณีนี้ Safe to proceed

ในเมนูติดตั้ง เลือก Components ที่ต้องการ เราต้องการ Debugging Tools for Windows ใต้ Common Utilities

Windows Debugger ดูไม่น่าสนใจตอน Launch แต่มัน Mighty tool ใช้เวลามาก ความอดทน และความรู้ในการทำงานอย่างถูกต้อง คล้าย GDB ในลินุกซ์ สามารถ Examine sources, Attach running processes, Examine kernel dumps, และอื่นๆ

ตัวอย่าง BSOD

เรียกใช้ BSOD (ด้วย StartBlueScreen)

เพื่อดูเครื่องมือทำงาน ต้องมี BSOD รัน Verifier บน Windows 7 ของผมไม่ได้ผล ใช้ NirSoft StartBlueScreen ที่กล่าวไว้

StartBlueScreen เป็น Command line tool ต้องรันด้วย Parameters ที่ Trigger BSOD ต้องใช้ Administrator account

Windows 7 Enable hidden administrator account อาจ Tricky จะมีบทความแยก Windows XP ก็ไม่ Trivial อีก จะพูดแยก

Login เป็น Admin รัน StartBlueScreen จาก Command line Nir Sofer มี Examples บนเว็บ ใช้หนึ่งในนั้น:

StartBlueScreen.exe 0x12 0 0 0 0

คล้าย echo c > /proc/sysrq-trigger บนลินุกซ์ (SysRq enabled) หลังไม่กี่วินาที จะเห็น BSOD:

รอ Dump เสร็จ หลัง Reboot วิเคราะห์ Crash อาจเห็น Popup message หลัง Reboot มี Hint เกี่ยวกับสิ่งที่เกิดขึ้น

การวิเคราะห์ BSOD

ดูว่าแต่ละเครื่องมือ 3 ตัวให้อะไร

ผลลัพธ์ WhoCrashed

ได้ Drilldown เรียบง่าย สำหรับคนส่วนใหญ่ข้อมูลนี้พอเริ่มต้น รู้ชื่อ Offending driver ช่วยแยกปัญหา

เห็น Error เป็น Unknown kernel trap ก่อให้เกิดโดย nirsoftbluescreendriver.sys คาดเดาได้ เพราะ Code ของ Nir คล้าย Null-pointer kernel driver example ของผม

ผลลัพธ์ Nirsoft BlueScreenView

BlueScreenView ให้ข้อมูลละเอียดกว่า โหลด Minidump files ใน Root folder อัตโนมัติ Top view: ข้อมูลพื้นฐาน Crash รวม Bug Check String (เหมือน Panic String ใน Linux) และ Bug Check Code (คล้าย Kernel Page Error)

Bottom pane: รายการ Drivers ที่โหลดใน Memory ตัวที่เกี่ยวข้อง Crash ถูก Mark สี Salmon (สีส้มชมพู) หากต้องการ Call trace สำหรับ Crash process เปลี่ยน Filter ใน Options menu

ยังโหลด Original BSOD screen (XP style) ได้:

มีประโยชน์บางครั้ง ดู Technical Information section มีชื่อ Bad driver และ Memory address คล้าย Exception RIP ใน Task backtrace ลินุกซ์ โฟกัสที่ Stack:

มีชื่อ Executable และ Memory address ทฤษฎีแล้ว หากมี Sources จะ Pinpoint บรรทัด Code ที่ทำให้ Kernel crash แต่ไม่มี Sources สิ่งที่ดีที่สุดคือเก็บ Data มากที่สุด ส่งให้ Microsoft วิเคราะห์ต่อ จะพูดเร็วๆ นี้

โดยรวม Microsoft จะออก Patch สำหรับ Crashes ใน Microsoft components คำถามคือ: รู้ยังไงว่า nkrnlpa.exe เป็น Microsoft component? Double click entry หรือ Right-click Properties จะได้รายละเอียด

เห็นได้ว่าการทำงานกับ Windows crashes ไม่ต่าง Linux มากนัก แต่คุณอาจอยากรู้รายละเอียด ต้องการ Sources ที่ไม่พร้อมใช้งานเสมอไป เช่นเดียวกับลินุกซ์หากมี Proprietary drivers เช่น Nvidia โปรดสังเกต File version - สำคัญเมื่อใช้ Symbols

ผลลัพธ์ Windows Debugger

Windows Debugger ซับซ้อนและทรงพลังที่สุดของ 3 เครื่องมือ ก่อนเริ่ม ต้องรู้ว่าใช้เวลา ความอดทน และความรู้ ถึงแม้ผมจะ Bravado ผมค่อนข้าง Inexperienced แต่ Common sense และ Universal knowledge ของ Crash analysis ใช้ได้ดี หากรู้ Business หนทางมืดของ Code ในระบบหนึ่ง จะเก่งในทุกระบบ

Permissions

หากไม่ใช่ Administrator ไม่มี Permission เข้าถึง Memory dumps (เหตุผลความปลอดภัย) อาจต้อง Copy file หรือ Set permissions ให้ถูกต้อง

Load symbols

ขั้นแรก: Load symbols Tool อาจไม่รู้ Symbols location บน Disk เพราะ Path ไม่อาจอยู่ใน Environment variables เพื่อเน้นจุดนี้ ผม Load crash dump โดยไม่ระบุ Symbols

เห็น Error string: ERROR: Module loaded completed but... นี่เกิดเมื่อไม่มี Symbols ทำให้ Analysis ไร้ผล หากรัน Analysis จะได้ Question marks เพราะ Debugger ไม่ทายได้ว่า Driver mapped ใน Memory ยังไงตอน Crash

ตรวจสอบ Current symbols path ด้วยคำสั่ง .sympath จะว่างหากยังไม่ Load symbols ตอนนี้ Load symbols

หลัง Load symbols ไม่ต้อง Reopen minidump แค่ Reload ได้โดย Check Reload box ใน Symbol Search Path window หรือรัน .reload ใน Debugger command line (kd>)

จะได้ Output ต่างออกไป

Run analysis

รัน Analysis ด้วยคำสั่ง !analyze -v flag -v = verbose

!analyze -v

ได้ข้อมูลมากขึ้น รวมถึง Detailed strings สำหรับ Crash arguments สำหรับคนส่วนใหญ่ Way above basic needs แต่หาก Really into controlling system, solving problems, ช่วย Microsoft fix core bugs จะใช้เวลาสักพักรัน Analysis และส่ง Crash report หากทำได้

Symbols ไม่ตรงกับ Kernel!

สิ่งที่ต้องระวัง: หาก Load Symbols ผิด ข้อมูล Crash จะผิด หาก Download Symbols ที่เก่าหรือใหม่กว่า Kernel version จะมีปัญหา เหมือน Linux ตัวอย่างไม่มี Debuginfo package ใน Repo openSUSE 11.2 หลัง Kernel update ผมเจอปัญหานี้ กลับไปที่ Symbols installation:

Symbols เป็นสำหรับ Kernel 7600.16385 (RTM) Timestamp 090713-1255 แต Windows 7 รัน Kernel ใหม่กว่า ผ่าน Updates หลายครั้ง อาจส่งผล Kernel version

Version คือ 7600.16481 ไม่ตรงกัน! หากเจอกรณีนี้และไม่สามารถ Download Symbols ใหม่ได้ ติดต่อ Microsoft Support สำหรับ Third-party drivers อาจไม่มี Symbols ติดต่อ Vendor ได้

ดึง Symbols ที่ถูกต้องออนไลน์!

ใน Windows: หลัง Load crash dump ใน WinDbg เปิด Symbol Search Path window อีกครั้ง นอกจาก Local path เราจะระบุ Online symbols repository ที่เข้าถึงได้จากภายใน Debugger เท่านั้น ดู Microsoft KB article

เฉพาะอย่างนี้:

SRV*c:\symbols*https://msdl.microsoft.com/download/symbols

แทน c:\symbols ด้วย Path symbols ที่ถูกต้องบนเครื่องคุณ Path ไม่จำเป็นต้องใส่ผ่าน Symbol Search Path สามารถระบุผ่าน Command line .sympath command ได้ จะพูดคำสั่ง Debugger อื่นๆ เร็วๆ นี้ รัน Analysis อีกครั้ง (ไม่มี Symbols สำหรับ Nirsoft driver)

เพื่อความสนุก นี่คือ Call stack (รายละเอียดเร็วๆ นี้):

พร้อมแล้ว!

คำสั่งและตัวเลือก Debugger อื่นๆ

โชคดีที่ WinDbg มี Help อุดมสมบูรณ์ ควรช่วยให้เริ่มได้เร็ว หากชอบเรื่องนี้ และหากคุ้นเคยกับ Linux crash analysis ส่วนใหญ่จะคุ้นเคย

ตัวอย่างคำสั่งที่มีประโยชน์: lm (list modules) รัน lml ได้ Short list หรือ lmv Verbose listing สามารถ List user-land modules ด้วย u flag หรือ kernel modules ด้วย k flag

ตัวอย่าง lvm: (รูปภาพ)

ตัวอย่าง lml: สังเกต Drivers บางตัวไม่มี Symbols (Third-party) เพราะ Windows kernel ไม่ได้ Compile ด้วย Symbols เหล่านี้ และไม่พร้อมใช้งาน อาจได้จาก Vendor

ใต้ View menu มี Commands built-in: Watch, Locals, Registers, Memory, Call Stack (เห็นไปแล้ว) และอื่นๆ

ตัวอย่าง: แสดง Processes and Threads, Registers

คำสั่งอื่นๆ: !memusage และ !address Combination ของ Commands และ Options คล้าย bt, ps และคำสั่งอื่นๆ ของ Crash utility แนวคิดรวมเหมือนกัน

Disassembly

แม้ไม่มี Sources อาจอยากดู Binary coded disassembled อาจไม่เข้าใจ Code ทั้งหมด แต่อาจบ่งชี้ว่าเกิดอะไรผิด

Disassembly options และอื่นๆ อยู่ใน Menus

นี่เพียงส่วนเล็กของ Iceberg ของ WinDbg แต่ควรพอสำหรับคนส่วนใหญ่

ต่อไปทำอะไร?

หาก Isolated source ของปัญหาแล้ว ลอง:

Uninstall หรือ Disable bad drivers

ดูว่ามีผลหรือไม่ หากยังคงปัญหา อาจเป็น Hardware problem ที่ซับซ้อน

ลอง Update drivers

อาจแก้ได้ ไปที่ Vendor site หรือ Microsoft Update หา Latest drivers Backup data และ Image system ก่อน เพื่อมี Baseline กลับไป

Google ข้อมูล

เสมอเป็นการกระทำที่ฉลาด หาชื่อ Driver หรือ Bug Check String อาจได้ข้อมูล Workarounds คนควรเคยเจอปัญหาคล้ายกัน

กรองข้อมูลอย่างระมัดระวัง หากลองแก้ไขที่เสนอ ต้องแน่ใจว่าข้อมูลปลอดภัย และ Roll back ไปยัง Known good configuration ได้

อื่นๆ

หากมี Crash information ที่มีประโยชน์ ควรส่งให้ Developers วิเคราะห์ อาจเป็น Microsoft หรือ Third-party ที่พัฒนา Hardware/Software drivers ดูด้านล่าง

ส่งข้อมูล Kernel dump เพื่อวิเคราะห์

ผมไม่มีข้อมูลแน่ชัด หากมีข้อเสนอแนะ ส่งมาให้ครับ ลอง Microsoft links หลายแห่ง แต่ดูเหมือน Out of bounds สำหรับ Casual users

หน้าที่เกี่ยวข้องที่สุด: oca.microsoft.com แต่ดูเหมือน Server-side errors รอแก้ไข/Feedback/Links

Note: ส่ง Crash dumps เรื่องละเอียดอ่อน! Memory dumps อาจมี Private information รวมถึง Passwords และทุกอย่างที่โหลดใน Memory ตอน Crash ระวังก่อน Upload หรือ Mail

สิ่งเพิ่มเติม

การตรวจสอบหน่วยความจำ

หากเจอ Hardware problems ระหว่างทาง อาจต้องการ Memory test Tool ยอดนิยม Open-source: Memtest86+ ใช้เป็น Standalone ISO หรือมาพร้อม Linux distros ทุกตัว Bootable as Live CDs

ยังใช้ Windows Memory Diagnostic ได้

คำแนะนำทั่วไปใน Linux crash ใช้ได้ที่นี่ด้วย!

แค่นี้ก่อน สวัสดีครับ!

อ้างอิง

Driver Verifier
Windows Symbol Packages
Debugging Tools for Windows
Windows SDK
WhoCrashed
Nirsoft website
Nirsoft Nirlauncher (review ของผม)
Nirsoft BlueScreenView
Nirsoft StartBlueScreen
Windows Memory Diagnostic
Memtest86+

วิธีใช้ Symbols ออนไลน์

ดึง Symbols จาก Online server ทันทีจากภายใน Windows Debugger:
Use the Microsoft Symbols Server to obtain debug symbol files

ทรัพยากรอื่นๆ ที่มีประโยชน์

Microsoft articles on kernel memory dump analysis:

บทความที่มีประโยชน์ รวมถึง Registry tweaks, Keyboard use a-la System Request (SysRq), Command line use of Windows Debugger และ Batch (scripted) use

Overview of memory dump file options
Keyboard dump trigger

บทความยอดเยี่ยมโดย Mark Russinovich (Sysinternals, ตอนนี้ Wininternals):

The Case of the Crashed Phone Call

อย่าลืม Built-in help ใน Windows Debugger! มันละเอียดและครอบคลุมมาก สุดท้าย กลับไปที่ Search engines เพื่อนฟรีที่ดีที่สุดในทุกสถานการณ์

สรุป

Wow, ยาวมาก - และ Geek มากกว่าที่คาด ไม่อาจหนี Super-geeko เมื่อจัดการ Kernel stuff อย่างไรก็ตาม ผมหวังว่าคุณจะเพลิดเพลินกับบทความนี้

มีทุกอย่างครบ: Kernel memory dump setup, Verification of drivers, สามเครื่องมือสำหรับตรวจสอบ Kernel crashes รวมถึง WhoCrashed ง่ายๆ จนถึง WinDbg ทรงพลัง ใช้ Nirsoft tools ทั้ง Trigger และ Analyze BSOD ตรวจสอบว่า Machine มี Symbols ติดตั้ง ลงลึก WinDbg ครอบคลุม Commands และ Options หลายอย่าง สุดท้าย Tips ทั่วไปและ Links มากมาย

ผมไม่คิดว่าจะหาบทความที่ Friendly เท่านี้ได้ โดยเฉพาะบทความที่เขียนโดย Linux guy เพื่อประโยชน์และความเพลิดเพลินของ Windows users และนั่นคือความลับ Syntax ต่างกัน แต่ Basic principles เหมือนกัน หากคุณจับหลักการ Linux หรือ Windows kernel crash analysis ได้ คุณจะสบายใจทำงานกับอีกตัวได้ดีขึ้น แค่นี้ครับ ผมเสียพลังแล้ว ลาก่อน!

Cheers.