IT 运作方式排除 RPC 错误

Zubair Alexander

如果您多年来使用的都是 Windows 服务器平台，那么可能曾经看到过远程过程调用 (RPC) 错误。它们提示您 RPC 服务器无法使用，或者没有更多的可用终结点，或提供某个其他难懂的警告。如果您对这些消息感到困惑，请继续阅读。我会

谈到一些比较常见的错误，以及可用来识别所遇到的 RPC 错误的各种技术，并会讨论一些可以解决某些特定问题的解决方案。但是在我讨论 RPC 错误和解决方案之前，先让我们大致了解一下 RPC 技术。

什么是 RPC？

RPC 是一种进程间通信 (IPC) 方法，客户端和服务器可使用这种方法来进行相互之间的通信。简单地说，RPC 可被程序（通常是客户端计算机上的程序）用来执行服务器计算机上的程序。例如，Microsoft® Outlook® 客户端可通过使用 RPC 与 Microsoft Exchange Server 通信。客户端计算机会使用某些参数将消息发送到服务器计算机。而服务器则会以一条包含执行程序的结果的消息响应客户端。

此过程的组成部分是终结点，即计算机上的名称、端口或端口组，由服务器监视经过其传入的客户端请求。更具体地讲，它是用于 RPC 的服务器进程特定于网络的地址。

终结点映射程序 (Endpoint Mapper) 是 RPC 子系统的一个组成部分，负责响应客户端要解析动态终结点的请求。在某些情况下，终结点映射程序还负责动态地将终结点分配给服务器。

另一个重要的 RPC 组件就是 Locator 服务。它维护网络上的 RPC 服务和服务器列表。Windows® 客户端会连接到服务器消息块 (SMB) 端口（TCP 139 和 445）上的域控制器，并通过 Locator 服务搜索 RPC 服务或服务器。

大多数内置的 Windows 服务都通过 RPC 相互通信。例如，证书服务、DCOM、FRS、MSMQ、MAPI 和 Active Directory® 复制服务都使用 RPC 来进行通信。因此，如果 RPC 服务不能网络上正常运行，则您可能就会遇到很多通信问题。

RPC 错误

现在让我们看一些 RPC 服务失败时您可能会遇到的错误。（这并不是完整的列表。）

当文件复制服务 (FRS) 失败时，运行时可能会出现可怕的“RPC 无法使用”错误。当您试图映射一个驱动器时，可能会遇到“拒绝访问”错误。当使用 Active Directory 用户和计算机时，可能会看到错误消息“指定的域不存在或无法联系。”登录域时，可能会看到一条错误消息，指明“缺少该系统主域的计算机帐户或该帐户的密码不正确，无法让您登录此域。”

当 Microsoft Outlook 客户端试图与 Exchange Server 通信时，RPC 失败可能会导致客户端遇到“您的登录信息不正确”或“Outlook 无法登录”等令人误解的错误。

除了这些错误外，当 RPC 服务不可用时，您可能还会遇到其他问题。例如，可能会无法浏览“网上邻居”中的域，或者可能无法打开“组策略”管理单元。

这些只是一部分示例而已，在这些示例中您可能没想到 RPC 会引起问题。在更多示例中，以及在涉及远程过程的任何时候，RPC 问题都有可能是造成您困境的根本原因。那么您要如何确定，以及更重要的是，如何跟踪到精确的错误呢？让我们来了解一下。

故障排除

如果您怀疑您的 RPC 服务遇到了问题，您可以使用好几个工具来诊断这些问题。

一个是 Repadmin 工具。这个程序通常是用来监视和排除 Active Directory 复制问题，但是它也可以用来排除 RPC 终结点映射程序的问题。要运行该工具，可在命令提示符下键入 repadmin /bind。如果您遇到了 RPC 问题，会看到类似下面这样的消息：“终结点映射程序没有更多可用的终结点。”这是与 RPC 相关的问题的第一个提示。

另一个选择是使用“域控制器”诊断工具 (DCDiag)，这是一个通过域控制器诊断问题的命令行程序。如果您看到错误“状态为 1722：RPC 服务器无法使用”，您就知道遇到了“域控制器”诊断工具恰巧发现的 RPC 问题。

很多时候，您都在使用 Ntdsutil（用来管理 Active Directory 和执行大量维护任务的命令行工具），这个时候如果您试图连接到服务器，就可能会遇到 RPC 错误。最有可能的就是您会看到更常见的错误之一，例如“终结点映射程序没有提供更多的终结点”。同样，这是 RPC 可能存在问题的一个提示。如果真是 PRC 存在问题，检查域控制器上“组策略”对象一致性的 Gpotool 工具也会报出同样的错误。

使用 Dcpromo 工具将 Windows 2000 Server 或 Windows Server® 2003 服务器提升为域控制器时产生的 Dcpromo.log 也可以显示 RPC 的问题。例如，如果提升失败，可以查看一下该日志。它位于 %windir%\debug 文件夹。列出的错误大意是目录服务无法复制分区，或无法创建对象。在此消息结束的地方会有一个错误代码。下面是您可以在 Dcpromo.log 中看到的错误消息类型的一个示例：

 
08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)

注意错误代码 1722，在这条消息中出现了四次，这指明 RPC 服务器无法使用。图 1 列出了部分错误代码及其说明，更多的错误代码及其说明可以在 msdn2.microsoft.com/ms681386 中找到。

Figure 1 错误代码及其说明

解决 RPC 错误

既然您已掌握了检测某些 RPC 错误的方法，接下来就让我们看一下部分解决方案。

Microsoft 客户端会连接到端口 135 上的 RPC 终结点映射程序。然后终结点映射程序会告诉该客户端请求的服务在侦听哪一个端口。系统会动态分配这些端口号，可以是 1024 和 65,535 之间的任何端口号。当您遇到错误时，例如 1753，就表示终结点映射程序没有提供更多的终结点，这意味着 RPC 终结点映射程序无法对服务使用大于 1024 的端口。我们稍后再进一步讨论这个主题。

您需要做的第一件事是检查服务器上 RPC 服务的状态。根据服务器角色的类型，RPC 和 RPC Locator 服务应具有图 2 中所列的状态。如果两个服务都没有像图中显示的那样配置，请尝试调整状态，重新启动服务器，然后进行测试，看它是否解决了您的问题。

Figure 2 RPC 服务的状态

请验证您的客户端是否可以成功地 Ping 存在连接问题的服务器。例如，如果您在与 IP 地址为 192.168.1.200，名为 DC1 的服务器通信时遇到了问题，则在命令提示符下使用下面的命令来验证 DNS 是否在正确地解析主机 DC1：

Ping –a 192.168.1.200

请确保是将 –a 开关与 IP 地址（而不是主机名）搭配使用。

如果一切顺利，您应该会得到 DC1 的响应，如图 3 中所示的 Ping 响应。注意 Ping 不只是解析 IP 地址 192.168.1.200，还解析主机名 dc1.contoso.com。这确定了 DNS 名称解析在正常运行，并且如期望的那样正确地解析到主机 dc1.contoso.com。

Figure 3 Ping 响应

C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms

您还应确保 Windows XP 或 Windows 2000 客户端上的注册表至少包含图 4 右窗格中列出的四个 ClientProtocols。

图 4** 列入注册表的 RPC ClientProtocols **

如果缺少任一项，则添加一个图 4 中所示名称和数据类型的新字符串值。在默认情况下，还有一个名为 ncacn_nb_tcp 的第五项，它可用来识别基于 TCP 的 NetBIOS，将其作为终结点的协议家族。根据您的配置，您的 ClientProtocols 下可能没有列出这一项，这时您可以手动添加此项以查看它是否解决了 RPC 错误。

注意列在图中左窗格中的 Rpc 文件夹下的项，即 ClientProtocols、NameService、NetBios 和 SecurityService。如果您恰巧看到名为 Internet 但没有值的项，请尝试删除该项，然后重新启动您的计算机。这可能会帮助您解决问题。但是在您修改 Windows 注册表时始终要非常小心。

如前面所述，RPC 可以使用 1024 到 65,535 之间的端口，因此您需要确保这些端口没有被防火墙封锁。要确保端口开放的最简单的方法就是使用“端口查询”工具。这个工具有两种类型：命令行版本 (PortQry) 和 GUI 版本 (PortQueryUI)。

PortQry 可在 Microsoft 下载中心下载。有关其他信息，请查看文章“有关 Portqry.exe 命令行实用工具的说明”。在那里您可以找到 PortQry 状态报告的简要说明以及用来解决问题的命令示例。请不要忘记您还可以使用 GUI 版本，它更加简单，可以在 go.microsoft.com/fwlink/?LinkId=73740 下载。

使用“端口查询”时，您应该确保在没发生过 RPC 错误的计算机上运行它，并且是针对发生了 RPC 问题的计算机来运行它。例如，如果您想验证端口 135（它被 RPC 终结点映射程序占用）是否开放，可以在命令提示符下使用 PortQry，如下所示：

portqry -n [servername] -e 135

无论您使用的是 PortQuery 还是 PortQueryUI，您都会获得结果，如下所示：

Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING

最后一行显示端口 135 是开放的。否则，最后一行会指明“未侦听”。

要查看端口的范围，请输入以英文逗号隔开的端口号范围，例如“135,1024-5000”。

其他解决方案

如果尝试了目前列出的所有办法还是没有解决您的问题，这里还有一些其他方法供您选择。根据您环境中的具体问题，您可能想要尝试对注册表进行下列其中一项修改。（等等！在修改注册表前，请确定您已备份您的系统，尤其是注册表，这很重要；这样如果真的发生错误，您可以将您的计算机恢复到之前的状态。)

一个方法是调整 MaxUserPort，以指定当应用程序请求系统的可用用户端口时 TCP 可分配的最大端口号。在默认情况下，Windows Server 2003 会将 MaxUserPort 的值设置为 5000，这表示它以 5000 作为最大端口号，即使此项不存在。根据您的配置，您的注册表中可能没有此项，这时您可以将此项添加到图 5 所示的位置。

图 5** 注册表中的 MaxUserPort 设置 **

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000

在修改注册表时，您需要注意任何其他潜在的负面影响，它并不总是那么容易。如果将这个值设置为 50,000，则修改此项可能会对 Microsoft Exchange Server 有影响。如果 Exchange Server 最佳实践分析工具 (BPA) 发现 MaxUserPort 注册表项的值小于 50,000，它会显示一个警告。Microsoft 建议您将值设置为 60,000；否则您可能会引发命名服务提供程序接口 (NSPI) 代理警告，例如事件 9040。有关详细信息，请参阅 Microsoft 的文档“MaxUserPort 值太小”。

您还可以调整 TcpMaxDataRetransmissions。TCP 数据包期望能收到接收端的确认。如果在计时器到时之前还没有确认，则会重传数据包，最多 TcpMaxDataRetransmissions 次。此参数的默认值是 5，但是您可能想尝试 4 或 3 这些值。请不要使用小于 3 的值。

如果 TcpMaxDataRetransmissions 注册表项不存在，您可以将它添加到注册表的下列位置，如下所示：

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5

有关 TcpMaxDataRetransmissions 的详细信息，请参阅 Microsoft 知识库文章 170359“如何修改 TCP/IP 最大重传超时时间”。

另一个您可能想实验的注册表项是 TcpTimedWaitDelay。如果用户端使用了过多的端口，很可能它会在 TCP/IP 释放关闭的连接之前用尽端口。这是因为 TCP/IP 直到经过段最大生存时间 (MSL) 的两倍时间后才会释放连接（这称为时间等待状态）。此外，因为每个 MSL 都被定义为 120 秒，而 TCP/IP 直到经过 2 个 MSL 后才会释放连接，因此需要长达 240 秒（4 分钟）的时间才能让 TCP/IP 释放一个关闭的连接。注意，这是一个使用 Service Pack 进行改正后的 Windows NT® 中已知的问题；因此目前您不太可能会遇到这个问题。但是，Microsoft 建议调整这个设置，使之成为一个可以解决 RPC 终结点映射程序错误的可能解决方案，正如知识库文章“如何排除 RPC 终结点映射器错误”中所说明的一样。

可将 TcpTimedWaitDelay 添加到注册表的下列位置：

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD 
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)

有关 TcpTimedWaitDelay 的详细信息，请参阅知识库文章“Windows NT 客户端用尽端口”。尽管该文章没有建议任何特定的数字，但是您可能会想将 TcpTimedWaitDelay 降到以十进制表示的 60（秒），而以十六进制表示则为 3c。

结束语

RPC 错误可能是您的网络出现各种通信错误的根本原因。幸运的是，您现在有好几种创新方法，可以帮助排除这些难以捕捉的问题。我在这里推荐的工具有些是内置的，有些是 Windows Server Resource Kit 中提供的。很多都已在图 6 中列出。您可以使用这些工具来检测 RPC 错误的原因和位置，然后使用本文列出的其中一项技术来解决这些错误。

Figure 6 RPC 故障排除工具

Zubair Alexander 是 MCSE、MCT 和 Microsoft MVP，也是一家 IT 培训和咨询企业 SeattlePro Enterprises 的所有者。他的经验涉及 IT 培训领域的诸多方面：作家、大学教授、顾问、网络工程师、公开演讲人、安全架构师、系统管理员、技术编辑和培训师。您可以通过 alexander@techgalaxy.net 与 Zubair 联系。

© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.