Iis
嘗試解決無響應/掛起/損壞的 IIS 網站時應採取哪些步驟？
當您發現 IIS 網站沒有響應時，您會採取哪些措施？
我可能會嘗試先 telnet 到指定埠，然後檢查網站綁定和身份驗證，最後重新啟動它。
我認為了解有經驗的管理員在遇到此類問題時會檢查什麼非常有用。
事實上，我自己花了半個多小時試圖找出問題所在，似乎沒有什麼不正確的。我只是重新啟動了網站，問題仍然存在，但在重新啟動 IIS 服務後問題解決了。
如果我能知道一個更好的跟踪或至少一個有用的日誌記錄功能來幫助我更快地解決它，那將為我節省半個多小時。
{僅供參考，我使用的是 IIS 7.5}
我發現以下指南作為一般收集指南非常有效。
確定症狀
嘗試（盡快）確定問題的表面積：
- 連通性？（Telnet 很好；如果您在瀏覽器中返回一個錯誤頁面，那麼顯然有些東西在工作 - 首先消除連接）
- 一般應用程序池失敗，還是特定於內容類型？（ASPX 文件工作/不工作，但 .HTM 工作？你有每個應用程序和內容類型的金絲雀文件嗎？）
- 特定的應用內故障、掛起或崩潰？（其中大部分用於掛起和應用程序故障；崩潰決定了它們自己的方法：獲取崩潰轉儲，調試它）
作為一項規則，總是把它寫下來，因為你可能正在處理多種症狀，並且能夠回顧你對早期事件的筆記可能是非常寶貴的。
收集數據
又名“收集時間數據”- 在發生中斷時，您有一個有限的視窗來收集某些數據。一些數據——比如程序記憶體——是短暫的，如果你先採取糾正措施就會消失。其他數據（例如日誌）可能需要一些時間來複製，但之後您可以輕鬆地獲取它們。因此，了解您現在需要收集哪些數據與恢復後需要收集哪些數據。
- 獲取稍後解決問題所需的任何**時間敏感/及時的數據。**不要擔心持久性的東西——事件日誌和 IIS 日誌會一直存在，除非你是一個強迫性的清除者，在這種情況下：停止它。（那些沒有上週事件日誌的人注定要重蹈覆轍）
- 確定受影響的工作程序（並轉儲它）
APPCMD LIST WP可以幫助解決這個問題，或者伺服器級別的工作程序 GUI 。- 如果使用 GUI，不要忘記通過右鍵點擊工作程序來查看目前請求 - 如果你得到它，它會告訴你請求卡在哪個模組 (DLL) 中，這可以幫助你猜測一個引起早。
- 確定範圍（即只有一個應用程序池、多個應用程序池、兩個具有依賴項 - 這取決於您的應用程序和網站佈局）
- 獲取工作程序****的記憶體轉儲- 一旦您確定哪個應用程序池有問題，確定相關的工作程序，並使用任務管理器通過右鍵點擊該程序來創建記憶體轉儲。記下文件名以備後用。
- 關於任務管理器位數的注意事項：您需要使用與您正在攻擊的工作程序相同的任務管理器位數 - 如果您使用 64 位任務管理器轉儲 32 位 WP (w3wp*32)，它不會執行是可解釋的。如果在 64 位 Windows 上轉儲 32 位程序，則需要退出任務管理器，執行 %WINDIR%\SYSWOW64\TaskMgr.exe 以獲取 32 位版本，然後以相同的位數轉儲。（十秒鐘的繞道，但你必須當時做）。
恢復服務
您現在已經獲得了您認為診斷所需的所有時間點資訊，因此是時候讓網站客戶恢復業務了。
- 回收****最少數量的工作程序以恢復服務。
- 不要費心停止和啟動網站，您通常需要刷新應用程序池才能使網站再次執行，這就是資源回收筒的作用。
- 回收 App Pool 就足夠了 9/10 倍。
- 請注意，回收似乎發生在下一個請求進入時（即使現有的 WP 已被告知離開），因此工作程序可能不會立即重新出現。這並不意味著它沒有工作，只是沒有請求在等待。
- IISReset通常是不了解的人使用的工具。不要使用它，除非您需要所有網站都立即終止並重新啟動。（這就像試圖用磚頭將釘子釘在牆上。它可能會起作用，但你看起來有點像白痴，並且在某些時候會有附帶損害）。
- 您可能有其他應用程序依賴項 - 應用程序池取決於其他應用程序池、數據庫或外部系統……恢復服務所需的操作可以告訴您問題的範圍。列表中的最後一個是完全重啟，但除非核心級驅動程序真的搞砸了，否則這通常是沒有必要的，只是你無法確定哪個是必要的，它是一個有用的包羅萬象的東西……
確定原因 ，即查看並考慮您收集的數據。
- 獲取日誌和記憶體轉儲、尋找共性、吸引應用程序開發人員、使用DebugDiag（或更新版本）或 WinDBG 調試轉儲等等。
為下次安排
你知道你修好了嗎？如果沒有，特別是如果似乎沒有其他任何變化，請考慮如果再次發生更好的設置，您可能能夠捕捉到什麼。
- 不要假設這是最後一次發生- 根據這次製定計劃，為您下次需要收集的內容制定計劃。
- 例如，如果請求都針對同一個 URL，則實施一些額外的檢測或日誌記錄，或者一個失敗的請求跟踪規則，這將有助於辨識頁面上遇到問題的位置。
- 性能監視器日誌很有幫助（如果有疑問，也可以獲取 perfmon 日誌）。
- 查看其他可能有用的工具 - ProcDump、XPerf/WPT/WPR 等。如果你只有一把錘子，那麼每個問題都必須是釘子……
- 考慮在尋找實際根本原因時“掩蓋”問題是否可以接受 - 如果中斷非常嚴重，則可能可以接受調整應用程序池的回收設置以最小化可能性或持續時間（除非發生衝突能夠解決它）…