window7旗舰版开机说远程过程调试失败和rpc不可用
发布网友
发布时间：2022-05-01 09:09
共1个回答
热心网友
时间：2022-06-27 06:30
如果您多年来使用的都是 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 错误代码及其说明
错误代码 说明
58 指定的服务器不能执行请求的操作。
1721 没有足够的资源可用于完成此操作。
1722 RPC 服务器不可用。
1723 RPC 服务器太忙，无法完成此操作。
1727 远程过程调用失败，尚未执行。
1753 终结点映射程序没有提供更多的终结点。
解决 RPC 错误
既然您已掌握了检测某些 RPC 错误的方法，接下来就让我们看一下部分解决方案。
Microsoft 客户端会连接到端口 135 上的 RPC 终结点映射程序。然后终结点映射程序会告诉该客户端请求的服务在侦听哪一个端口。系统会动态分配这些端口号，可以是 1024 和 65,535 之间的任何端口号。当您遇到错误时，例如 1753，就表示终结点映射程序没有提供更多的终结点，这意味着 RPC 终结点映射程序无法对服务使用大于 1024 的端口。我们稍后再进一步讨论这个主题。
您需要做的第一件事是检查服务器上 RPC 服务的状态。根据服务器角色的类型，RPC 和 RPC Locator 服务应具有图 2中所列的状态。如果两个服务都没有像图中显示的那样配置，请尝试调整状态，重新启动服务器，然后进行测试，看它是否解决了您的问题。
Figure 2 RPC 服务的状态
服务器角色 RPC 服务 RPC Locator 服务
Windows Server 2003—域控制器 已启动，自动 已停止，手动
Windows Server 2003—成员服务器 已启动，自动 已停止，手动
Windows Server 2003—独立服务器 已启动，自动 已停止，手动
Windows 2000 Server—域控制器 已启动，自动 已停止，自动
Windows 2000 Server—成员服务器 已启动，自动 已启动，手动
Windows 2000 Server—独立服务器 已启动，自动 已停止，手动
请验证您的客户端是否可以成功地 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 故障排除工具
工具 说明
DCDiag 分析域控制器的状态。
事件查看器 显示记录的事件。
Gpotool 确定策略是否有效、一致。
NetDiag 用于测试网络连接。
Network Monitor 监视和捕获网络通信。
Ntdsutil 为 Active Directory 提供管理工具。
PortQry，PortQueryUI 用于 TCP/IP 连接测试。
Repadmin 诊断 Windows DC 之间的复制问题。
RPCDump 通常与 Network Monitor 一起使用。
RPCPing 用于确认 RPC 连接。
