我們有大約 200 台伺服器、Hyper V、檔案群集和 IIS，它們都遇到相同的問題，正常使用時在伺服器上發生一個事件，導致伺服器上的 RAM 達到或接近最大。一旦發生這種情況，SVCHOST/工作站服務，特別是（透過將工作站服務隔離到它自己的 SVCHOST 來清除）將停止釋放句柄/線程，並且該服務使用的記憶體永遠不會釋放。在某些極端情況下，我們的工作站服務在 255GB 伺服器上使用多達 40GB 的 RAM。在某些情況下還發現了超過 4000 萬個句柄。
重新啟動後，問題當然會消失，並且不會再次出現，直到所有記憶體都被使用（例如 W3 進程或 HyperV VM），之後，工作站服務開始取得所有 RAM。這個過程非常緩慢，可能需要數週/數月的時間，具體取決於伺服器上的 RAM 量。
我們的 Hyper V 伺服器和 IIS 伺服器都存取工作文件的共享，這些共享位於 SSD 儲存空間上，因此它們具有足夠的效能。我們已經安裝了所有當前補丁，但尚未轉移到 R2，因為我們有很多工具，這將使這成為重要的一步，但找不到任何明確的跡象表明這將在 R2 中修復。
我們已經運行了 ProcMon 和其他工具，但在問題最嚴重的伺服器上，這些工具甚至無法運作。在其他方面，他們提供的結果只是表明該進程中似乎確實存在記憶體洩漏。
有沒有一種方法可以釋放此進程的記憶體或同時避免該錯誤？我們不想重新啟動，而且一旦進程處於錯誤狀態，我們就無法重新啟動該進程。該過程被凍結。
我們試圖避免定期重新啟動來「修復」此問題，因此我們將不勝感激。
答案1
我遇到了一個非常相似的問題，svchost 正在破壞伺服器效能。
解決方案：原來我有完整的事件日誌。我把它清理乾淨了，一切都恢復正常了，就像什麼都沒發生過一樣。
（我還建議更改事件日誌的預設大小，請參見下文）
使用 Windows 介面設定最大日誌大小
- 啟動事件檢視器。
- 在控制台樹中，導覽至並選擇要管理的事件日誌。
- 在「操作」功能表上，按一下「屬性」。
- 在「最大日誌大小 (KB)」中，使用微調器控制項設定所需的值，然後按一下「確定」。
這聽起來和這裡發生的情況一模一樣，但最終是一個非常簡單的修復。重新啟動可以暫時解決問題，但是一旦有任何內容嘗試寫入日誌，一切就會失控，並不斷消耗資源。
希望這可以幫助！
答案2
>Is there a way we can free up the memory from this process ?
您無法在不殺死有問題的應用程式的情況下從外部（正確）釋放分配的記憶體或處理資源。
>or avoid the bug all together?
您遇到內存和資源洩漏。解決問題的唯一方法是找到洩漏並避免其觸發（如果可能）或在原始程式碼層級修復洩漏；在最後一種情況下，您需要微軟幫助來製作補丁，但他們似乎希望您「準確」地告訴他們問題到底出在哪裡。
您可以嘗試使用 ie MS 找出記憶體/資源洩漏來找到罪魁禍首應用驗證器
答案3
創建 RAM 很容易，但沒有解決方案。
我建議 Sysinternals RAMMAP 或 VMMAP 進行更深入的研究。有了這些工具，您可以更好地了解發生了什麼。通常是圖元文件問題。
自 Server 2008 以來，我們遇到了所有終端伺服器記憶體不足的問題，當從共享啟動應用程式時，隨著時間的推移，記憶體消耗令人難以置信。
我們的解決方法是將應用程式託管在單獨的終端伺服器上，並經常清除記憶體消耗。
我們使用自行設計的 C++ 命令列應用程式來執行此操作，
在所有進程上使用 SetProcessWorkingSetSize() 和 SeDebugPrivilege
強烈建議不要做這樣的事情;)