2013-04-03 17 views
5

Tôi đang dựa vào Windows Error Reporting để tạo các bãi chứa chế độ người dùng đầy đủ cho một ứng dụng lớn, đa luồng. Tôi biết rằng khi tôi bắt đầu sử dụng nó (đầu năm 2012) các bãi chứa tất cả các bộ nhớ ứng dụng, và ngăn xếp đầy đủ cho tất cả các chủ đề được chính xác cho thời gian ứng dụng bị rơi (ném ngoại lệ unhandled, vv). Nhưng tại một số điểm chưa biết trong năm qua, các bãi đổ vỡ do WER tạo ra đã thay đổi. Họ vẫn chứa tất cả bộ nhớ, nhưng chỉ hiển thị một thread, và chồng dường như là từ sau quá trình này đã được tắt:Khi nào thì Windows Error Reporting tạo tệp kết xuất? Nó có thể cấu hình được không? Điều này đã thay đổi trong Windows 7 chưa?

[email protected]() + 0x14 bytes 
    [email protected]() + 0x141 bytes  
    [email protected]() + 0x74 bytes 
    [email protected]() + 0x18928 bytes 

Đây là một không được quản lý (unmanagable?) 32-bit ứng dụng C++ biên soạn với VS2010 SP1, chạy trên Win7 SP1 64 bit (và được cập nhật liên tục). Có ai biết về bất kỳ bản cập nhật Windows nào đã thay đổi hành vi WER trong năm qua không? Có cấu hình nào khác ngoài 'HKLM \ SOFTWARE \ Microsoft \ Windows \ Windows Error Reporting \ LocalDumps \ AppName.exe' không?

Ngoài ra, việc hủy ứng dụng bằng cách gọi 'RaiseFailFastException' vẫn dẫn đến kết xuất tốt với ngăn xếp hợp lệ cho tất cả chuỗi.

+0

Không có gì tôi nghe thấy. Lời giải thích đơn giản là ứng dụng của bạn chỉ bị lỗi vì một lý do khác. –

+0

Không, tôi rõ ràng đang ném một ngoại lệ để kiểm tra việc tạo kết xuất, và tôi đang thiếu các ngăn xếp trên cả phiên bản mới nhất của ứng dụng và phiên bản từ một năm trước mà ban đầu đã làm việc. Cảm ơn mặc dù. –

Trả lời

3

Aha! Một thư viện của bên thứ ba đã gọi SetUnhandledExceptionFilter, ngăn chặn Windows Error Reporting không nhận được ngoại lệ ban đầu. Người xử lý của họ đã làm một số dọn dẹp nội bộ, sau đó được gọi là hủy bỏ, tại thời điểm đó WER cuối cùng đã có thể tạo ra một bãi chứa. Đối với bất kỳ ai gặp phải vấn đề này, tôi khuyên bạn nên kiểm tra xem các trình xử lý đã cài đặt (giá trị trả về của SetUnhandledExceptionFilter, set_terminate, vv) là những gì bạn mong đợi (null nếu bạn đang dựa vào WER, hoặc trình xử lý của riêng bạn hoặc CrashRpt).

+0

Thông tin hữu ích tại đây: http://www.debuginfo.com/articles/debugfilters.html#overwrite –

0

Tốt hơn hết là làm cho ứng dụng tự đổ rác khi ứng dụng gặp sự cố. Bạn chỉ cần gọi hàm SetUnhandledExceptionFilter, chỉ định lại cuộc gọi. Trong khi gọi lại, hãy sử dụng chức năng MiniDumpWriteDump với MiniDumpWithFullMemory loại kết xuất.

Bộ lọc ngoại lệ của bạn sẽ được gọi bất cứ khi nào ngoại lệ unhandled (bởi mã của bạn) xảy ra. Trong cuộc gọi trở lại, nó sẽ là tốt hơn để liệt kê và đình chỉ tất cả các chủ đề khác của quá trình của bạn.

Bạn cũng có thể cần phải cài đặt móc cho SetUnhandledExceptionFilter chính nó! Tại sao? Vâng, CRT sẽ luôn tắt bất kỳ bộ lọc ngoại lệ đã cài đặt nào và bằng chức năng được nối, bạn có thể tránh điều đó.

+0

Có vẻ như đây là những gì tôi sẽ phải làm. Tôi sẽ quay lại sử dụng thư viện [CrashRpt] (https://code.google.com/p/crashrpt/). –

+2

Nếu có thể dựa vào các bãi chứa WER (nghĩa là không cần thêm thông tin nào trong bộ lọc không được lọc, không có thông báo người dùng cụ thể), sử dụng WER là * cách tốt hơn * (nếu bạn không phải hỗ trợ WinXP). Nó sẽ cung cấp cho bạn một bãi chứa trong * tất cả * kịch bản vụ tai nạn, thậm chí bị hỏng ngăn xếp nơi UHEF thậm chí không được gọi. Plus: (quote MS) * MiniDumpWriteDump nên được gọi từ một quá trình riêng biệt nếu có thể, thay vì từ bên trong quá trình mục tiêu được bán phá giá (...) * Và tôi có thể nói với bạn rằng điều này thực sự phức tạp. –

+0

Xin lỗi, nhưng tôi phải nói rằng đây là một lời khuyên cực kỳ tồi tệ. @MartinBa chỉ chính xác đến các tài liệu, nhưng các tài liệu không nói * tại sao * người ta không nên làm điều đó. Trong thực tế, 'MiniDumpWriteDump' gọi' LoadLibraryEx() 'nội bộ, và, nếu bạn tình cờ giữ khóa bộ nạp, quá trình chắc chắn là deadlocks bên trong cuộc gọi. [Chủ đề thảo luận này] (https://groups.google.com/d/msg/microsoft.public.windbg/Kca8A-pV914/UEd48t2OzccJ) có một lời giải thích tốt từ một trong những nhà phát triển WER tại sao điều này chỉ đơn giản là không thể tránh khỏi. – kkm

Các vấn đề liên quan