【发布时间】：2017-06-12 09:49:20
【问题描述】：
因为与我们的管理员讨论的争论已经不多了，我希望你能帮助我解决以下问题。
我们有一个奇怪的行为对应于我们自己实现的 Windows 服务。他们随机冻结。有时他们会持续工作数周，有时他们会在一周内冻结多次。我很确定，错误的代码或未处理的异常没有问题。在我看来，这是某种 Windows 管理员/权限管理问题以及时间巧合。
但是让我们首先从一些信息开始：
- 所有 Windows 服务都在一台服务器上运行。
- 所有 windows 服务都由同一个 windows 用户执行。
- 服务器是虚拟机。 （VMWare，Windows Server 2008 R2）（我知道...）
- 这些服务是使用带有 .Net 4.0 的 VB.Net 实现的。 （我知道...不是我的决定 ;-)）
- 我们有 2 种不同类型的服务（称为 A、B）。
- 这两种服务都从目录中读取文件并将一些信息写入数据库。他们到底在做什么可能并不重要，因为这是某种标准任务。
- 每种服务都存在 3 个变体，它们是彼此的副本，但使用不同的 SQL 服务器来存储数据（称为 1、2、3）。
- 六项服务中的一项或两项似乎不定期冻结。
- 在 Windows 服务管理器中，冻结的服务被标记为“正在运行”。通过 Powershell 命令，服务也被标记为正在运行。
- 您无法看到与哪些服务冻结相对应的模式。有时，例如服务 A 变体 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
服务的最后一个生命迹象（假设它是服务 A 变体 2），此时再次冻结，是在 01:04:29，其中一个线程已退出。在 06:55:25，我们的一位管理员重新启动了该服务，因为他看到该服务似乎被冻结了。 DebugDiag 没有写入任何转储，因此我再次假设该服务没有崩溃。
对我来说很奇怪，wship6.dll、wshtcpip.dll、fwpuclnt.dll 和 security.dll 在重新启动服务时被卸载，因为我还没有看到这个。我多次尝试重新启动服务 A 的另一个变体，但没有被冻结。我看到了相同的条目，但它们是在第一次重新启动后才写的。即使在停止并再次启动服务后，我也看不到库已被卸载。
所以在查阅了很多资料后：
- 您能大致告诉我这些 Windows 库的任务吗？
- 是否有任何提示，服务器可能存在与用户权限管理/组策略相对应的问题？我知道，我们过去在团体政策方面遇到过问题。执行服务的用户的本地权限被一些无效的全局组策略覆盖。至少我是这么理解的。我正在开发，不从事管理工作。
- 我还能检查什么以确保代码确实没有问题/帮助我们的管理员解决这个烦人的问题？
编辑 16.06.2017： 昨晚是另一个 Windows 服务停止使用相同的行为。 Windows 服务的一些变体被冻结，而一些仍在工作。但是这次你看不到在重新启动服务时提到的 DLL 被卸载了。也许对卸载的 DLL 的第一次怀疑对进一步的诊断没有帮助。一个有趣的事实：该服务与第一个服务同时停止工作。虚拟机备份或类似的东西可能有问题？我想有一个常规任务导致了这个问题。你有什么提示吗？
编辑 19.06.2017： 我想我们发现了一些有趣的东西。冻结服务都有一个共同的 .Net 组件：文件系统观察器。这在过去从来都不是问题，因为我们扩展了 .Net-filesystemwatcher 并具有自重新连接功能。包含与我们的文件系统观察器相关的路径的文件服务器每晚都会备份。如果此网络路径不可用，我们的 filesystemwatcher 重新连接功能会每秒检查一次。如果是这样，则在路径再次可用后重新连接文件系统观察程序。管理我们所有虚拟服务器的托管服务器几天前已经升级。所以我们有以下怀疑： 假设我们的 Windows 服务在时间 t_1000 和 t_2000 检查网络路径。虚拟服务器备份在时间 t_1200 断开包含由文件系统观察程序监视的网络路径的虚拟文件服务器，并在时间 t_1500 重新连接路径。在这种情况下，我们的重新连接功能无法正常工作，因为在 t_1000 和 t_2000 网络路径可用。尽管如此，文件系统观察器还是失去了连接，并且不会对上述网络路径中的传入文件做出反应。这在以前不是问题，因为我们的备份软件触发的重新连接由于此服务器中使用的硬件较慢而需要多毫秒的时间。所以我们的重新连接功能运行良好。
那么我们能做些什么呢？
- 选项 1：联系我们的备份软件供应商。也许这是他的软件中的一个错误？
- 选项 2：永远不要再使用文件系统观察器，因为我们一直在处理网络路径。
- 选项 3：也许有一种方法可以进一步优化文件系统观察程序？文件系统观察器能否捕捉到任何这样的事件，这样我们就不必使用与计时器一起使用的重新连接功能？你怎么看？
提前非常感谢。
【问题讨论】：
标签： vb.net service freeze debugdiag rights-management