# Hướng dẫn WinDbg: Debug Deadlock & High CPU qua Memory Dump Không phải sự cố production nào cũng kết thúc bằng một crash rõ ràng. Ngược lại, những vấn đề **khó chịu nhất** thường là: * Hệ thống **treo** (request không trả về, CPU thấp) * Hoặc **CPU tăng vọt 100%** nhưng không có lỗi Trong cả hai trường hợp, memory dump là **ảnh chụp hiện trường** tại thời điểm hệ thống đang “bất thường”. WinDbg giúp bạn đọc bức ảnh đó – nếu bạn biết cách đặt câu hỏi đúng.
*** ### 1. Phân biệt Deadlock và High CPU – bước tư duy đầu tiên Trước khi debug, hãy xác định **bản chất vấn đề**: | Hiện tượng | CPU | Trạng thái thread | | ---------- | ---- | ----------------- | | Deadlock | Thấp | Block / Wait | | High CPU | Cao | Running / Loop | 📌 **Sai lầm phổ biến**: Dùng cùng một quy trình debug cho cả hai.\ Thực tế, deadlock và high CPU yêu cầu **hai hướng tư duy hoàn toàn khác nhau**. *** ### 2. Nền tảng bắt buộc: Nhìn toàn cảnh thread Bất kể deadlock hay high CPU, luôn bắt đầu bằng: ``` ~ ``` Lệnh này liệt kê: * Tất cả thread * Trạng thái * CPU time 📌 **Câu hỏi cốt lõi** > Thread nào không làm đúng vai trò của nó? *** ## PHẦN I – DEBUG DEADLOCK ### 3. Nhận diện deadlock qua thread state #### Chuyển sang từng thread và xem stack ``` ~Ns k ``` Bạn cần tìm: * Thread đang chờ lock * Thread giữ lock nhưng không tiến triển * Chuỗi phụ thuộc vòng tròn 📌 **Deadlock không phải “treo”**\ Deadlock là **hệ thống đang làm việc… nhưng không bao giờ xong**. *** ### 4. Phát hiện lock & synchronization object #### Với critical section / mutex (user-mode) ``` !locks ``` Hoặc: ``` !cs -l ``` Bạn sẽ thấy: * Lock nào đang bị giữ * Thread nào sở hữu * Thread nào đang chờ 📌 **Dấu hiệu rõ ràng** * Một thread giữ lock rất lâu * Nhiều thread xếp hàng chờ cùng một lock *** ### 5. Đọc stack để hiểu “vì sao lock không được nhả” Hãy đặt câu hỏi: * Thread giữ lock đang làm gì? * Có I/O, sleep, hoặc gọi sang external system không? * Có lock lồng nhau không? 📌 **Nguyên tắc kiến trúc** > Không giữ lock khi gọi code không kiểm soát được thời gian thực thi. *** ## PHẦN II – DEBUG HIGH CPU ### 6. Xác định thread ăn CPU nhiều nhất #### Xem CPU usage từng thread ``` !runaway ``` Hoặc reset rồi đo lại: ``` !runaway reset ``` (chờ vài giây) ``` !runaway ``` 📌 **Thread có User Time hoặc Kernel Time cao nhất** chính là mục tiêu đầu tiên. *** ### 7. Phân tích stack thread high CPU Chuyển sang thread nghi vấn: ``` ~Ns kv ``` Tìm: * Vòng lặp * Hàm được gọi lặp đi lặp lại * Thiếu điều kiện thoát * Busy wait 📌 **High CPU không phải do “nặng”**\ Mà thường do **làm việc vô ích, lặp lại không cần thiết**. *** ### 8. Phân biệt User CPU và Kernel CPU * **User CPU cao**: logic code, vòng lặp, thuật toán * **Kernel CPU cao**: I/O spin, lock contention, syscall bất thường Stack trace sẽ cho bạn câu trả lời. *** ### 9. Khi stack “đẹp” nhưng CPU vẫn cao? Đây là case nguy hiểm nhất. Nguyên nhân thường là: * Thread đang spin ở native code * External library * JIT / GC / runtime internal loop 📌 **Chiến lược** * So sánh nhiều dump * So sánh stack các thread cùng CPU cao * Tìm pattern lặp lại *** ### 10. Deadlock giả & High CPU giả Không phải lúc nào biểu hiện cũng phản ánh bản chất. Ví dụ: * CPU thấp nhưng thread chờ I/O → không phải deadlock * CPU cao do load hợp lệ → không phải bug 📌 **Debug tốt là biết khi nào nên… không debug** *** ### Kết luận: Debug concurrency là bài kiểm tra tư duy hệ thống Deadlock và High CPU không thể giải quyết bằng một stack trace đẹp. Chúng yêu cầu: * Hiểu vòng đời thread * Hiểu chiến lược synchronization * Hiểu chi phí của từng quyết định kiến trúc WinDbg chỉ là công cụ.\ **Tư duy hệ thống mới là thứ tạo ra khác biệt.** Đó cũng là định hướng mà **Cẩm nang NQDEV** và **NQDEV Platform** theo đuổi: > *Khi hệ thống gặp sự cố, người hiểu concurrency sâu là người cuối cùng rời phòng.* 👉 Theo dõi thêm các bài phân tích thực chiến tại:\ 🔗 [**https://blogs.nhquydev.net/**](https://blogs.nhquydev.net/)