因爲我用盡討論與我們的管理員的爭論，我希望你能幫助我解決以下問題。Windows服務不規則地凍結
我們有一個奇怪的行爲對應於我們自我實現的windows服務。他們隨機凍結。有時他們會繼續工作數週，有時他們會在一週內凍結多次。我很確定，沒有問題的代碼不正常或未處理的異常。在我看來，這是一種Windows管理員/權限管理問題，與時間上的巧合相結合。
但是，讓我們有一些信息，在開始第一：
- 所有Windows服務是一個服務器上運行。
- 所有的Windows服務都由相同的Windows用戶執行。
- 服務器是虛擬機。 （VMWare，Windows Server 2008 R2）（我知道...）
- 這些服務是使用VB.Net和.Net 4.0實現的。 （我知道......不是我的決定;-)）
- 我們有2種不同的服務（稱爲A，B）。
- 這兩種服務都從目錄讀取文件，並在數據庫中寫入一些信息。這很可能不重要，他們正在做什麼，因爲這是一種標準任務。
- 每種服務都存在3種變體，即彼此的副本，但使用不同的SQL服務器來存儲數據（稱爲1,2,3）。
- 以不規則的間隔，六個服務中的一個或兩個似乎凍結。
- 在Windows服務管理器中，凍結的服務被標記爲「正在運行」。通過Powershell命令服務也被標記爲正在運行。
- 沒有任何模式可以查看哪些服務凍結。 Somethimes例如服務變體2被凍結，而變體1和3工作正常。重要提示：這3個變體背後有相同的代碼。
- 每項服務每天寫入一個日誌文件。查看凍結服務的日誌可以看到，沒有發生異常或錯誤記錄。這些服務剛剛停止了他們的工作。
- 沒有相關的信息，我可以在Windows事件中找到。
- 重新啓動凍結的服務總是有幫助的。有時你不能簡單地重新啓動它們。相反，你必須先阻止他們，然後開始他們。在這種情況下，您會看到「錯誤1061：此時服務無法接受控制消息」。這也是不規則的。
因爲我看不到任何記錄的錯誤，我在相應的服務器上安裝了DebugDiag，爲所提及的服務添加了崩潰規則，並且可能會發現一些有趣的內容。 這裏是DebugDiag資料日誌的摘錄：
[12.06.2017 01:04:05]
Thread created. New thread - System ID: 17372
[12.06.2017 01:04:29]
Thread exited. Exiting thread - System ID: 7152. Exit code - 0x00000000
[12.06.2017 06:55:25]
Thread created. New thread - System ID: 13252
Thread exited. Exiting thread - System ID: 31012. Exit code - 0x00000000
C:\Windows\System32\wship6.dll Unloaded from 0xfcee0000
C:\Windows\System32\wshtcpip.dll Unloaded from 0xfc650000
C:\Windows\System32\fwpuclnt.dll Unloaded from 0xfb1c0000
C:\Windows\system32\security.dll Unloaded from 0x6f9e0000
Thread exited. Exiting thread - System ID: 25912. Exit code - 0x00000000
Thread exited. Exiting thread - System ID: 17372. Exit code - 0x00000000
Thread exited. Exiting thread - System ID: 27412. Exit code - 0x00000000
Thread exited. Exiting thread - System ID: 13252. Exit code - 0x00000000
Thread exited. Exiting thread - System ID: 31768. Exit code - 0x00000000
Thread exited. Exiting thread - System ID: 27540. Exit code - 0x00000000
Thread exited. Exiting thread - System ID: 12252. Exit code - 0x00000000
Thread exited. Exiting thread - System ID: 29336. Exit code - 0x00000000
Thread exited. Exiting thread - System ID: 5620. Exit code - 0x00000000
Thread exited. Exiting thread - System ID: 8248. Exit code - 0x00000000
Thread exited. Exiting thread - System ID: 4340. Exit code - 0x00000000
Thread exited. Exiting thread - System ID: 18056. Exit code - 0x00000000
Thread exited. Exiting thread - System ID: 34164. Exit code - 0x00000000
Process exited. Exit code - 0x00000000
服務的最後的生命跡象（讓我們說這是一個服務變種2），這是在這個時候再次凍結，在01:04： 29，其中一條線已退出。在06:55:25，我們的一個管理員重新啓動了服務，因爲他看到服務似乎被凍結了。 DebugDiag沒有寫入轉儲，所以我再次假設服務沒有崩潰。
對我來說，奇怪的是，wship6.dll，wshtcpip.dll，fwpuclnt.dll和安全。dll在重新啓動服務時卸載，因爲我還沒有看到。我試圖重新啓動另一個服務變種A，這個變種沒有被凍結。我看到了相同的條目，但是隻有在第一次重新啓動後才寫入。即使再次停止並啓動服務，我也看不到圖書館已卸載。
所以很多的信息後：
- 你能告訴我大概這些窗口庫的任務嗎？
- 有什麼提示，服務器可能有問題對應於用戶權限管理/組策略？我知道，我們過去曾遇到組策略問題。執行服務的用戶的本地權限被一些無效的全局組策略覆蓋。這至少是我所理解的。我正在開發並且不執行管理任務。
- 我還能檢查什麼，以確保代碼真的沒有問題/幫助我們的管理員解決這個煩人的問題？
編輯16.06.2017： 昨晚，它是另一個窗口服務，停止與相同的行爲工作。 Windows服務的一些變體被凍結，有些仍在工作。但是這次你不能在重新啓動服務時看到提到的DLL被卸載了。也許第一次懷疑卸載的DLL不利於進一步的診斷。一個有趣的事實：這項服務與第一項服務同時停止工作。也許虛擬機備份或類似的東西存在問題？我想有一個導致問題的常規任務。你有什麼提示嗎？
編輯19.06.2017： 我想我們已經找到了一些有趣的東西。凍結服務都有一個共同的.Net組件：一個filesystemwatcher。這在過去從未成爲問題，因爲我們使用自重連接功能擴展了.Net-filesystemwatcher。包含與我們的文件系統監視器相關的路徑的文件服務器每天晚上進行備份。如果此網絡路徑不可用，我們的文件系統監視器重新連接功能會每秒檢查一次。如果是這樣，則在路徑再次可用後，重新連接文件系統觀察器。託管服務器管理着我們所有的虛擬服務器，幾天前已經升級。所以我們有以下懷疑： 假設我們的Windows服務在時間t_1000和t_2000檢查網絡路徑。虛擬服務器備份在時間t_1200斷開包含由文件系統監視程序監視的網絡路徑的虛擬文件服務器的連接，並在t_1500重新連接路徑。在這種情況下，我們的重新連接功能無法正常工作，因爲在t_1000和t_2000網絡路徑可用。文件系統觀察者仍然失去了連接，並且不會對所提及的網絡路徑中的傳入文件做出反應。這之前沒有問題，因爲我們備份軟件觸發的重新連接需要幾毫秒的時間，因爲此服務器中使用的硬件較慢。所以我們的重新連接功能工作正常。
那麼我們該怎麼辦？
- 選項1：聯繫我們備份軟件的供應商。也許這是他軟件中的一個錯誤？
- 選項2：永遠不要再使用文件系統監視器，因爲我們一直在使用網絡路徑。
- 選項3：也許有更好的方法來優化文件系統監視器？一個文件系統監視器可以捕獲這樣的事件，所以我們不必使用我們的重新連接功能，它正在使用一個定時器？你怎麼看？
非常感謝提前。