NtpClient 将等待 3473457 分钟（超过 6 年！），然后才会再次尝试 DNS 解析，事件 ID 134

Question

我觉得这条消息很搞笑，一开始我以为这是微软团队某个过度活跃的程序员开的玩笑，或者是一个骗局。然而，这条消息一次又一次地出现，一天出现几次：

NtpClient 无法设置手动对等端作为时间源，因为 '' 上的 DNS 解析错误。NtpClient 将在 3473457 分钟后重试，然后将重试间隔加倍。错误为：请求的名称有效，但未找到请求类型的数据。（0x80072AFC）

来源：时间服务
事件 ID：134
级别：警告

我怀疑我的时间服务器配置不正确。这是真的吗？我该如何修复？但为什么会出现这么奇怪的消息？

笔记：我在 Technet 上报告了此问题，您可以在其中找到为什么这个数字如此奇怪的解释（因此，两个答案也找到了该链接并在答案中使用了它；））。

Answer 1

我知道这是一个老问题，但我自己的研究发现technet 上的这篇文章。

据称，长时间延迟的原因是事件查看器的输出错误。事件查看器将注册表中的字符串值“15”的原始数据误解为数字。

可以发现注册表NtpClient\ResolvePeerBackoffMinutes的值为15，事件日志中的输出为3473457 = 0x00350031，这是Unicode字符串“15”的小端格式。

- Alex Zhaozx - MSFT CSG

Answer 2

只是添加一些更多信息，以防其他人在搜索中遇到此问题。此事件查看器消息有一些令人不安的事情：

1. 事实上，您的客户端无法进行 NTP 同步。
2. 事实上，DNS解析错误出在“”，而不是实际的主机名。
3. 事实上，重试间隔非常长。

我的几个工作站上也收到了完全相同的消息（Windows 7，加入 2003 级域）。

关于第 1-2 项，我注意到这些消息仅在工作站进入睡眠状态时显示。它们在 Kernel-Power 消息显示 1 秒后显示，表明计算机因系统空闲而进入睡眠状态。同时，许多网络服务也在暂停。我的理论是时间服务只是确定网络已经消失。DNS 可能在此时停止，因此得名 ''。

在此之前，我大约 15 分钟前看到了来自 Time-Service 的事件查看器消息，表明同步成功。因此，这不太可能是配置问题。

查看事件查看器中消息的上下文。如果您在计算机进入休眠或关闭状态时看到此消息，则没什么大不了的。如果您在正常运行期间看到此消息，则表示有问题。 在这种情况下，做一个w32tm /resync /rediscover并从那里开始。

至于第 3 项，事实证明这是字符串打印方式的一个错误。它对 unicode 产生了错误。它应该打印 15 分钟。参见此处：

http://social.technet.microsoft.com/Forums/windows/en-US/34987a99-3bc6-4a73-b859-6eab6a53cafe/why-is-the-ntpclient-waiting-3473457-minutes-6-years-for-a-new-timesync-and-what-is-so-special?forum=w7itpronetworking

Answer 3

请求的名称有效，但未找到请求类型的数据。（0x80072AFC）

按照#2

关于第 1-2 项，我注意到这些消息仅在工作站进入睡眠状态时显示。它们在 Kernel-Power 消息显示 1 秒后显示，表明计算机因系统空闲而进入睡眠状态。同时，许多网络服务也在暂停。我的理论是时间服务只是确定网络已经消失。DNS 可能在此时停止，因此得名 ''。

Answer 4

是的，您的时间服务器配置错误。要么是它没有上游服务器可以同步，要么是您在防火墙中阻止了端口（端口 123 UDP）。

为什么数字这么大？错误消息中已经给出了解决方案：“然后将重试间隔加倍。”所以它从几秒钟开始，然后加倍、加倍、加倍……

这些都在有关 Microsoft 时间服务的文档。