當您的軟件在現場崩潰時，您會捕獲哪些信息？

Question

我正在重寫我的意外錯誤處理過程，並且我想問問社區：

什麼信息在您寫入崩潰的軟件時自動捕獲和手動捕獲？

現在，我捕捉到了幾個項目，其中一些是：

自動：

1. 應用墜毀
2. 版本的應用程序的墜毀
3. 堆棧跟蹤的名稱
4. 操作系統版本
5. 應用程序使用的RAM陽離子
6. 處理器數量
7. 屏幕截圖：（僅適用於非公開的應用程序）
8. 用戶姓名和聯繫方式（從Active Directory）

手冊：

1. 用戶在什麼環境下（即：什麼公司，技術支持電話號碼，RA號碼等）
2. 什麼時候用戶期望發生？ （典型的回答是：「不崩潰」）
3. 步驟來重現

你捕捉什麼其他位的信息，幫助你發現一個應用問題的真正原因，特別是考慮到大多數用戶只需混搭。當記者問到告訴你發生了什麼鍵盤

對於我使用C＃，WPF和.NET版本4的記錄，但我不一定要限制自己的

相關：。What to: Collect Information When Software Crashes

相關：What should be included in the state-of-the-art error and exception handling strategy?

Answer 1

（這有點的Windows/.NET特有的，但是那是你的問題的說明，我認爲這是在這方面非常有用的信息。）

除非你的應用程序是嚴格的單線程，你需要一個轉儲文件（至少爲所有線程提供堆棧），而不僅僅是引發異常的線程的堆棧跟蹤。

生成一個不太大的轉儲，並且有足夠的信息來爲您提供有用的託管堆棧跟蹤，這有點棘手，但有一個非常有用的實用程序，稱爲clrdump，它將爲您處理一些更高級的細節。

Clrdump大多是Microsoft的DbgHelp.dll的包裝。您可以直接使用DbgHelp - 請參閱this question - 但您會得到一個「完整的小型轉儲」，其大小與應用程序的虛擬地址空間一樣大，可能相當大。 Clrdump做了一個很好的工作，創建一個只有堆棧跟蹤的小轉儲，並且有足夠的信息讓SOS能夠讀取它們。

Answer 2

LA Transtar還保留一個只保存故障的關鍵日誌。該日誌包含正在進行的輸入和程序跟蹤。日誌在每個新事務開始時重置。

Answer 3

你沒有提到進程日誌記錄（比如Linux中的syslog，Windows的Event Viewer）。由於我也有一個系統管理員的背景，我真的很感謝與日誌設施的程序。如果可以選擇詳細級別，則更好。

這對你更瞭解環境很有好處，如果你的用戶必須與其他工具進行某種類型的集成工作，這對你的用戶是有好處的。

如果您的用戶更具技術性，您可以要求他們將日誌記錄詳細程度設置爲最大值並再次重現錯誤。

Answer 4

基本上，沒有黃金法則，你必須遵循和實施它在每個應用程序。根據您的業務應用程序和場景，發生錯誤時收集信息最適合包含不同的內容。

你提到的那些是正常的，但這裏有一點更是好到可以登錄：

• 爲
• 背景下你的程序的關鍵和複雜的操作，輸入參數 - 一些物體重算法 - 最大風險，有產階級
• 的狀態下爲你的程序

例如：你的程序的流程就像是一個狀態自動機，你有5個州的d你已經達到狀態3.

• 如果你有一個應用程序，它是服務器 - 客戶端，同時收集日誌 - 從供應商和消費方面

• 內存轉儲不是一般的好建議 - 做只有當您需要了解您無法控制的框架或JVM中的問題時（例如）。 OutOfMemoryError例如

Answer 5

我沒有在您的列表中看到最重要的信息（當我們談論dotnet/Java代碼級別時）。
異常類型，消息和跟蹤。
您可以使用簡單的代碼來捕捉任何異常，並「寫入日誌」/「直接發送到電子郵件」。

Answer 6

而且現在從偏執陣營:(

考慮什麼行業軟件的目標。收集有關用戶（即使是活動目錄名）或網絡上的任何信息，可以讓您的應用反對票，並可能進行責任。即什麼如果你的錯誤數據庫被破壞，並且這些信息被用來侵入銀行或政府實驗室網絡，那麼包含IP的錯誤報告會被注意到嗎？你可以被起訴嗎？也許......例如，如果您需要收集網絡特定數據以診斷網絡問題，請考慮讓您的應用程序在將數據發回給您之前用佔位符替換任何系統名稱或IP。 （emailSrvr1，bankAcctNumSrv，成爲srvr1和srvr2）這是追查問題時更大的痛苦，但也許值得。這仍然捕獲可能會讓你陷入困境的信息，但可能會有所幫助。

我一直在與高端企業和政府合作幾年，這爲我的觀點着色，但它可能值得考慮你正在收集什麼以及它如何被存儲。