Nếu bạn đọc Dedoimedo trong mười một năm qua, bạn biết tôi không quá thích phần mềm bảo mật. Nhưng tôi test các sản phẩm bảo mật, chỉ để xem chúng hành xử thế nào trong bối cảnh rộng hơn. Thực hành vô tư này cũng cho phép tôi so sánh và đánh giá phần mềm, đặc biệt đối với chuẩn vàng của chương trình bảo mật Windows, EMET vinh quang, hữu ích và không rắc rối nhất. Có.
Dù sao, vài tháng trước, tôi chạy quét với MalwareBytes Anti-Malware (MBAM) trên máy Windows 7, và giữa chừng quét, tôi gặp Blue Screen of Death (BSOD). Không tốt. Sau khi khôi phục, tôi bắt đầu "mẹ của tất cả cuộc điều tra". Theo tôi.
Thiết lập hoạt động, sự thật bổ sung
Trước khi bắt đầu tìm hiểu chuyện gì xảy ra, hãy cho tôi thêm thông tin. Nếu không, bài tập này vô nghĩa. Thứ nhất, BSOD. Nói chung, Windows cực kỳ ổn định trong môi trường gia đình – server là chủ đề riêng – và thực sự không có lý do bạn nên trải qua crash hệ thống nghiêm trọng do bug kernel nội bộ Windows.
Trong khoảng 15 năm sử dụng Windows nặng, trải qua khoảng một chục hệ thống khác nhau, tôi chỉ gặp BSOD vài lần – do card đồ họa quá nóng, do driver đồ họa lỗi, một sự kiện buồn chúng ta đã nói kỹ, và một lần khi kết nối smartphone qua cáp USB. Đó là tất cả.
Thực tế, quay lại tuyên bố trước, những lần bạn nên thấy kernel crash chỉ do lỗi phần cứng hoặc driver lỗi, thực sự, điều này phù hợp hoàn hảo với lịch sử sử dụng của tôi. Điều này cũng đi de đôi với kinh nghiệm làm việc khá rộng của tôi với Linux, tôi đã ghi chép trong cuốn sách Linux crash của mình. Bản chất: phần cứng, system call xấu, hoặc bug kernel thuần túy. Đó là tất cả, và cái cuối ít xảy ra nhất.
Nhưng bây giờ, tôi đối mặt với vấn đề driver ataport.sys – đây là driver của Microsoft, và nó không nên có bug. Vậy, chúng ta có vấn đề phần cứng? Và nếu có, loại nào? Vẫn, trước khi vội vàng, tôi muốn thu hút sự chú ý của bạn về nghệ thuật giải quyết vấn đề và cách nó phải được làm, chậm rãi, cẩn thận, có phương pháp.
Phân tích, bước đầu
Được rồi. Hãy hiểu chuyện gì xảy ra. Chúng ta biết cách phân tích BSOD, vì tôi đã chỉ cho bạn trong hướng dẫn BSOD chi tiết. Sử dụng một trong các công cụ có sẵn trong hướng dẫn, chúng ta có thể phân tích crash dump. Tôi chọn BlueScreenView của Nirsoft. Rút ra crash do:
ataport.SYS+1ff3c
Và lỗi cụ thể là KERNEL_DATA_INPAGE_ERROR. Kiểm tra một số đối số khác trong core memory, điều này chỉ ra lỗi phần cứng trong thao tác kernel, dẫn đến crash hệ thống. Cho đến nay đơn giản.
Nhưng tại sao crash xảy ra DURING quét MBAM?
Đây là câu hỏi thú vị? Thực sự, chúng ta giờ cần tìm ra xem:
- Vấn đề này chỉ dành riêng cho MBAM.
- Một vấn đề hệ thống chung hơn mà tình cờ biểu hiện trong lúc quét.
Để xác định khẳng định a) hay b) đúng, chúng ta cần lặp lại hoàn cảnh crash. Một vài chi tiết thêm: Máy Windows 7, không phần mềm bảo mật khác ngoài EMET, với container TrueCrypt được mount. Điều này quan trọng và liên quan, vì đây là phần mềm khác dùng driver lớp lưu trữ (storage layer) và có thể tiềm ẩn ảnh hưởng kết quả tình huống này.
Tôi chạy quét lần thứ hai – nhưng lần này hệ thống không crash, container TrueCrypt và tất cả. Tuy nhiên, tôi thấy lỗi trong Event Log, Event ID 11 đọc:
The driver detected a controller error on \Device\Ide\IdePort1.
Tôi chưa bao giờ thấy loại lỗi này trước đây, và thời điểm trùng với quét MBAM khá thú vị. Bây giờ chúng ta có thêm thông tin, chúng ta phải tìm ra bước tiếp theo trong điều tra.
Ý nghĩa của controller error
Nếu bạn tìm kiếm lỗi cụ thể này, bạn sẽ thấy một loạt entry, từ những người hỏi cùng câu hỏi. Cuối cùng, nó归结为 ba vấn đề chính – cáp SATA xấu, ổ đĩa xấu, hoặc chipset controller xấu, thực tế nghĩa là mainboard mới. Nghe khá ám ảnh. Tuy nhiên, vấn đề chỉ biểu hiện DURING quét MBAM. Và tại thời điểm này, chúng ta cần hiểu xem chúng ta đang đối mặt với sự cố đơn lập hay vấn đề hệ thống.
Phân tích, sức khỏe hệ thống
Tôi quyết định kiểm tra trạng thái máy trên vài cấp độ, bao gồm kiểm tra phần cứng. Lưu ý bạn không bao giờ chắc chắn 100%. Ngay cả khi một kiểm tra cụ thể ra sạch, về mặt kỹ thuật, phần cứng của bạn có thể chết ngày mai. Do đó, bạn không thể tìm sự an ủi và đảm bảo trong các kiểm tra này. Chúng chỉ cho bạn biết là, cho lúc này, trong trường hợp tốt nhất, không có triệu chứng cho thấy vấn đề rộng hơn.
- Kiểm tra SMART ổ đĩa, sạch.
- Kiểm tra WD Data Lifeguard Diagnostics, sạch.
- Hệ thống ổn định như đá ngoài vấn đề trên.
- Không vấn đề khác xảy ra, kể cả cả tuần sau sự cố.
Dù tôi ngứa ngáy muốn làm gì đó, tôi quyết định không làm gì và để máy chạy một tuần, bao gồm hoạt động stress như – chơi game nặng IO nhiều, sao lưu dữ liệu, system imaging, Windows Updates, và hơn thế. Trong tất cả các "test" này, hệ thống hành xử dự đoán được, cùng cách nó làm hàng tháng và năm trước.
Tại thời điểm này, tôi quyết định không có vấn đề sức khỏe phần cứng cấp bách, ít nhất, thống kê thời gian và mê tín dĩ vãng. Điều này dẫn tôi tin rằng vấn đề do MBAM gây ra. Và nó phù hợp với kinh nghiệm của tôi rằng không phải Windows bị crash, luôn là thứ khác gây ra.
MBAM, điều tra thêm
Bây giờ, chúng ta tập trung vào phần mềm bảo mật này. Lại, nếu bạn tìm online, bạn sẽ thấy vô số entry, với các chủ đề chính lặp lại: a) mã độc, như DÙ, bao gồm trojan ngăn phần mềm bảo mật chạy và gây crash loại này b) khiếu nại người dùng rằng MBAM 3 gây crash trong khi MBAM 2 không c) có thể có sự không tương thích với TrueCrypt có thể dẫn đến BSOD.
Tôi quyết định test các giả thuyết này xem có đúng không. Trước tiên, về c), điều này có thể là vấn đề một thời, nhưng chắc chắn không còn nữa. Theo kinh nghiệm tôi, tôi luôn có volume TrueCrypt mounted và chúng chưa bao giờ gây crash trước.
Về a), đây là vô nghĩa, nhưng tôi quyết định theo dõi vài khuyến nghị nhanh xem có kiểm tra được không. Tất nhiên không. Hơn nữa, MBAM hoàn thành quét tiếp theo không BSOD nhưng với lỗi controller liên quan, thu hẹp vấn đề xuống phần mềm.
MBAM + Event ID 11
Bây giờ, chúng ta thực sự có thể tìm thông tin liên quan. Chỉ có một vài entry trong forum chính thức, và câu chuyện của họ rất giống với tôi. Vài người đã crash, và họ tìm ra đây do xung đột giữa MBAM và driver Intel Rapid Storage Technology (RST). Aha. Tôi cài driver mới nhất được hỗ trợ và reboot. Tôi khám phá một vài điều trên đường:
- Chữ cái ổ đĩa của tôi bị lộn xộn, phải gán lại đúng.
- Đèn ổ đĩa trên case nhấp nháy ít hơn trước – ngay cả khi không bật SATA Link power management – có thể chỉ là trick thị giác hoặc thực sự, hoạt động polling ổ đĩa giảm hơn trước. System metrics không thấy khác biệt lớn.
- Có tăng hiệu năng rất nhẹ do driver mới.
Và bây giờ, tôi chạy quét MBAM mới hoàn toàn, và nó hoàn thành không vấn đề gì. Cũng không có lỗi nào trong Event Log. Vậy hóa ra đây là vấn đề do phần mềm thứ ba, và không phải lỗi của Microsoft, cũng không phải vấn đề phần cứng. P.S. Người khác dùng MBAM báo vấn đề biến mất SAU khi nâng cấp phiên bản MBAM.
Hãy để tôi miễn trừ trách nhiệm, lỗi không do Windows hoặc nền tảng bên dưới, theo biết bạn có thể nói. Nó không trong khả năng hợp lý của người dùng để tìm ra. Vì trên desktop cũ của tôi, như bạn đọc trong bài vui vẻ của tôi về chủ đề này, ổ đĩa với dữ liệu SMART hoàn hảo chết không cảnh báo trước, trong khi cái khác, với vấn đề critical ngụ ý sắp chết, đã sống vui vẻ nhiều tháng kể từ khi lỗi xuất hiện. Thống kê hoạt động tốt cho đến khi chúng quay lưng bạn.
Nhưng cho mọi mục đích thực tế, ngay đây, ngay bây giờ, đó là vấn đề 100% MBAM, và không liên quan đến phần cứng. Xung đột giữa scanner bảo mật với đặc quyền hệ thống thấp (low-level) và driver lưu trữ. Câu hỏi là tại sao?
Thực sự, tại sao?
Không có quyền truy cập source code MBAM, bạn không thể biết chắc, nhưng tôi có lý thuyết. Mã độc cố gắng giấu mình trên ổ đĩa thỉnh thoảng dùng mọi kế hoạch thông minh. Cách làm là ép hệ thống dùng driver I/O giả, để chúng báo cáo ổ đĩa sạch. Nghĩa là malware scanner có thể không thể tin hàm hệ thống trả về giá trị thật.
Tôi tin MBAM triển khai hàm truy cập ổ đĩa riêng, bao gồm lệnh controller, cũng như seek, read, unlink, và các system call và hàm khác của riêng nó. Với lý do nào đó, một trong các lệnh này xung đột với Intel RST, kích hoạt lỗi I/O, mà hệ thống hiểu là controller error. Do đó, BSOD hoặc system event. Đây là lý thuyết của tôi, và có thể sai, nhưng nó hợp lý.
Đọc thêm
Vì bạn không bao giờ chắc chắn hệ thống của bạn không fail, bạn thực sự nên lên kế hoạch cho sự thất bại của chúng. Nói cách khác, ôm lấy khoảnh khắc đau đớn, chuẩn bị cho khi chúng xảy ra để bạn có thể khôi phục nhanh, với thiệt hại tối thiểu. Ví dụ, tôi luôn có phần cứng dự phòng, bao gồm ít nhất 2-3 ổ cứng mới.
Tôi cũng chăm chỉ sao lưu dữ liệu và tạo system image, nên nếu cần thay phần cứng, tôi có thể nhanh chóng quay lại năng suất. Và vậy nó xảy ra, vài tháng trước, tôi đang đối mặt với sự cố ổ cứng đột ngột trên desktop khác. Không lo lắng. Tôi quay lại hoạt động trong khoảng một giờ, không mất dữ liệu hay thậm chí cấu hình hệ thống.
Cuối cùng, tôi la hét về giải quyết vấn đề và cách nó phải được làm có phương pháp. Đây là bản chất của troubleshooting, đặc biệt vấn đề phần cứng và phần mềm. Nếu bạn làm đúng, bạn ít khả năng sai lầm, tiết kiệm thời gian và tiền bạc. Đi thay đổi mọi thứ mù quáng không bao giờ là ý tưởng tốt. Tôi có cả một cuốn sách về điều này.
Kết luận
Đây là vấn đề khó khăn, phức tạp, với nhiều yếu tố cân nhắc. Tại một thời điểm, chúng ta có vấn đề phần cứng tiềm ẩn trên vài mặt, TrueCrypt, mã độc, và bug phần mềm đều tranh giành sự chú ý. Giải quyết nó không dễ. Và vẫn, với công việc chậm rãi, cẩn thận, chúng ta đã hiểu hoàn toàn vấn đề, cô lập nguyên nhân gốc rễ, xác thực khẳng định, và test các giải pháp tiềm năng. Tất cả mà không cần thay đổi hệ thống mạnh mẽ.
Tôi tin đây là bài học quý giá. Nó xảy ra với tôi, nhưng tôi muốn bạn lấy đi phát hiện. Bất cứ khi nào điều xấu xảy ra, Internet sẽ ném rác lên bạn. Phần cứng, mã độc, tự chọn. Mọi người sẽ có vấn đề của bạn, và vẫn, nó sẽ khác nhau chỉ một chút và không hoàn toàn áp dụng. Bạn có thể điên theo cách đó. Có cám dỗ mạnh mẽ để thử những gì mọi người khác làm. Nhưng cách tiến tốt nhất là kiểm tra kỹ triệu chứng, phân tích kỹ và áp dụng sửa chữa, có thể đảo ngược, định lượng hoàn toàn, bắt đầu từ cái đơn giản, ít xâm lấn nhất.
Đó là cách chúng ta xử lý vấn đề này. Chúng ta biết gì xảy ra? Chúng ta có thể tái tạo? Thông tin mới có ý nghĩa? Chúng ta có thể xác thực nguyên nhân có thể? Có thể loại trừ một số? Với những cái còn lại, vòng tìm kiếm mới. Khẳng định mới, giả thuyết mới, kiểm tra mới. Kết quả rõ ràng, tái tạo được. Giải quyết. Kiến thức. Vui. Hy vọng bạn thích. Nhớ đừng đổ lỗi cho Windows, và hoài nghi về những gì Internet nói về phần cứng của bạn. Nó toàn đen tối và u ám. Nhưng nó không phải như vậy. Happy computing.
Chúc vui.