軟體崩潰後，提示發出的「發送錯誤報告」到底有沒有用？

01-02

還是 @黃繼新老哥你了解我。

籠統的回答是：當然是有用的。但如果不說明白裡面到底有什麼，恐怕大家還是不能理解。

當程序崩潰時，Windows 的發送錯誤報告對話框實際上會在後台發送相當一部分數據，大體上包括下面這些數據：

一個64K 左右的 mini dump，包括崩潰時的寄存器和調用棧。
一組主要 Windows 關鍵 DLL 的版本號信息。用來確定當前系統狀態。
一部分系統的日誌。

其中最主要的，也是最重要的，實際上是第一個，就是dump。對程序崩潰這個特定的場景來說，dump最重要，日誌次之。版本號信息主要是用來確定系統確實是處於正常的狀態，不是盜版或者自行精簡之類的情況。

那麼dump是不是就能幫我們找出問題所在？這個答案可能是所有人最關心的，但很可惜，正確的回答是：不一定。事實上真正分析問題時我們需要的數據很多，比如內存違例而崩潰時，我們實際上需要至少這個進程內的內存快照，但現實是這些數據我們實際上無法得到。一方面是隱私問題，另一方面也是如今軟體佔用內存都很大，完全做快照可能佔用數百MB的空間，哪怕壓縮後也是如此。這麼大的數據上傳在實踐中並不現實。而現在上傳的dump不過64KB，多數情況下這麼點數據實在不夠用。

所以平心而論，單憑dump找出問題的可能性並不高。但是如果用戶踴躍提交bug報告仍然可以幫助我們的程序員：如果大家的問題都指向同一個調用棧，那麼 Windows 伺服器端這邊的統計數據就可以更好地定位出問題的熱點範圍。程序員們也會相應地在這裡投入更多的精力。投入的精力越多，問題被解決的可能性越大。

請看 http://techsingular.net/?p=1991

必須有用

軟體（程序）運行分為兩種一種叫做伺服器端運行一種叫做客戶端運行

世上沒有完美的事物同樣也沒有完美的軟體（程序）多多少少會有bug windows還藍屏呢

-------------------------- 以上為背景 -------------------------

對於伺服器端運行的出了錯誤程序員預先寫好的程序會將錯誤寫到文件中這樣程序員去伺服器上就能查看錯誤信息然後找到問題修復bug

但是客戶端運行的程序員不能去你的電腦上查看因此把錯誤信息發送到伺服器

對你來說沒有用。對他們自己的測試人員有用。

作為測試我來說一下。

大體上跟@陳甫鵃說的差不多。

一般測試的時候，我們會用Microsoft Visual Studio attach 到我們的軟體上。

出現問題後用Visual Studio輸出dump文件，這個文件非常大，每次基本上在1.5G以上。

作為初級測試就知道這麼多了。

非常有用，我們一直在用。

可以這麼說，一個專業的開發團隊開發的軟體，必需有crash repoort機制。十萬行代碼以上產品，沒有這個機制，就等著焦頭爛額吧，除非你的團隊人數很少且均為頂尖牛人。

下面說說我們團隊的做法，因為我們認為crash對用戶體驗的傷害是巨大的，所以我們把crash率作為技術團隊的考核指標之一。

技術上，我們通常都使用mini dump，full dump太大了，上傳不現實，實際上mini dump包含的信息也能提供很多參考。除此之外，通常同時還會把客戶端的一些日誌文件打包上傳。

為了最大限度的獲得信息，在reporter的界面設計上儘可能引導用戶選擇上傳。

收集到伺服器後，會進行初步的自動化分析和歸類，然後每天生成報表，供開發團隊進行後續的人工分析。通常使用visual studio或者windbg進行人工分析，因為所有的發布版本都有符號文件備份，因此分析起來還不算太困難。

當然，通常我們不會分析所有的crash，那樣太沒有效率，我們只會針對出現的次數和頻率等進行有重點的分析和修復，再結合灰度發布進行驗證和發行，有時候有的crash比較棘手，還需要多個回合才能修復，甚至一些兼容性問題導致的crash，需要好幾家公司配合才能修復。

微軟從Windows Xp開始引入錯誤報告機制WER，它可以幫助開發者獲得用戶反饋的程序崩潰信息，同時能讓用戶即時了解該問題是否已經得到解決以及如何解決。微軟專門提供HTTPS協議的伺服器來收集信息，另外企業也可以自行搭建相關伺服器。

希望有人知道，十萬行以上的軟體崩潰率（崩潰次數/活躍用戶數）這個比率在什麼範圍的認為是正常。或者說有沒有知道主流軟體的崩潰率？