因为我用尽讨论与我们的管理员的争论，我希望你能帮助我解决以下问题。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：也许有更好的方法来优化文件系统监视器？一个文件系统监视器可以捕获这样的事件，所以我们不必使用我们的重新连接功能，它正在使用一个定时器？你怎么看？
非常感谢提前。