我目前有2個csrss.exe在系統下運行，每個使用1700kb - 2156kb記憶體。與它們相關的似乎有 2 個 conhost.exe，其中一個使用大約 1000kb 內存，另一個使用 1400kb。一種是系統，一種是網路。我在我的系統中發現了2個csrss.exe，一個在system32中，一個在winsxs/amd64_microsoft中（有大量數字）我在system32中發現了1個conhost，在winsxs/amd64_microsoft中發現了8個conhost ，後面跟有數字，如csrss。這是正常的嗎？我也可能看到第三個 conhost 正在運行，但我不認為它附加到 csrss
使用事件檢視器日誌和進程資源管理器，我發現 csrss 下的 2 個 conhost 檔案是在 15:33:52 啟動的（在我的測試中）。同時，在系統下的事件檢視器中，MBAM服務進入運作狀態。另外，伺服器服務進入運作狀態。大約一、兩秒後啟動的其他服務： 網路清單服務 診斷服務主機 人機介面裝置存取 Microsoft 網路檢查 診斷系統主機 可攜式裝置枚舉器 電腦瀏覽器服務 事件檢視器的應用程式部分中沒有條目。在安全下，15:33:52 有一個條目：
審核成功：帳號登入成功。主題 ID：null sid（同一條目的下方）
新登入： 安全 ID：匿名登入 帳號名稱：匿名登入 帳號網域：nt 權限
該條目還有其他幾個部分。這很糟糕嗎？早在一年前我拿到電腦的那天，我就發現了一些匿名登入條目，所以我認為這還不錯。家裡的另一台電腦的硬碟上有相同數量的conhost 和csrss.exe 檔案（大約8-9 個，在amd64 安裝資料夾中，以及在system32 下運行的電腦和csrss 檔案。另一台電腦有2個csrss 進程正在運行但沒有 conhost。我將運行一些安全模式掃描。 （Mbam 和 MSE）。掃描結果已經乾淨了。
這是我運行 Geforce experience 時的映像，該 conhost 出現並很快關閉。
答案1
任何時候您看到 ConHost.exe 都意味著正在執行非 GUI 程式。當您開啟命令提示字元或應用程式安裝程式需要執行標準「DOS」命令作為安裝例程的一部分時，就會發生這種情況。 ConHost.exe 進程來來去去是很正常的，只有當您有許多（20-30+）實例持續一段時間以上時才應該引起關注。此外，您可以觀察與 ConHost.exe 進程啟動和停止相關的程式和服務啟動/停止活動，因為在程式生命週期的這些時候，它們經常需要與非 GUI 互動應用。
如果你想更深入地挖掘，這篇文章http://blogs.technet.com/b/askperf/archive/2009/10/05/windows-7-windows-server-2008-r2-console-host.aspx解釋了新新增的內容（從 Windows 7 開始）ConHost.exe 及其要解決的問題：
在先前的 Windows 版本中（即 Windows 7 之前的版本），代表在桌面上執行的非 GUI 應用程式（控制台應用程式）的所有 GUI 活動均由系統進程 CSRSS.exe 代理程式。
如果您非常了解 Windows 如何處理使用者之間的權限分離，您可能會正確地看到潛在的弱點，請在本文繼續時確認：
這樣做的問題是，即使應用程式在普通使用者帳戶的上下文中運行，CSRSS.EXE 也會在本機系統帳戶下運行。因此，在某些情況下，惡意軟體可能會利用應用程式中的弱點，以便在 CSRSS.EXE 中具有更高特權的本機系統帳戶下執行程式碼。
Windows 7 透過引入 ConHost.exe 進程永久改變了這個模型：
此漏洞已在 Windows 7 和 Windows Server 2008 R2 中透過在新進程 ConHost.exe 的上下文中執行控制台訊息傳遞程式碼得到解決。 ConHost（控制台主機）與其關聯的控制台應用程式在相同的安全上下文中運行。該請求不是向 CSRSS 發出 LPC 請求以進行訊息處理，而是發送至 ConHost。
希望有幫助！
編輯：
兩個csrss.exe實例都沒有異常。我在已知乾淨的計算機上多次觀察到這種情況。如果你不如果有兩個執行個體正在執行，只需啟動 CMD.EXE，您可能最終會得到託管 conhost.exe 子執行個體的 csrss.exe 的第二個執行個體。
在您的情況下，我沒有看到任何證據表明它們是 csrss.exe 的第二個實例或 conhost.exe 的多個實例的惡意原因。