我有一位客戶在Asp.NET 1.1中使用IIS和我們開發的應用程序。星期一，連續4次錯誤「處理服務應用程序池'xxxx'與萬維網發佈服務遭遇致命通信錯誤。進程ID是'yyyy'。數據字段包含錯誤號。「出現。如何診斷IIS致命通信錯誤問題
有關如何診斷此問題的任何想法？ only link I've found討論安裝低級調試工具，但在進行這種低級別分析之前，我會知道是否有人有更好的主意或合適的替代方案。
問題（從我所能看到的）是客戶環境中的問題，因爲它在至少20或30臺不同的服務器上安裝在其他客戶站點的相同應用程序並且不會發生問題。
問候
馬西莫
我相信你已經知道這一點，但應用程序池包含1.1應用程序只對不對？我不記得當游泳池通過混合框架（類似於Server Unavailable）而死的時候出現的錯誤，但是它更常見，然後我在野外考慮，所以我會仔細檢查。
雖然不太可能是這樣的情況下，它是開始的地方。
編輯：This知識庫文章也有您描述的有關注冊表權限的錯誤消息，客戶端運行的是什麼版本的IIS？
當網站部署到客戶端的Web服務器時，我遇到了同樣的問題。 This Microsoft support article說：
「如果NT AUTHORITY \ NETWORK SERVICE帳戶不具有所需的註冊表項的權限，則可能會發生此問題。」
而解決方法是：「將權限設置爲所需的註冊表項，然後重新啓動IIS 6.0」。
鏈接的文章有這樣做的步驟。
一個更受歡迎的原因（如我的情況） - 其中一個Windows日誌已滿。
Alsin，你的答案是從4年前開始的，所以這是一個延伸。但你是否記得爲什麼你說「日誌滿了」是一個流行的原因？我沒有找到這個失敗的原因的其他參考，但鑑於我們的Windows事件日誌的配置方式，在我看來似乎是合理的。 – 2014-07-29 14:56:31
在我的情況下，問題是我的應用程序代碼中的無限遞歸循環。 – 2016-05-19 13:47:14
我得到了同樣的錯誤，這裏有一些更多的細節：
運行：Windows Server 2003中，IIS 6.0/ASP 3.0， 2.13千兆赫，1 GB RAM
我的網站是在測試版，所以我幾乎沒有任何訪問者訪問該網站。
根據事件查看器，我每3分鐘收到3次警告， 然後停止幾個小時。
於是有時我得到的錯誤：
服務應用程序池一個進程的默認應用意外終止。進程ID是'3900'。進程退出代碼是'0x800703e9'。隨後通過
：
應用池DefaultAppPool'被自動由於在服務於該應用程序池的過程（ES）一系列故障而被停用。
然後在瀏覽網站時會導致「服務不可用」消息。
閱讀關於這個問題太多崗位後，我做了以下步驟：
我看，這可能是註冊表的訪問權，所以我安裝了一個監控和跟蹤所有W3SVC拒絕訪問錯誤，授予permition
我讀到0x800703e9錯誤意味着堆棧溢出導致w3wp.exe崩潰，我應該安裝調試工具並嘗試獲取內存轉儲。 我這樣做了，但我沒有得到任何轉儲，所以我安裝了一個新的調試工具，但沒有崩潰。
我的網站正在做一些數據挖掘，使服務器保持繁忙。
結論：
我不知道什麼是對那裏發生的......但我知道，我的服務器計算機的方式對資源的慢，所以我要升級並重新安裝它，我敢肯定，它會解決問題...即使當我的.net代碼是空閒的，因此這是一個問題在服務器上，而不是在我的代碼中，問題一直髮生，所有的時間， 。
我認爲，第一WARNNING 「進程服務應用程序池......」發生的每一段時間，每一個現在，然後它會導致應用程序池重新啓動，因此一個附加調試器並不能幫助 - 進程繼續重新啓動，調試器不再有效... 我認爲0x800703e9錯誤（導致服務不可用）可能發生在應用程序池重新啓動時，我想它需要大量資源，並且自從我機器速度太慢，它得到0x800703e9 ......如前所述，這是一個堆棧溢出，但我認爲這是由低資源造成的，而不是由無窮遞歸造成的。 0我認爲被微軟聲稱是'註冊表訪問權'是問題，但是我沒有得到'服務不可用'，因爲它可能有幫助（我認爲我仍然得到警告「一個進程服務應用程序池...「）。
希望這有助於有人...
對IIS 7相同的問題，有一些報道所有的工作只不過是很長，它從來沒有在IIS7工作的一份報告（這是對低精spec服務器）。
在IIS7中應用程序池的高級設置我設置了「啓用32位應用程序」爲true和所有的工作很好
對我來說，問題是在我的應用程序代碼中的無限遞歸循環。 – 2016-05-19 13:47:04