Phân tích sự cố đổ rác trong windbg

Question

Tôi đang sử dụng API nguồn đóng của bên thứ ba có ngoại lệ cho biết rằng "tất cả các đường ống có tên đang bận".

Tôi muốn gỡ lỗi hơn nữa (thay vì chỉ bước qua) để tôi thực sự có thể tìm hiểu những gì đang xảy ra dưới trang bìa.

Tôi đã lấy một kết xuất của quá trình này bằng cách sử dụng WinDbg. Tôi nên sử dụng các lệnh nào để phân tích kết xuất này?

Cảm ơn

Answer 1

Điều này thường xảy ra khi khách hàng gọi CreateFile cho đường ống hiện tại và tất cả các phiên bản đường ống hiện có đang bận. Tại thời điểm này, CreateFile trả về lỗi và mã lỗi là ERROR_PIPE_BUSY. Điều đúng đắn tại thời điểm này là gọi WaitNamedPipe với một giá trị thời gian chờ để chờ một thể hiện đường ống có sẵn.

Sự cố thường xảy ra khi nhiều khách hàng cố gắng kết nối với ống được đặt tên cùng một lúc.

Answer 2

Tôi giả định rằng dll bên thứ 3 có nguồn gốc (Nếu không, chỉ cần sử dụng Reflector)

Trước khi sử dụng WinDbg để phân tích các bãi chứa, hãy thử sử dụng Process-Monitor (SysInternals, phần mềm miễn phí) để giám sát hoạt động của quá trình của bạn. nếu nó không thành công vì vấn đề liên quan đến hệ thống tệp, bạn có thể thấy chính xác nguyên nhân gây ra sự cố và chính xác nó đã cố làm gì trước khi không thành công.

Nếu Process-Monitor không đủ hơn bạn có thể thử và gỡ lỗi quy trình của bạn. nhưng để xem một số thông tin có ý nghĩa về dll của bên thứ 3 bạn sẽ cần nó là pdb's.

Sau khi đặt các biểu tượng gỡ lỗi chính xác, bạn có thể xem ngăn xếp cuộc gọi bằng cách sử dụng lệnh k hoặc một trong các biến thể đó (một lần nữa, tôi cho rằng bạn đang nói về mã gốc). nếu quá trình của bạn thực sự bị hỏng vì dll này hơn là kiểm tra các tham số mà bạn chuyển đến hàm của nó để đảm bảo rằng vấn đề không nằm ở bên cạnh bạn. Tôi đoán rằng tiếp tục xuống ngăn xếp cuộc gọi, bạn đạt được một số Win32 API - kiểm tra các thông số mà chức năng của dll là đi qua, cố gắng để xem nếu một cái gì đó "mùi". Nếu bạn có biểu tượng riêng của dll, bạn có thể kiểm tra các biến cục bộ của hàm đó (dv) có thể cung cấp cho bạn thêm một số thông tin.

Tôi hy vọng tôi đã cho bạn một điểm khởi đầu tốt.

Answer 3

Đây là một nguồn tuyệt vời cho sử dụng WinDbg để phân tích tai nạn mà bạn có thể sử dụng một số: http://www.networkworld.com/article/3100370/windows/how-to-solve-windows-10-crashes-in-less-than-a-minute.html

bài viết này là dành cho Windows 10, nhưng nó có chứa liên kết đến các thông tin tương tự cho các phiên bản trước của Windows.

Answer 4

Khi gỡ lỗi sau khi sửa lỗi bằng Windbg, có thể hữu ích khi chạy một số lệnh chẩn đoán chung trước khi quyết định nơi tìm hiểu sâu hơn. Đây phải là các bước đầu tiên của bạn:

.logopen <filename> (See also .logappend) 
.lastevent    See why the process halted and on what thread 
u      List disassembly near $eip on offending thread 
~      Status of all threads 
Kb      List callstack, including parameters 
.logclose 

Các lệnh này thường cung cấp cho bạn tổng quan về những gì đã xảy ra để bạn có thể khai thác thêm. Trong trường hợp xử lý các thư viện mà bạn không có nguồn, việc gửi tệp nhật ký kết quả tới nhà cung cấp cùng với bản dựng của thư viện nhị phân phải đủ để chúng theo dõi nó đến một vấn đề đã biết nếu có.

Answer 5

Bạn có thể bắt đầu làm như sau để có được một tổng quan về các ngoại lệ:

!analyze -v 

Bây giờ bạn có thể tải các bản ghi bối cảnh ngoại lệ:

.ecxr 

Và bây giờ ... chỉ cần có một cái nhìn tại ngăn xếp, sổ đăng ký, chủ đề, ...

kb  ;will show you the stack trace of the crash. 
dv  ;local variables 

Tùy thuộc vào manh mối bạn nhận được, bạn nên theo dõi hướng lên men. Nếu bạn muốn tham khảo nhanh về WinDbg, tôi khuyên bạn nên this link.

Tôi hy vọng bạn tìm thấy một số lệnh và thông tin này hữu ích.