問題如下：
1.網頁上顯示
您試圖在此 Web 服務器上訪問的 Web 應用程式當前不可用。請點擊 網頁瀏覽器中的[重新整理] 按鈕重試您的請求。
管理員注意事項:
詳述此特定請求失敗原因的錯誤資訊可在 Web 服務器的系統事件日誌中找到。請檢查此日誌項以查明導致該錯誤發生的原因。
2.windows事件檢視器-應用程式Log
The state server has closed an expired TCP/IP connection. The IP address of the client is 127.0.0.1. The expired Read operation began at 05/21/2007 20:12:04.
解決的方法很簡單，把程式對應的IIS應用程式集區回收一下就好了。
可是為什麼會出現這個原因呢？還有為什麼回收一下就好了呢？回收做了些什嗎？
出現的原因
在網上搜尋了一翻，發現主要是一下幾個問題，當然還有其他原因
1）.Framework的問題，例如1.0和2.0版本
2）aspnet_wp.exe 問題
3）安全更新程式 (KB886903)
可惜我們伺服器出現的問題都不是以上幾點引起的，經過我的分析認為是寫的很爛很爛的程式佔用了大量的資源最後導致記憶體流失，導致IIS的 進程當掉了。可惜了程式我是沒辦法改，都是別人寫的，也不會改。不過我不可能每次出現這個問題就登陸到遠程伺服器上去回收一次吧，所以只有讓他自動回收 了。
自動回收有好幾種方式，也不知道那一種比較適合，而且回收背景工作處理序是會把儲存在記憶體裡的Session清空，造成使用者需要重新登陸的問題，所以自動回收要越少越好，以保證不會因為其中的一個使用者使用了那個很爛的程式導致其他的使用者都要重新登陸。
如果用了狀態伺服器或者是把Session儲存到了資料庫中去的程式自動回收後肯定是沒有任何影響的，請求也不會中斷還是一樣繼續運行，只是換了個背景工作處理序繼續為用戶端工作，用戶端是感覺不到的，當初沒有為了方便沒有把Session儲存到資料庫真是失策！
1.根據已耗用時間
系統預設是1740分鐘,也就是29個小時,這個不是很好控制,建議不用，也就是去掉那個勾。
2.請求數目
這個要看具體的情況了。如果只有10個請求，可是有5個都在請求那個比較佔資源的頁面（可能是統計年度報表之類），這個 時候就會出現進程當掉的情況，如果請求有1000個可是一個也沒運行比較佔資源的頁面，這個時候進程肯定是很正常的，所以根據請求的數目來決定也不符合實 際需要。
3.計劃的時間
這個其實很好，不過具體什麼時間回收好呢？通常我們都是設定上班前和下班後回收，這個時候回收是有必要的，不過針對出現隨時可能出現是高記憶體佔用並不是很適用。
4.記憶體（虛擬記憶體或已使用的記憶體）
這個針對出現記憶體問題引起的進程當掉實在太合適了，不過設定多大的值比較好是一個很重要的問題， 我是根據每次出現問題時進程是實際佔用情況決定的。我們的伺服器記憶體是2G，通常其他的一些服務會佔用掉600多M，我發現有每次進程都是到1G多的時候 當掉，所以設定了最大使用記憶體為1000M的時候自動回收，設定後一直都沒出現問題了。要查看進程的佔用直接用windows工作管理員就好，值不能太小 了，否則如果訪問量都很大超過這個值的時候也會自動回收，這個就很沒必要了。一定要多多觀察進程的實際佔用情況再做決定。
在IIS的設定檔裡面 如果配置了IIsApplicationPools節點的LogEventOnRecycle屬性，每次回收的時候IIS的記錄檔會根據 LogEventOnRecycle屬性的值紀錄下相關的資訊，也個也是設定自動回收時的一個重要參考，不過由於這個記錄檔只能看幾個小時以前的紀錄， 當前的紀錄要幾個小時後才寫進去，所以看起來不方便，鬱悶！
現在暫時根據最大佔用記憶體自動收回以前的問題是解決了，暫時也發現什麼新問題了，也不知道其他地方都是怎麼設定的，是不是還有更好的方法呢？希望到了這篇文章的人能提點寶貴意見，大家一起交流一下經驗。
IIS的設定檔在windows的安裝目錄下（C:/WINDOWS/system32/inetsrv/MetaBase.xml），直接修改設定檔需要停止IIS服務，修改前記得備份。
部分配置資訊，寫的好玩的
複製代碼 代碼如下:
<IIsApplicationPool Location ="/LM/W3SVC/AppPools/DefaultAppPool"
AppPoolAutoStart="TRUE"
PeriodicRestartMemory="2000" //最大虛擬記憶體MB
PeriodicRestartPrivateMemory="1000" //最大佔用記憶體MB
PeriodicRestartRequests="1000" //請求數
PeriodicRestartSchedule="07:50 //自動回收時間
12:00
20:00"
>
</IIsApplicationPool>
以下是摘錄IIS內建的協助。
背景工作處理序回收如何工作
根據應用程式集區回收的配置方式，全球資訊網發布服務（WWW 服務）可以使用兩種方法來回收已指派的背景工作處理序：
•預設情況下，WWW 服務建立“重疊回收”，即繼續運行要終止的背景工作處理序，直到啟動新的背景工作處理序後為止。
•或者，WWW 服務可以終止一個背景工作處理序，然後啟動一個新的背景工作處理序（如果工作負載允許執行此操作的話）。
注意 當 WWW 服務回收某個背景工作處理序時，它並不斷開現有的 TCP/IP 串連。HTTP 協議堆棧 (HTTP.sys) 建立並維護 TCP/IP 串連。
在重疊回收方案中，要回收的進程繼續處理請求，同時 WWW 服務建立一個替代背景工作處理序。在停止舊背景工作處理序之前啟動新的背景工作處理序，然後將請求定向到新的進程。此設計可以防止服務中斷，因為舊進程關閉前仍然保持與 HTTP.sys 的通訊以處理請求。因為可重疊關閉或啟動的關閉逾時值是可以配置的，所以在背景工作處理序仍在處理請求的同時可以終止該進程（如果它在時間限制內沒有處理完請求 的話）。
在配置應用程式集區以基於已耗用時間來回收背景工作處理序時，可以在設定的已耗用時間內回收所有的背景工作處理序，但不能同時回收所有這些背景工作處理序。可以在設定的時間內的不同時段進行回收應用程式，以減少用戶端請求服務的中斷次數。
類似地，在配置應用程式集區以基於處理請求的數目來回收應用程式時，可以每隔一段時間回收一次以分擔與背景工作處理序回收有關的系統開銷。
何時使用背景工作處理序回收
在決定是否啟動背景工作處理序回收時，應考慮以下常規指南。最佳的解決方案是修複引起故障的應用程式。但是，並非總能使用重新編碼，尤其是啟動並執行其他應用程式代碼無法修改時。
在以下情況下考慮使用回收：
- 無法修複 Web 服務器上您所主控的有故障的應用程式。
- 遇到不能確定的或間斷性的故障。
- 您懷疑應用程式由於效能監控的原因而泄漏記憶體。
- 先前已實施了臨時性的重設解決方案，例如，計劃執行 IISReset 命令列工具 + 生產力。
在以下情況下，可能根本不需要使用回收：
- 您所主控的網站只包含靜態內容，並且不包含自訂 網際網路伺服器 API (ISAPI) 應用程式。
- 您所主控的應用程式已經過完全測試，並且不會出現記憶體或資源分派問題。
要有效地使用回收，請仔細檢查回收所依據的標準（如下表中所示）。
| 回收依據的條件 |
描述 |
使用時間 |
| ISAPI 請求 |
根據應用程式集區中 ISAPI 的請求回收背景工作處理序。 |
ISAPI 擴充可以將其自身聲明為健全狀態差。 |
| 已耗用時間 |
根據使用者指定的時間（分鐘）回收背景工作處理序。 |
存在故障的應用程式的已耗用時間過長。 |
| 請求數目 |
當超文字傳輸通訊協定 (HTTP) (HTTP) 請求超出某個特定閾值時回收背景工作處理序。 |
根據應用程式接收到的請求數目，應用程式出現故障。 |
| 計劃的時間 |
在 24 小時內的指定時間進行回收。 |
條件與已耗用時間的條件類似。 |
| 虛擬記憶體（保留的記憶體加上已使用的記憶體） |
當背景工作處理序虛擬記憶體達到某個特定閾值時回收該背景工作處理序。 |
記憶體堆棧片段過多（這是由於應用程式保留多次記憶體造成的）。癥狀是虛擬記憶體持續增加。 |
| 已使用的記憶體 |
當 W3wp.exe 進程使用的記憶體達到某個特定閾值時回收背景工作處理序。 |
某些應用程式出現記憶體流失。 |
| 根據需要 |
當 IIS 管理員可以使用 Microsoft? 管理主控台 (MMC) 或指令碼控制整個應用程式集區的回收時開始回收。 |
在其他網站啟動並運行時，有一個引起故障的應用程式集區。請考慮回收該應用程式，而無需重設整個 WWW 服務。 |
