Windows-服务不定期冻结
Windows-Services freeze irregularly
因为我运行无法与我们的管理员讨论争论，希望您能帮助我解决以下问题。
我们有一个奇怪的行为对应于我们自行实现的 windows-服务。他们随机冻结。有时他们会连续工作数周，有时他们会在一周内冻结多次。我很确定，错误代码或未处理的异常没有问题。在我看来，这是某种 windows admin/rights 管理问题以及时间上的巧合。
但是让我们先从一些信息开始：
- 所有 windows 服务都在一台服务器上 运行。
- 所有 windows 服务均由同一 windows 用户执行。
- 服务器是虚拟机。 (VMWare, Windows Server 2008 R2) (我知道...)
- 这些服务是使用 VB.Net 和 .Net 4.0 实现的。 （我知道...不是我的决定 ;-)）
- 我们有 2 种不同的服务（称为 A、B）。
- 两种服务都从目录中读取文件并在数据库中写入一些信息。他们到底在做什么可能并不重要，因为这是某种标准任务。
- 每种服务都存在 3 个变体，它们是彼此的副本，但使用不同的 SQL 服务器来存储数据（称为 1、2、3）。
- 六项服务中的一项或两项似乎每隔一段时间就会冻结。
- 在 windows 服务管理器中，冻结的服务被标记为 "running"。通过 Powershell 命令，服务也被标记为 运行.
- 您看不到与哪些服务冻结相对应的模式。 Somethimes 例如服务 A 变体 2 被冻结，而变体 1 和 3 工作正常。重要提示：这 3 个变体背后有相同的代码。
- 每项服务每天写入一个日志文件。查看冻结服务的日志，您可以看到没有异常或错误记录。这些服务刚刚停止工作。
- 在windows个活动中没有找到相关信息。
- 重新启动冻结的服务总是有帮助的。有时您不能简单地重新启动它们。相反，您必须先停止它们，然后再启动它们。在这种情况下，您会看到 "error 1061: service cannot accept control messages at this time"。这也是不定期发生的。
因为我看不到任何记录的错误，所以我在相应的服务器上安装了 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 的最初怀疑无助于进一步诊断。一个有趣的事实：此服务与第一个服务同时停止工作。也许 VM 备份或类似问题有问题？我想有一个常规任务导致了这个问题。你有什么提示吗？
编辑 2017 年 6 月 19 日：
我想我们发现了一些有趣的东西。冻结服务都有一个共同的 .Net 组件：一个 filesystemwatcher。这在过去从来都不是问题，因为我们使用自重新连接功能扩展了 .Net-filesystemwatcher。包含与我们的 filesystemwatcher 相关的路径的文件服务器每晚都会备份。如果此网络路径不可用，我们的 filesystemwatcher 重新连接功能会每秒检查一次。如果是这样，则在路径再次可用后重新连接 filesystemwatcher。管理我们所有虚拟服务器的托管服务器已于几天前升级。所以我们有以下怀疑：
假设我们的 windows 服务在时间 t_1000 和 t_2000 检查网络路径。虚拟服务器备份在时间 t_1200 断开虚拟文件服务器，其中包含由 filesystemwatcher 监视的网络路径，并在 t_1500 重新连接路径。在这种情况下，我们的重新连接功能无法正常工作，因为在 t_1000 和 t_2000 网络路径可用。尽管如此，filesystemwatcher 失去了他的连接并且不会对提到的网络路径中的传入文件做出反应。这以前不是问题，因为由于此服务器中使用的硬件速度较慢，我们的备份软件触发的重新连接花费了一些毫秒的时间。所以我们的重新连接功能运行良好。
那我们能做什么呢？
- 选项 1：联系我们的备份软件供应商。也许这是他软件中的错误？
- 选项 2：永远不要再使用 filesystemwatcher，因为我们一直在处理网络路径。
- 选项 3：也许有进一步优化 filesystemwatcher 的方法？ filesystemwatcher 是否可以捕获任何此类事件，因此我们不必使用与计时器一起使用的重新连接功能？你怎么看？
非常感谢。
这是我们为感兴趣的每个人提供的解决方案：
备份软件的供应商知道这个问题，但不愿意修复它。所以我们决定创建一个新的虚拟机，用作我们需要的文件服务器。这个新的文件服务器将不会通过快照备份。
我没有找到进一步改进我们的 filesystemwatcher 的方法，所以我想这是我们解决问题的唯一机会。
因为我运行无法与我们的管理员讨论争论，希望您能帮助我解决以下问题。
我们有一个奇怪的行为对应于我们自行实现的 windows-服务。他们随机冻结。有时他们会连续工作数周，有时他们会在一周内冻结多次。我很确定，错误代码或未处理的异常没有问题。在我看来，这是某种 windows admin/rights 管理问题以及时间上的巧合。
但是让我们先从一些信息开始：
- 所有 windows 服务都在一台服务器上 运行。
- 所有 windows 服务均由同一 windows 用户执行。
- 服务器是虚拟机。 (VMWare, Windows Server 2008 R2) (我知道...)
- 这些服务是使用 VB.Net 和 .Net 4.0 实现的。 （我知道...不是我的决定 ;-)）
- 我们有 2 种不同的服务（称为 A、B）。
- 两种服务都从目录中读取文件并在数据库中写入一些信息。他们到底在做什么可能并不重要，因为这是某种标准任务。
- 每种服务都存在 3 个变体，它们是彼此的副本，但使用不同的 SQL 服务器来存储数据（称为 1、2、3）。
- 六项服务中的一项或两项似乎每隔一段时间就会冻结。
- 在 windows 服务管理器中，冻结的服务被标记为 "running"。通过 Powershell 命令，服务也被标记为 运行.
- 您看不到与哪些服务冻结相对应的模式。 Somethimes 例如服务 A 变体 2 被冻结，而变体 1 和 3 工作正常。重要提示：这 3 个变体背后有相同的代码。
- 每项服务每天写入一个日志文件。查看冻结服务的日志，您可以看到没有异常或错误记录。这些服务刚刚停止工作。
- 在windows个活动中没有找到相关信息。
- 重新启动冻结的服务总是有帮助的。有时您不能简单地重新启动它们。相反，您必须先停止它们，然后再启动它们。在这种情况下，您会看到 "error 1061: service cannot accept control messages at this time"。这也是不定期发生的。
因为我看不到任何记录的错误，所以我在相应的服务器上安装了 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 的最初怀疑无助于进一步诊断。一个有趣的事实：此服务与第一个服务同时停止工作。也许 VM 备份或类似问题有问题？我想有一个常规任务导致了这个问题。你有什么提示吗？
编辑 2017 年 6 月 19 日： 我想我们发现了一些有趣的东西。冻结服务都有一个共同的 .Net 组件：一个 filesystemwatcher。这在过去从来都不是问题，因为我们使用自重新连接功能扩展了 .Net-filesystemwatcher。包含与我们的 filesystemwatcher 相关的路径的文件服务器每晚都会备份。如果此网络路径不可用，我们的 filesystemwatcher 重新连接功能会每秒检查一次。如果是这样，则在路径再次可用后重新连接 filesystemwatcher。管理我们所有虚拟服务器的托管服务器已于几天前升级。所以我们有以下怀疑： 假设我们的 windows 服务在时间 t_1000 和 t_2000 检查网络路径。虚拟服务器备份在时间 t_1200 断开虚拟文件服务器，其中包含由 filesystemwatcher 监视的网络路径，并在 t_1500 重新连接路径。在这种情况下，我们的重新连接功能无法正常工作，因为在 t_1000 和 t_2000 网络路径可用。尽管如此，filesystemwatcher 失去了他的连接并且不会对提到的网络路径中的传入文件做出反应。这以前不是问题，因为由于此服务器中使用的硬件速度较慢，我们的备份软件触发的重新连接花费了一些毫秒的时间。所以我们的重新连接功能运行良好。
那我们能做什么呢？
- 选项 1：联系我们的备份软件供应商。也许这是他软件中的错误？
- 选项 2：永远不要再使用 filesystemwatcher，因为我们一直在处理网络路径。
- 选项 3：也许有进一步优化 filesystemwatcher 的方法？ filesystemwatcher 是否可以捕获任何此类事件，因此我们不必使用与计时器一起使用的重新连接功能？你怎么看？
非常感谢。
这是我们为感兴趣的每个人提供的解决方案：
备份软件的供应商知道这个问题，但不愿意修复它。所以我们决定创建一个新的虚拟机，用作我们需要的文件服务器。这个新的文件服务器将不会通过快照备份。
我没有找到进一步改进我们的 filesystemwatcher 的方法，所以我想这是我们解决问题的唯一机会。