Màn hình xanh chết chóc của Windows (BSOD) không phải thứ bạn muốn thấy trên màn hình máy tính, trừ khi bạn đang dùng screensaver nhất định hoặc test phần mềm. Nhưng thỉnh thoảng, người dùng Windows vẫn trải qua trường hợp thất bại phần mềm tối thượng, đó là của chính kernel, dẫn đến treo hoàn toàn hệ thống và cuối cùng là crash.

Trong Linux, tình huống này được gọi là kernel panic. Trong Windows, nó gọi là BSOD. Nhưng nó lên tới cùng một điều: một ngoại lệcritical, không thể khôi phục trong lõi của hệ thống, kernel và các driver đi kèm.

Giới thiệu vi mô

Sau khi làm một series siêu dài và ultra-geeky về crash Linux, bắt đầu từ công cụ kernel crash dump, tiếp tục với thiết lập trên openSUSE và CentOS và đỉnh điểm với phân tích sâu, tôi muốn cung cấp cho người dùng Windows một phiên bản hơi ngắn hơn và ít geeky hơn về phân tích BSOD. Có hai lý do: một, tôi không thể đi sâu như muốn, vì nguồn Windows đóng; hai, tôi không thành thạo trong việc đàm phán kernel Windows như tôi làm với Linux. Dù sao, hướng dẫn này vẫn sẽ khá nerdy và vượt xa yêu cầu, nhu cầu hoặc mong muốn của người dùng trung bình. Tuy nhiên, nếu bạn muốn tìm hiểu thêm về nội tại Windows và có kỹ năng mới giúp chẩn đoán vấn đề hệ thống cốt lõi, bạn đã đến đúng nơi.

Bây giờ hãy bắt đầu.

Mục Lục

1. Câu hỏi
2. 1. Nguyên nhân gây ra Màn hình xanh chết chóc?
3. Bật thu thập BSOD
4. Thu thập BSOD
   1. Driver Verifier
5. Chẩn đoán BSOD
   1. Windows Symbol Packages
   2. Công cụ phân tích BSOD 1: WhoCrashed
   3. Công cụ phân tích BSOD 2: Nirsoft
   4. Công cụ phân tích BSOD 3: Windows Debugger (Windbg)
6. Ví dụ BSOD
   1. Kích hoạt BSOD (sử dụng StartBlueScreen)
7. Phân tích BSOD
   1. Kết quả WhoCrashed
   2. Kết quả Nirsoft BlueScreenView
   3. Kết quả Windows Debugger
   4. Lấy symbols đúng trực tuyến!
   5. Các lệnh & tùy chọn Debugger khác
   6. Tiếp theo?
   7. Gửi thông tin kernel dump để phân tích
8. Thêm thứ
   1. Chẩn đoán bộ nhớ
9. Tham khảo
   1. Hướng dẫn symbols trực tuyến
   2. Tài nguyên hữu ích khác
10. Kết luận

Câu hỏi

Trước khi đào sâu vào thuật ngữ kỹ thuật, hãy trả lời một vài câu hỏi về BSOD.

Nguyên nhân gây ra Màn hình xanh chết chóc?

Không có câu trả lời đơn giản. Người dùng Windows lâu năm sẽ đã học được rằng một số người dường như gặp BSOD rất thường xuyên trong khi người khác không bao giờ thấy chúng, trong khi tất cả chạy Windows khá giống nhau.

Phổ rộng trải nghiệm xuất phát từ việc BSOD thường không bao giờ do thành phần Microsoft Windows gây ra. Mặc dù hầu hết mọi người thích đổ lỗi cho Windows vì crash, chúng hiếm khi hoặc không bao giờ do chính hệ điều hành gây ra.

Kinh nghiệm cá nhân của tôi như sau:

Trên hai máy Windows với tổng uptime 10 năm, tôi chỉ gặp BSOD hai lần, một lần trên mỗi máy. Như sự việc, hai lần crash xảy ra cách nhau chưa đầy một giờ.

Bạn có thể cho rằng đây do cập nhật Windows gần đây hoặc một trong các chương序 đang chạy. Thật vậy, đây dường như là một dấu vết tốt, đặc biệt xem xét hai máy có phần cứng và phần mềm gần như giống hệt nhau. Nhưng đây không phải lỗi phần mềm.

Điều thực sự xảy ra là card đồ họa bị quá nóng. Đơn giản vậy. Đó là một ngày nóng bức và card đồ họa vượt quá phạm vi nhiệt độ bình thường.

Tất cả các trường hợp BSOD khác tôi gặp trên máy khác đều liên quan đến driver xấu, hoạt động sai hoặc có bug được cài đặt bởi phần mềm hoặc phần cứng, bao gồm card Wireless, chương trình bảo mật và tương tự. Tôi chưa bao giờ thấy một trong những thành phần cốt lõi của Windows kêu lên. Chỉ để rõ ràng, chúng ta nói về sử dụng gia đình ở đây.

Bây giờ chúng ta đã biết mình đang nói về gì, hãy bắt đầu khoa học.

Bật thu thập BSOD

Để tận dụng tốt các công cụ hệ thống tích hợp, bạn cần cho Windows thu thập crash dump, gọi là minidump. Điều này tương tự như bật LKCD hoặc Kdump trong Linux. Mặc định, Windows kernel memory dumps được bật, vì vậy bạn chỉ cần xem và đảm bảo cài đặt đúng.

Bạn có thể cấu hình thu thập BSOD bằng cách right-click vào Computer trong menu Explorer, Properties, System, Advanced, Startup and Recovery. Ở nửa dưới, dưới System failure, bạn cần cấu hình các tham số.

Bạn có thể chọn có ghi log crash vào system log, tự động khởi động lại hệ thống hoặc ghi đè file hiện có. Tôi khuyên không ghi đè file. Giữ lại thông tin để so sánh và phân tích sau này luôn là điều tốt.

Một điều khác cần chú ý là hộp thả xuống Write debugging information. Ở đây, bạn có thể chỉ định phần bộ nhớ nào bạn muốn lưu khi máy crash. Điều này rất giống với Kdump DUMPLEVEL.

Bạn có các tùy chọn sau:

Small memory dump - Chỉ file cơ bản chứa thông tin crash. Giá trị hạn chế, vì bạn không có trace của các executable và DLL được load vào bộ nhớ. Trên Windows XP, file này 64K. Trên Windows 7, là 128K.

Kernel memory dump - Sẽ dump phần bộ nhớ chứa kernel, điều này nên đủ trong hầu hết trường hợp, vì kernel crash sẽ do bug kernel hoặc driver gây ra.

Complete memory dump - Sẽ dump toàn bộ nội dung RAM.

Khi bạn hài lòng với cài đặt, nhấp OK. Chúng ta có thể bắt đầu phân tích ngay.

Thu thập BSOD

Tìm nguyên nhân gốc rễ của crash có thể không dễ dàng. Vấn đề phần cứng có thể và sẽ gây ra hành vi thất thường và không thể dự đoán, có thể biểu hiện dưới các triệu chứng khác nhau, không cho bạn xác định vấn đề. Vấn đề phần mềm nên dễ chẩn đoán hơn.

Nếu và khi BSOD xảy ra, nhiệm vụ đầu tiên của bạn nên là cố gắng cô lập các thành phần có vấn đề và khiến chúng kích hoạt BSOD lại. Nếu bạn có thể tái hiện vấn đề, bạn sẽ có thể giải quyết nó.

Driver Verifier

Nếu bạn đang cố gắng troubleshoot BSOD, bạn nên dùng Driver Verifier.

Driver Verifier là công cụ mạnh mẽ và có thể làm nhiều thứ, như chạy driver trong memory pool cách ly, không chia sẻ bộ nhớ với thành phần khác, cung cấp áp lực bộ nhớ cực đoan, xác thực tham số, kiểm tra unload, và hơn thế nữa.

Để bắt đầu dùng Verifier, tìm executable và khởi động nó. Trên Windows XP, nhấp Start > Run > Verifier. Trên Windows 7, gõ Verifier trong hộp tìm kiếm inline và nhấn Enter.

Khi Verifier đã khởi động, bạn sẽ cần cấu hình nó. Bạn có thể tạo cài đặt tiêu chuẩn, nên hoạt động cho hầu hết mọi người, hoặc cấu hình tùy chỉnh, chủ yếu hữu ích cho nhà phát triển code. Bạn cũng có thể hiển thị tasks, xóa tasks hoặc hiển thị thông tin cho driver đang được verify hiện tại.

Trong màn hình menu tiếp theo, bạn cần chọn driver nào bạn muốn kiểm tra: driver không ký, driver xây dựng cho phiên bản Windows cũ hơn hoặc tất cả driver. Vì bạn chưa biết vấn đề thực sự là gì, hãy chọn tất cả.

Bước tiếp theo là reboot. Verifier sẽ tiêu thụ nhiều CPU và làm chậm máy đáng kể. Bạn cũng có thể gặp crash thêm. Verifier sẽ vô hiệu hóa driver lỗi giữa các BSOD và reboot cho đến khi bạn cuối cùng đạt desktop. Bạn cũng có thể đã thu thập một vài minidump.

Bây giờ bạn có thể vô hiệu hóa Verifier. Khởi động ứng dụng và xóa cài đặt hiện có.

Hơn nữa, nếu máy của bạn không thể boot vào desktop vì Verifier, bạn có thể vô hiệu hóa công cụ bằng cách khởi chạy Last Known Good configuration hoặc boot vào Safe mode.

OK, minidump đã thu thập, hãy phân tích.

Chẩn đoán BSOD

Để chẩn đoán minidump, bạn sẽ cần một số công cụ. Nếu bạn nhớ các hướng dẫn Linux, điều kiện tiên quyết để dùng crash là có kernel compile với debug symbols và cài đặt debuginfo packages.

Windows Symbol Packages

Vâng, Windows không khác. Để phân tích đúng, bạn sẽ cần symbols. Bạn sẽ cần tải xuống và cài đặt symbols khớp chính xác với phiên bản kernel Windows của bạn. Nếu không, phân tích sẽ không chính xác. Lại không khác Linux, về mặt này.

Tôi sẽ chỉ cho bạn sau một ví dụ về điều này.

Sau khi symbols được cài đặt, bạn sẽ cần công cụ để đọc và giải mã dữ liệu crash. Tôi sẽ chỉ cho bạn ba công cụ như vậy, bắt đầu từ dễ nhất và dần leo lên đỉnh geek.

Công cụ phân tích BSOD 1: WhoCrashed

WhoCrashed là công cụ đơn giản, hiệu quả cho bạn tìm ra driver nào gây crash máy. Nó rất dễ dùng và không đòi hỏi chuyên môn, mặc dù phân tích đúng đắn thì cần. Công cụ yêu cầu Windows Debugger được cài đặt.

Công cụ phân tích BSOD 2: Nirsoft

Nếu bạn thậm chí bán nghiêm túc về Windows, bạn nên đã nghe về công cụ Nirsoft, một bộ tiện ích Windows cực kỳ đa năng được phát triển và duy trì bởi Nir Sofer. Cụ thể, chúng ta muốn công cụ chẩn đoán gọi là BlueScreenView, dùng để phân tích Windows kernel memory dump. Tốt nhất, công cụ nhỏ hữu ích này được bao gồm trong hộp công cụ kiểu Swiss Army knife siêu mạnh gọi là Nirlauncher, một bộ sưu tập hơn một trăm ứng dụng do Nir phát triển. Không phải không lý do website của Nir xuất hiện trong danh sách Greatest của tôi.

Hơn nữa, Nir Sofer cũng có công cụ để kích hoạt BSOD, để bạn có thể mô phỏng crash. Công cụ này gọi là StartBlueScreen và được bao gồm trong gói Nirlauncher. Để biết thêm chi tiết về Nirlauncher, bạn có thể muốn đọc review của tôi về phần mềm này.

Chúng ta sẽ nói về cả hai chương trình này rất sớm.

Công cụ phân tích BSOD 3: Windows Debugger (Windbg)

Windows Debugger là công cụ đa năng, bạn có thể dùng để troubleshoot mọi thứ, bao gồm driver, ứng dụng, và dịch vụ trên hệ thống Windows.

Windows Debugger được bao gồm trong Windows SDK.

Trên Windows 7, khi cài đặt Debugger, bạn có thể gặp lỗi .NET Framework 4. Bạn có thể bỏ qua nó, miễn là bạn không cố gắng làm việc với ứng dụng phát triển trong .NET framework. Trong trường hợp của chúng ta, chúng ta có thể tiếp tục an toàn.

Trong menu cài đặt, bạn có thể chọn thành phần nào bạn muốn. Chúng ta muốn Debugging Tools for Windows, dưới Common Utilities.

Windows debugger trông không quá thú vị khi khởi chạy, nhưng nó là công cụ mạnh mẽ cần khá nhiều thời gian để quen và làm việc đúng cách. Nó tương tự GDB trong Linux, vì nó có thể dùng để kiểm tra nguồn, attach vào tiến trình đang chạy, kiểm tra kernel dump, và hơn thế nữa.

Ví dụ BSOD

Kích hoạt BSOD (sử dụng StartBlueScreen)

Để thấy các công cụ này hoạt động, chúng ta cần một BSOD. Chạy Verifier trên máy Windows 7 của tôi không tạo ra tác hại. Vì vậy chúng ta sẽ phải thử công cụ StartBlueScreen của NirSoft, mà tôi đã nhắc trước đó.

StartBlueScreen là công cụ dòng lệnh. Nó cần chạy với một số tham số, sẽ kích hoạt BSOD. Để thực thi BSOD, bạn cần dùng tài khoản Administrator trên hộp Windows của bạn.

Trên Windows 7, bật tài khoản administrator ẩn có thể hơi khó khăn, nhưng chúng ta sẽ có hướng dẫn riêng cho đó sớm. Thực tế, làm điều tương tự trên Windows XP cũng không tầm thường. Lại một lần, chúng ta sẽ thảo luận riêng.

Khi đã đăng nhập với tư cách administrator, chạy StartBlueScreen từ dòng lệnh. Nir Sofer liệt kê một số ví dụ trên website của ông, nên chúng ta sẽ dùng một trong số đó:

StartBlueScreen.exe 0x12 0 0 0 0

Điều này rất giống chạy echo c > /proc/sysrq-trigger trên Linux, với System Request được bật. Thật vậy, sau vài giây, bạn nên thấy BSOD nổi tiếng:

Để máy hoàn thành dump. Sau khi nó khởi động lại, chúng ta có thể phân tích crash. Bạn có thể thấy thông báo pop up sau khi máy reboot. Đã có gợi ý về chuyện gì xảy ra, chi tiết hơn sắp tới.

Phân tích BSOD

Hãy xem mỗi trong ba công cụ cho chúng ta gì.

Kết quả WhoCrashed

Bạn có một drilldown rất đơn giản về chuyện gì xảy ra. Đối với hầu hết mọi người, thông tin này đủ để bắt đầu. Biết tên driver gây sự có thể giúp cô lập vấn đề.

Chúng ta thấy lỗi là unknown kernel trap do driver nirsoftbluescreendriver.sys gây ra. Vâng, điều này dự đoán được. Tôi đoán code của Nir tương tự ví dụ null-pointer kernel driver của tôi.

Kết quả Nirsoft BlueScreenView

BlueScreenView cung cấp thông tin chi tiết hơn. Nó sẽ tự động load file minidump tìm thấy trong thư mục gốc. Trong view trên, bạn sẽ thấy một số thông tin cơ bản về crash, bao gồm Bug Check String, giống hệt Panic String trong file phân tích crash Linux, và Bug Check Code, tương tự Kernel Page Error.

Trong ngăn dưới, bạn có danh sách tất cả driver load trong bộ nhớ, với những cái liên quan đến crash được đánh dấu màu salmon - tôi đoán đó là tên màu. Nếu bạn muốn xem chỉ call trace cho tiến trình crash, bạn có thể thay bộ lọc trong menu Options.

Và bạn cũng có thể load màn hình BSOD gốc (phong cách XP):

Điều này đôi khi hữu ích. Ví dụ, xem phần Technical Information. Bạn có tên driver xấu và địa chỉ bộ nhớ. Dùng аналоги Linux thêm lần, điều này giống như exception RIP trong task backtrace. Thật vậy, hãy tập trung vào stack:

Chúng ta có tên executable và địa chỉ bộ nhớ. Về lý thuyết, nếu chúng ta có source, chúng ta có thể xác định chính xác dòng code nào dẫn đến kernel crash. Vì chúng ta không có, điều tốt nhất bạn có thể làm là thu thập càng nhiều dữ liệu càng tốt và gửi thông tin cho Microsoft để phân tích thêm. Chúng ta sẽ nói về đó sớm.

Nói chung, Microsoft sẽ phát hành bản vá cho crash trong thành phần Microsoft, vì vậy câu hỏi là, bạn biết nkrnlpa.exe có phải thành phần Microsoft không? Vâng, nếu bạn double click vào bất kỳ mục nào hoặc right-click chọn properties, bạn sẽ có thông tin chi tiết.

Như bạn thấy, làm việc với crash Windows không khác biệt nhiều so với Linux. Tuy nhiên, bạn có thể muốn biết chính xác chuyện gì xảy ra, vì vậy bạn sẽ cần source, không phải lúc nào cũng sẵn có. Lại nói, điều này không luôn có thể trên Linux, đặc biệt nếu bạn có driver proprietary load vào kernel, như Nvidia. Hãy lưu ý phiên bản file - điều này quan trọng khi chúng ta muốn dùng symbols, mà chúng ta sẽ sớm thấy hoạt động.

Kết quả Windows Debugger

Windows Debugger là phức tạp và mạnh mẽ nhất trong ba công cụ đã đề cập. Trước khi bắt đầu, bạn nên biết rằng nó cần thời gian, kiên nhẫn và kiến thức làm việc với Debugger. Thực tế, mặc dù có vẻ tự tin, tôi khá thiếu kinh nghiệm với công cụ này, mặc dù common sense và kiến thức phổ quát khi nói đến phân tích crash áp dụng tốt ở đây. Nếu bạn biết nghề của mình dọc theo những con đường code tối tăm trong một hệ thống, bạn sẽ ổn trong tất cả các hệ thống khác.

Quyền hạn

Nếu bạn không làm việc với tư cách Administrator, bạn sẽ không có quyền truy cập memory dump, vì lý do bảo mật hiển nhiên. Bạn có thể cần copy file ra hoặc đặt quyền đúng.

Load symbols

Điều đầu tiên bạn cần làm là load symbols. Công cụ có thể không biết vị trí symbols trên ổ đĩa, vì path có thể không được lưu trong biến môi trường. Để nhấn mạnh, tôi sẽ load crash dump mà không chỉ định symbols.

Chú ý chuỗi lỗi: ERROR: Module loaded completed but... Đây là chuyện gì xảy ra khi không load symbols, làm cho phân tích khá vô nghĩa. Thật vậy, nếu bạn chạy phân tích, bạn sẽ nhận được một vài dấu hỏi, vì debugger không thể đoán driver được map như thế nào trong bộ nhớ tại thời điểm crash.

Bạn có thể kiểm tra symbols path hiện tại bằng cách thực thi lệnh .sympath. Nó sẽ trống trừ khi bạn đã load symbols. Chúng ta sẽ load symbols ngay bây giờ.

Sau khi load symbols, bạn không cần mở lại file minidump. Bạn chỉ cần reload nó. Bạn có thể làm điều đó bằng cách check hộp Reload trong cửa sổ Symbol Search Path hoặc chạy .reload trong dòng lệnh debugger, được đánh dấu bằng kd> ở dưới cửa sổ lệnh.

Bây giờ bạn sẽ thấy output khác:

Chạy phân tích

Chạy phân tích được thực hiện bằng cách thực thi lệnh !analyze -v. Cờ -v nghĩa là verbose.

!analyze -v

Bây giờ bạn sẽ thấy nhiều thông tin hơn, bao gồm chuỗi chi tiết cho các đối số crash. Đối với hầu hết mọi người, điều này cách xa nhu cầu cơ bản, nhưng nếu bạn thực sự vào việc kiểm soát hệ thống, giải quyết vấn đề và thậm chí giúp Microsoft sửa lỗi cốt lõi, thì bạn sẽ dành vài phút chạy phân tích và gửi báo cáo crash, nếu có thể.

Symbols không khớp kernel!

Đây là điều bạn nên chú ý. Nếu bạn load symbols sai, thông tin về crash sẽ sai. Thật vậy, nếu bạn đã tải symbols cũ hơn hoặc mới hơn phiên bản kernel của bạn, bạn sẽ có vấn đề.

Điều này tương tự ví dụ Linux, không có debuginfo package trong repository trên openSUSE 11.2 sau khi update kernel. Thực tế, tôi đã gặp vấn đề này. Hãy quay lại cài đặt symbols:

Symbols dành cho kernel 7600.16385, mà, nếu tôi không nhầm là RTM. Chú ý timestamp và revision chính xác - 090713-1255. Mặt khác, Windows 7 đang chạy kernel mới hơn, cộng với đã trải qua một số cập nhật, cũng có thể ảnh hưởng đến phiên bản kernel.

Phiên bản là 7600.16481. Hai cái không khớp! Nếu bạn gặp trường hợp như này và không thể tải phiên bản symbols kernel mới hơn, bạn nên liên hệ Microsoft để hỗ trợ. Bạn rất có thể không có symbols cho driver bên thứ ba. Bạn có thể liên hệ nhà cung cấp thứ ba, cũng vậy.

Lấy symbols đúng trực tuyến!

Bây giờ, về phía Windows, đây là những gì bạn cần làm để lấy symbols mới nhất cho hệ điều hành của bạn. Sau khi load crash dump trong Windows Debugger, mở lại cửa sổ Symbol Search Path. Ngoài local path, chúng ta sẽ chỉ định online symbols repository, chỉ truy cập được từ trong Debugger. Để biết thêm thông tin, xem bài KB của Microsoft này.

Cụ thể, bạn muốn điều sau:

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

Thay thế c:\symbols bằng symbols path đúng trên máy của bạn. Path không cần nhập qua Symbol Search Path. Nó cũng có thể chỉ định trên dòng lệnh bằng lệnh .sympath. Chúng ta sẽ thảo luận các lệnh Debugger khác và tùy chọn rất sớm. Và hãy chạy phân tích lại. Tất nhiên, chúng ta sẽ không có symbols cho driver Nirsoft.

Để thêm thú vị, đây là call stack (sẽ nói thêm về đó sớm):

Và chúng ta xong!

Các lệnh Debugger & tùy chọn khác

May mắn cho bạn, Windows Debugger có help cực kỳ chi tiết và phong phú, sẽ giúp bạn bắt đầu ngay lập tức, miễn là bạn thích loại thứ này. Và nếu bạn quen với phân tích crash Linux, hầu hết thứ sẽ quen thuộc.

Ví dụ, một lệnh rất hữu ích là lm (list modules). Bạn có thể chạy lml để lấy danh sách ngắn gọn các module hoặc lmv để liệt kê đầy đủ, verbose. Bạn cũng có thể liệt kê module user-land với cờ u hoặc module kernel với cờ k.

Dưới đây là ví dụ lvm:

Dưới đây là ví dụ lml; lưu ý một số driver không có symbols, chính là các driver bên thứ ba, vì kernel Windows không được compile với symbols này, cũng không có sẵn. Bạn có thể lấy từ vendor.

Dưới menu View, bạn có một vài lệnh built-in, nên bạn không cần săn chúng trên dòng lệnh. Bạn có Watch, Locals, Registers, Memory, Call Stack, mà chúng ta đã thấy trước đó, và hơn thế nữa.

Ví dụ, bạn có thể muốn hiển thị Processes and Threads.

Hoặc registers:

Các lệnh khác bạn có thể muốn dùng bao gồm !memusage và !address. Kết hợp các lệnh và tùy chọn chúng ta vừa thấy khá tương tự bt, ps và các lệnh khác dùng bởi crash utility. Ý tưởng tổng thể là giống nhau.

Disassembly

Ngay cả khi bạn không có source, bạn có thể muốn xem binary được disassembled. Bạn có thể không hiểu hoàn toàn chuyện gì xảy ra trong code, nhưng nó có thể cho bạn chỉ dẫn gì đã sai.

Các tùy chọn disassembly, cũng như nhiều cái khác, có sẵn trong menu.

Đây là nó:

Và bạn có thể nhúng các cửa sổ khác nhau vào giao diện chính.

Đây chỉ chạm đến ngọn núi băng của những gì Windows Debugger có thể làm, nhưng tôi đoán nó đủ cho hầu hết mọi người.

Tiếp theo?

Nếu bạn đã cô lập nguồn vấn đề, bạn có thể thử một vài điều:

Gỡ cài đặt hoặc vô hiệu hóa driver xấu

Xem có khác biệt không, tức là nếu bạn có thể, vì bạn có thể mất chức năng quan trọng. Nếu vấn đề vẫn tiếp diễn, bạn có thể có vấn đề phức tạp liên quan đến phần cứng.

Thử cập nhật driver

Điều này có thể hoạt động. Đi đến trang vendor hoặc Microsoft update và lấy driver mới nhất cho phần cứng và phần mềm của bạn. Nhớ backup dữ liệu và tạo ảnh hệ thống, để bạn có baseline để quay lại.

Google thông tin

Luôn là một nước đi khôn ngoan. Tìm tên driver hoặc Bug Check String có thể cho ra thông tin hữu ích, bao gồm workaround cho vấn đề. Nói chung, ai đó nên đã từng thấy hoặc nghe hoặc trải qua điều gì đó tương tự vấn đề của bạn.

Như luôn, lọc dữ liệu cẩn thận và thận trọng. Nếu bạn quyết định thử một số giải pháp được đề xuất, hãy chắc chắn dữ liệu của bạn an toàn và bạn có thể roll back về cấu hình tốt, đã biết.

Khác

Nếu bạn có thông tin crash hữu ích, bạn nên thử gửi cho nhà phát triển để phân tích. Có thể là Microsoft hoặc bên thứ ba phát triển driver phần cứng hoặc phần mềm cho Windows. Xem bên dưới.

Gửi thông tin kernel dump để phân tích

Tôi không có gì vững chắc ở đây. Nếu bạn có đề xuất, hãy gửi. Tôi đã thử một số link Microsoft, nhưng chúng dường như out of bounds cho người dùng bình thường.

Trang liên quan nhất là oca.microsoft.com, nhưng dường như bị lỗi server-side. Tự do sửa tôi và/hoặc gửi phản hồi và link của bạn.

Lưu ý: Gửi crash dump là vấn đề nhạy cảm! Memory dump có thể chứa thông tin riêng tư, bao gồm mật khẩu và gần như bất cứ thứ gì khác load vào bộ nhớ tại thời điểm crash. Hãy nhận thức điều này trước khi upload hoặc gửi mail dữ liệu crash của bạn.

Thêm thứ

Chẩn đoán bộ nhớ

Nếu bạn đối mặt với vấn đề phần cứng không liên tục, bạn có thể muốn chạy test bộ nhớ trên máy. Công cụ open-source phổ biến nhất là Memtest86+. Công cụ có thể dùng như standalone ISO; nó cũng đi kèm với phần lớn các bản phân phối Linux, tất cả bootable như live CD.

Bạn cũng có thể dùng Windows Memory Diagnostic.

Hơn nữa, lời khuyên chung trong Linux crash cũng áp dụng ở đây!

Và đó sẽ là tất cả, các quý vị!

Tham khảo

Driver Verifier

Windows Symbol Packages

Debugging Tools for Windows

Windows SDK

WhoCrashed

Website Nirsoft

Nirsoft Nirlauncher (review của tôi)

Nirsoft BlueScreenView

Nirsoft StartBlueScreen

Windows Memory Diagnostic

Memtest86+

Hướng dẫn symbols trực tuyến

Lấy symbols từ server trực tuyến live từ trong Windows Debugger:

Sử dụng Microsoft Symbols Server để lấy file debug symbol

Tài nguyên hữu ích khác

Bài viết Microsoft về phân tích kernel memory dump:

Bài viết hữu ích, bao gồm registry tweaks, sử dụng keyboard a-la System Request (SysRq), sử dụng dòng lệnh Windows Debugger và sử dụng batch (scripted).

Tổng quan các tùy chọn file memory dump

Keyboard dump trigger

Bài viết tuyệt vời của Mark Russinovich (Sysinternals, giờ là Wininternals):

The Case of the Crashed Phone Call

Đừng quên built-in help trong Windows Debugger! Nó rất kỹ và chi tiết. Cuối cùng, chúng ta quay lại công cụ tìm kiếm Internet, người bạn tốt nhất miễn phí trong mọi tình huống.

Kết luận

Wow, đó là dài - và geeky hơn tôi dự kiến. Rõ ràng, bạn không thể thoát khỏi super-geeko khi xử lý kernel stuff. Tuy nhiên, tôi hy vọng bạn đã thích bài viết này.

Nó có khá nhiều thứ: với thiết lập kernel memory dump, xác minh driver, ba công cụ kiểm tra kernel crash, bao gồm công cụ đơn giản như WhoCrashed lên đến Windows Debugger mạnh mẽ. Chúng ta cũng dùng công cụ Nirsoft để cả kích hoạt và sau đó phân tích BSOD. Chúng ta đảm bảo máy có symbols cài đặt. Chúng ta nhìn sâu hơn vào những gì Windows Debugger cung cấp, bao gồm một vài lệnh và tùy chọn. Cuối cùng, một số mẹo chung và một kho link.

Tôi không nghĩ bạn sẽ tìm thấy nhiều bài viết thân thiện như cái này, đặc biệt không phải bài viết bởi một người Linux, cho lợi ích và niềm vui của người dùng Windows. Và đó chính là bí mật. Cú pháp khác nhau, nhưng nguyên tắc cơ bản giống hệt nhau. Khi bạn nắm bắt được phân tích kernel crash Linux hoặc Windows, bạn sẽ thoải mái hơn nhiều làm việc với cái kia. Và đó là tất cả. Tôi đã hết hơi. Hẹn gặp lại!

Chúc vui.