Đọc file minidump và stop code - Tìm nguyên nhân laptop màn hình xanh

Khi laptop gặp màn hình xanh rồi tự khởi động lại, Windows thường để lại một file minidump ghi mã lỗi, bốn tham số đi kèm và danh sách driver đang nạp tại thời điểm sự cố. Mã lỗi đó gọi là stop code, hay bug check code, gồm một tên viết hoa như IRQL_NOT_LESS_OR_EQUAL và một giá trị thập lục phân như 0x0000000A. Nói đơn giản, stop code là lý do Windows tự dừng để bảo vệ dữ liệu. Đọc đúng hai dữ liệu này bằng WinDbg hoặc BlueScreenView giúp khoanh nguyên nhân về driver, bộ nhớ RAM hay ổ lưu trữ, thay vì cài lại Windows theo cảm tính.

File minidump là gì và Windows cất giữ nó ở thư mục nào

Theo tài liệu Microsoft Learn về đọc small memory dump, file minidump là bản ghi bộ nhớ cỡ nhỏ, chứa lượng thông tin tối thiểu nhưng đủ đáp ứng việc tìm lý do hệ thống dừng. Nội dung gồm thông điệp Stop cùng các tham số, danh sách driver đã nạp, ngữ cảnh bộ xử lý (PRCB) của nhân CPU bị dừng, thông tin tiến trình (EPROCESS), luồng (ETHREAD) và ngăn xếp lời gọi chế độ nhân của luồng gặp sự cố. Nhờ danh sách driver và ngăn xếp này, phần mềm phân tích có thể chỉ ra mô-đun đang thực thi khi Windows buộc phải dừng.

Windows lưu mỗi file minidump trong thư mục %SystemRoot%\Minidump, trên đa số laptop tương ứng với C:\Windows\Minidump. Mỗi file mang tên mã hóa theo ngày; ví dụ Microsoft đưa ra là Mini022900-01.dmp, tức file dump thứ nhất tạo ngày 29/02/2000. Các loại dump lớn hơn như Kernel, Automatic hay Active memory dump được ghi vào một file chung là %SystemRoot%\MEMORY.DMP, và bản sau ghi đè bản trước khi giá trị Overwrite trong cấu hình CrashControl đang bật như mặc định.

Giới hạn của file minidump cũng được Microsoft nêu rõ: vì lượng thông tin ít, những lỗi không do chính luồng đang chạy lúc sự cố gây ra có thể không lộ diện khi phân tích. Trường hợp mỗi lần sập lại báo một mã khác nhau, file MEMORY.DMP kiểu Kernel chứa toàn bộ bộ nhớ nhân sẽ bộc lộ nhiều manh mối hơn.

Cài đặt Startup and Recovery để Windows ghi đủ file dump

Windows chỉ ghi được file minidump hay MEMORY.DMP khi tùy chọn tương ứng được kích hoạt. Đường vào theo Microsoft: mở Control Panel, chọn System and Security, chọn System, bấm Advanced system settings, sang thẻ Advanced rồi bấm Settings ở khu vực Startup and Recovery. Mục System failure có ba ô mặc định đều bật là Write an event to the system log, Send an administrative alert và Automatically restart. Danh sách Write debugging information bên dưới quyết định loại dump, mặc định là Automatic memory dump, ứng với giá trị CrashDumpEnabled bằng 7 trong khóa registry CrashControl.

Lựa chọn Write debugging information	Giá trị CrashDumpEnabled	Nơi lưu file	Yêu cầu tệp hoán trang
(none)	0	Không ghi dump	Không áp dụng
Small memory dump	3	%SystemRoot%\Minidump	Tối thiểu 2 MB trên ổ khởi động
Kernel memory dump	2	%SystemRoot%\MEMORY.DMP	Bản 64-bit, RAM từ 1.374 MB: bằng dung lượng RAM cộng 128 MB
Automatic memory dump (mặc định)	7	%SystemRoot%\MEMORY.DMP	Windows tự nâng tệp hoán trang lên ít nhất bằng RAM khi dump không vừa

Dung lượng Small memory dump được trang hướng dẫn xử lý lỗi dừng của Microsoft ghi là 256 KB, trong khi một tài liệu cũ hơn về tùy chọn dump vẫn ghi 64 KB. Dù chọn loại nào, Windows cần tệp hoán trang (paging file) nằm trên ổ khởi động. Laptop đã tắt paging file hoặc chuyển nó sang ổ khác để dành dung lượng SSD sẽ không ghi được dump; nhật ký System khi ấy có thể xuất hiện sự kiện 46 của nguồn volmgr với nội dung Crash dump initialization failed.

Các giá trị trong hộp thoại nằm ở khóa HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl, trong đó MinidumpDir quy định thư mục chứa minidump, DumpFile quy định đường dẫn MEMORY.DMP và AutoReboot quyết định việc tự khởi động lại. Mọi thay đổi chỉ có hiệu lực sau khi khởi động lại Windows. Microsoft cũng khuyến nghị ổ hệ thống còn trống 10 đến 15% dung lượng, vì file MEMORY.DMP cần đủ chỗ để ghi phần bộ nhớ nhân tại thời điểm sập.

Đọc stop code trên màn hình lỗi và trong nhật ký Event Viewer

Theo Microsoft Learn, màn hình bug check hiển thị stop code và, khi có thể, tên mô-đun đang thực thi. Ví dụ cho Windows 11 bản 24H2 trở đi là CRITICAL_PROCESS_DIED đi cùng mô-đun rdbyss.sys. Microsoft cho biết bản 24H2 cải tiến khâu thu thập crash dump, rút thời gian gián đoạn khi khởi động lại bất ngờ xuống khoảng 2 giây với đa số thiết bị, kèm giao diện mới nền đen vẫn duy trì stop code. Lý do đổi màu và lược bớt chi tiết trên màn hình được phân tích trong bài Microsoft chính thức khai tử BSOD, chuyển sang màn hình đen trên Windows 11.

Màn hình lỗi thường chỉ hiện trong chốc lát rồi laptop tự khởi động lại, nên bỏ chọn ô Automatically restart sẽ duy trì màn hình lỗi đủ lâu để ghi mã. Cách xem lại chắc chắn hơn là nhật ký System trong Event Viewer: sau mỗi lần sập, Windows ghi một sự kiện mức Error, mã 1001, nguồn BugCheck, nội dung dạng The computer has rebooted from a bugcheck, theo sau là mã lỗi, bốn tham số và đường dẫn nơi lưu dump. Microsoft khuyên rà thêm các lỗi nghiêm trọng xảy ra cùng khung giờ để tìm thiết bị hoặc driver liên quan.

Mã trong sự kiện BugCheck viết ở dạng thập lục phân, ví dụ 0x0000000a là IRQL_NOT_LESS_OR_EQUAL. Sự kiện Kernel-Power 41 lại ghi mã ở dạng thập phân; Microsoft nêu ví dụ giá trị 159 tương ứng 0x0000009F, tức DRIVER_POWER_STATE_FAILURE. Khi tra cứu, nên quy đổi về hệ 16 đủ 8 chữ số sau tiền tố 0x. Microsoft cũng lưu ý mã bug check bằng 0 có thể là dấu hiệu sự cố nguồn điện, khi đó laptop không có stop code nào để phân tích.

Dùng WinDbg và lệnh analyze để tìm driver gây lỗi

WinDbg là trình gỡ lỗi chính thức của Microsoft, hỗ trợ Windows 11 và Windows 10 từ bản 1607 trên laptop dùng bộ xử lý x64 lẫn ARM64. Có ba phương án cài đặt: tải bộ cài tại aka.ms/windbg/download, cài qua Microsoft Store, hoặc chạy lệnh winget install Microsoft.WinDbg trong PowerShell. Sau khi mở chương trình, chọn File, Open Crash Dump (phím tắt Ctrl+D) rồi trỏ tới file minidump cần đọc.

Trình gỡ lỗi cần symbol, tức tệp ký hiệu giúp đổi địa chỉ bộ nhớ thành tên hàm. Microsoft hướng dẫn đường dẫn srv*C:\Symbols*https://msdl.microsoft.com/download/symbols, trong đó C:\Symbols là thư mục đệm. Tiếp theo gõ !analyze -v để chạy phân tích chi tiết. Kết quả nêu tên bug check, bốn tham số, các trường MODULE_NAME và IMAGE_NAME chỉ mô-đun chứa lệnh gây lỗi, STACK_TEXT là ngăn xếp của thành phần lỗi. Ví dụ của Microsoft cho mã 9F kết luận Probably caused by : hidusb.sys, tức driver USB HID. Lệnh .bugcheck hiện lại mã, còn lm N T liệt kê mô-đun đã nạp.

Với laptop không tiện cài WinDbg, BlueScreenView phiên bản 1.55 là phương án xem nhanh. Theo trang BlueScreenView của NirSoft, công cụ không cần cài đặt, tự quét thư mục Minidump theo cấu hình CrashControl và hỗ trợ đọc cả dump 32-bit lẫn x64. Bảng phía trên liệt kê thời điểm sập, Bug Check String, Bug Check Code, bốn tham số và cột Caused By Driver; khung dưới tô hồng các driver có địa chỉ nằm trong ngăn xếp lỗi. Trang này chỉ liệt kê hỗ trợ tới Windows 10, nên kết quả trên Windows 11 cần kiểm lại bằng trình gỡ lỗi của Microsoft.

Những stop code hay gặp trên laptop và nhóm nguyên nhân tương ứng

Microsoft duy trì danh mục Bug check code reference, mỗi mã có trang riêng mô tả ý nghĩa, bốn tham số và hướng xử lý. Một số stop code gắn trực tiếp với thành phần đặc thù của laptop như driver đồ họa, chế độ tiết kiệm điện khi ngủ hay ngủ đông, và ổ lưu trữ. Bảng dưới tóm tắt ý nghĩa theo tài liệu của Microsoft, kèm nhóm nguyên nhân cần kiểm trước khi đọc sâu file minidump. Lệnh !analyze -show kèm mã hex cũng hiện mô tả tương tự mà không cần mở file minidump.

Stop code	Mã hex	Ý nghĩa theo Microsoft	Nhóm nguyên nhân cần kiểm
IRQL_NOT_LESS_OR_EQUAL	0x0000000A	Windows hoặc driver chế độ nhân truy cập bộ nhớ phân trang sai địa chỉ khi IRQL đang cao	Driver, dịch vụ hệ thống hoặc BIOS vừa cài, phần mềm diệt virus
PAGE_FAULT_IN_NONPAGED_AREA	0x00000050	Tham chiếu vùng nhớ hệ thống không hợp lệ	Driver, phần mềm diệt virus, phân vùng NTFS hỏng, RAM lỗi
DRIVER_POWER_STATE_FAILURE	0x0000009F	Driver ở trạng thái điện năng mâu thuẫn hoặc không hợp lệ	Driver thiết bị, chế độ tiết kiệm điện, firmware ACPI/BIOS
VIDEO_TDR_FAILURE	0x00000116	Không đặt lại được driver hiển thị sau khi GPU quá thời gian phản hồi	Driver đồ họa, ép xung, tản nhiệt hoặc nguồn điện không đủ
WHEA_UNCORRECTABLE_ERROR	0x00000124	Đã xảy ra lỗi phần cứng nghiêm trọng	Nhiệt độ, RAM, CPU, ép xung
CRITICAL_PROCESS_DIED	0x000000EF	Một tiến trình hệ thống thiết yếu bị dừng	Tệp hệ thống hỏng, driver hoặc phần cứng mới thêm
KERNEL_DATA_INPAGE_ERROR	0x0000007A	Không đọc được trang dữ liệu nhân từ tệp hoán trang vào bộ nhớ	Sector hỏng, kết nối ổ, RAM, virus

Hai mã liên quan GPU có ngưỡng thời gian cụ thể. Theo trang VIDEO_TDR_FAILURE, cơ chế Timeout Detection and Recovery mặc định đặt ngưỡng chờ GPU phản hồi 2 giây; quá thời hạn, Windows thử đặt lại driver, và nếu khôi phục thất bại hoặc có hơn 5 lần TDR trong 1 phút thì hệ thống dừng với mã 0x116. Microsoft ghi nhận lỗi thường xảy ra khi GPU xử lý đồ họa cường độ cao, điển hình lúc chơi game. Trong ví dụ của tài liệu, MODULE_NAME là nvlddmkm, driver đồ họa NVIDIA.

Với KERNEL_DATA_INPAGE_ERROR, tham số thứ hai cho biết hướng đi. Giá trị 0xC000009C hoặc 0xC000016A thường là sector hỏng trên ổ, 0xC000009D là cáp lỏng hoặc bộ điều khiển không nhận ổ, còn 0xC000009A là thiếu tài nguyên nonpaged pool. WHEA_UNCORRECTABLE_ERROR về bản chất thiên hẳn về phần cứng: Microsoft khuyên tắt ép xung, kiểm quạt tản nhiệt và chẩn đoán RAM, chỉ một phần nhỏ trường hợp do driver khiến phần cứng báo lỗi.

Hướng xử lý driver, RAM và ổ lưu trữ sau khi khoanh vùng

Tài liệu xử lý lỗi dừng của Microsoft ước tính 70% bug check do mã driver của bên thứ ba, 10% do phần cứng, 5% do mã của Microsoft và 15% không rõ nguyên nhân vì bộ nhớ hỏng quá nặng để phân tích. Tỷ lệ này giải thích vì sao driver thường được ưu tiên xử lý trước sau khi đọc stop code. Nếu MODULE_NAME trỏ vào driver vừa cập nhật, hướng xử lý là gỡ, cập nhật hoặc quay về bản trước đó; Microsoft cũng khuyên kiểm thiết bị có dấu chấm than trong Device Manager.

Nguồn gốc bug check theo ước tính của Microsoft	Tỷ lệ (%)
Mã driver của bên thứ ba	70
Không xác định được do bộ nhớ hỏng nặng	15
Sự cố phần cứng	10
Mã của Microsoft	5

Khi stop code lặp lại nhưng mỗi lần trỏ tới một driver khác, Driver Verifier giúp bộc lộ driver lỗi: gõ verifier tại cửa sổ dòng lệnh rồi chọn nhóm driver cần kiểm. Microsoft khuyên kiểm theo nhóm 10 đến 20 driver vì công cụ tiêu tốn nhiều CPU và làm suy giảm hiệu năng laptop đáng kể. Nếu Windows không vào được màn hình chính sau khi bật, khởi động Safe Mode (lựa chọn 4, 5 hoặc 6 trong Startup Settings) để tắt nó. Kết quả chỉ trỏ vào mô-đun lõi Windows thì nên gom nhiều file minidump để tìm điểm chung.

Nhóm mã gắn với bộ nhớ cần chạy Windows Memory Diagnostic (tìm Memory trong Control Panel, chọn Diagnose your computer's memory problems), rồi xem mục MemoryDiagnostics-Results trong nhật ký System. Với mã liên quan ổ, lệnh chkdsk /f /r kiểm và sửa lỗi phân vùng sau lần khởi động lại; CRITICAL_PROCESS_DIED thì chạy SFC /scannow để sửa tệp hệ thống. Lỗi xuất hiện ngay sau một bản cập nhật có thể đưa Windows về trạng thái trước bằng điểm khôi phục, quy trình bật và khôi phục được trình bày trong bài System Restore trên Windows 11 - Bật điểm khôi phục, quay lại khi cập nhật lỗi.

Câu hỏi thường gặp (FAQ)

Vì sao thư mục Minidump trống dù laptop vừa bị màn hình xanh?

Thường do ô Write debugging information đang để (none), tệp hoán trang không nằm trên ổ khởi động hoặc nhỏ hơn 2 MB. Nhật ký System có sự kiện 46 của volmgr là dấu hiệu Windows không khởi tạo được crash dump. Trường hợp sự kiện ghi mã bug check bằng 0, Microsoft lưu ý nguyên nhân có thể nằm ở nguồn điện, nên sẽ không có file minidump để đọc.

Có cần cài Windows SDK để dùng WinDbg không?

Không bắt buộc. Phiên bản hiện hành cài riêng được qua Windows Package Manager, Microsoft Store hoặc bộ cài tại aka.ms/windbg/download. Tài liệu xử lý lỗi dừng của Microsoft vẫn nhắc trình gỡ lỗi này thuộc gói Debugging Tools for Windows trong Windows SDK, đó là cách cài truyền thống dành cho môi trường phát triển. Cả hai cách đều mở được file minidump.

CRITICAL_PROCESS_DIED do tiến trình nào gây ra?

Microsoft liệt kê các dịch vụ hệ thống thiết yếu gồm csrss.exe, wininit.exe, logonui.exe, smss.exe, services.exe, conhost.exe và winlogon.exe. Khi một tiến trình trong nhóm này bị dừng hoặc trạng thái bị hỏng, Windows dừng với mã 0x000000EF. Hướng xử lý gồm chạy SFC /scannow, gỡ driver hoặc phần cứng mới thêm và kiểm phiên bản BIOS mới.

BlueScreenView và WinDbg chỉ ra hai driver khác nhau thì xem thế nào?

BlueScreenView chỉ đánh dấu driver có địa chỉ nằm trong ngăn xếp lỗi, còn lệnh !analyze -v của WinDbg phân tích tự động với symbol của Microsoft. Khi hai kết quả lệch nhau, nên đọc thêm trường STACK_TEXT và so sánh nhiều file minidump để tìm driver lặp lại.