我有一個用.net-3.5編寫的有點大的服務器進程，也就是說，運行在一個VMWare vCenter Server中，在不報告任何錯誤的情況下會一直崩潰。該進程由32位Windows Server 2003上的Windows Service創建，旨在成爲長時間運行的進程（多天）。這是一個協作過程，它接受來自運行在其他Windows XP機器上的多個客戶端的Tcp套接字的連接，並允許它們共享數據。此外，該過程還自行承載大約8個WCF服務，這些服務公開混合Tcp & Http端點。該過程通常會消耗大約500 Mb的內存和30-50％的CPU。在託管6個數據庫的同一虛擬機上還有一個SQL Server 2005實例，並消耗大約1-1.2 Gb的內存。整個系統已經分配了8G的RAM，並且在正常操作期間消耗高達7Gb。我假設PAE已啓用，以允許系統處理8 Gb的內存，但尚未確認。進程突然崩潰，沒有錯誤
問題是，在看似隨機的時間裏，進程會突然崩潰而沒有報告錯誤，包括事件日誌。我試着將調試器附加到進程中，但他們也沒有發現崩潰。我首先在發佈版本上嘗試了WinDbg，並加載了符號，然後用調試版本替換了所有發行版的dll/exes並加載了它們的符號。崩潰仍然發生，調試器沒有捕獲它們。接下來，我使用.Net Reflector加載項在系統上安裝了Visual Studio，並附加了它。它也沒有趕上崩潰。
在你講述爲什麼我們要在單個虛擬機上運行這麼多事情之前，我知道我沒有設計系統，也沒有這樣實現。我們的客戶因爲特定的原因決定了它，並且我被要求進來並使其工作。如果你能找到有助於解釋突發事故的具體證據，我只對環境的批評感興趣。如果我們可以展示這樣的證據，我們的客戶可能願意改變環境。任何額外的調試技術都可以讓我捕獲更多關於崩潰的信息，我們將不勝感激。
我首先在應用程序中包含過多的日誌記錄（例如NLOG或LOG4NET）在例外的情況下記錄什麼。 – 2011-04-17 15:00:06
ru使用任何非託管的第三方庫？當你連接windbg並且沒有發現異常時，windbg輸出還有什麼其他的興趣點？ – wal 2011-04-17 15:14:33
嗯，我的第一個猜測（這是*所有*它）是這是某種內存不足的錯誤。你的進程可能會消耗大量的RAM，你遇到了垃圾回收的問題，並且進程正在終止。不知道爲什麼你不能用調試器捕捉錯誤。檢查以確保您沒有泄漏內存或手柄。當事情穩定時，像Process Monitor這樣的東西會告訴你什麼？ – 2011-04-17 15:18:07