本文介绍如何使用Network Monitor 3.0修改一个远程脚本的错误，原文发布于WindowsNetworking.com。

在上一篇文章《修复神秘的错误——使用脚本管理Windows网络》中，我们开始修复一个神秘的错误，这个错误发生在我们尝试使用我们开发的脚本ChangeIPAddress.vbs远程修改一个XP主机的IP地址的过程中。这个神秘错误是这样的：

在前一篇文章中，我提到我已经联系了一些脚本高手一起解决这个错误，其中我收到最好的答案是可能有一个热补丁（Hotfix）破坏了WMI的功能，结果这个脚本虽然在远程工作了但却产生一个错误。

但是，后来有一个聪明的读者联系我并给了我这样的评论：

“在我看来这不是任何一个热补丁上发生的错误。记住你正在修改XP2的IP地址。远程过程调用失败了是因为它失去了XP2在原来IP地址（172.16.11.43）的连接。然后它花了一段时间（大约1分钟）在新的IP地址上（172.16.11.65）寻找XP2，直到最后放弃了。”

“想象你作为管理员Telnet到一个服务器，然后修改服务器的IP地址。你会失去与服务器连接吗？它会僵死一段时间，这与我们脚本的现象是一样的。但是修改服务器的默认网关将不会打断已存在的（Telnet）连接（假定你在同一个子网内）。如果你尝试从远程位置修改默认网关，你应该也会经历相同的延迟。”

非常对！我们要怎么测试这个解释呢？

使用Network Monitor 3.0

Microsoft最近发布了一个新版本的Network Monitor，一个作为Microsoft Systems Management Server一部分的包探测工具。Network Monitor 3.0比起之前的版本已经有了好几处的改进，诸如以下几项：

• 新的功能是，改进了用户界面，当他们正在实时捕捉时能够显示帧；
  
• 多种并发的会话捕捉和多个网络适配器并发捕捉；
  
• 显示网络“会话”的能力，比如，特殊协议的会话；
  
• 支持Vista，Windows XP和Windows Server 2003，包括32位和64位平台；
  
• 新的过滤面板支持手动指定过滤规则。

更多关于Network Monitor 3.0的信息，见Paul Long在TechNet的博客。

然后这是我的计划。我将在运行ChangeIPAddress.vbs脚本的主机上，通过使用NM3捕捉一个网络轨迹。我的测试步骤如下：

但在我尝试在Test124上运行ChangeIPAddress.vbs来修改test125的IP地址之前，让我们快速地浏览一下NM3。

当你启动NM3时，它的界面是这样的（图1）：

图1：Network Monitor 3.0启动页面

在我继续阐述之前，让我们选择“Enable Conversations”复选框，这样我们就可以浏览每一种在我们跟踪过程中出现的协议的会话。

现在点击“Create A New Capture Tab”。将会打开一个名称为“Capture1”的新标签，我们可以用这个来创建我们的网络跟踪（图2）：

 

图2：打开一个新的捕捉标签

现在让我测试NM3的一些简单功能。我们将点击“Play”按钮开始一个捕捉，然后我们将在主机test124上打开命令提示符并输入“ping 172.16.11.125”——我们从主机test124上ping主机test125。结果是这样的（图3）：

图3：跟踪对172.16.11.125的ping操作

这就是我们所期待的：2个ARP数据包（一个ARP请求和一个ARP响应），然后是一系列的ICMP数据包（Echo请求消息和Echo回复消息）。如果你知道基本的TCP/IP网络，这会更容易理解。

让我们看看发生的“会话”。展开“My Traffic”节点就可以显示这些会话，如图4所示：

图4：显示会话

注意有两个会话发生：ARP和IPv4（ICMP）。同样，如果你知道基本的TCP/IP网络，很明显，你会相当容易地理解这个。

现在让我们选择ARP请求数据包并查看其内部信息（图5）：

图5：检查一个数据包

现在我们已经简单地介绍了NM3（还有更复杂的）。让我们尝试用它来修改我们神秘的错误吧。

捕捉跟踪

我将从重启两个工作站以清除所有缓存（ARP，DNS等）开始，然后我将在test124打开一个命令提示符，并输入“ChangeIPAddress.vbs 172.16.11.144”，以便将test125的IP地址从172.16.11.125修改成172.16.11.144。（我已经将目标计算机test125写到这个脚本中。）下面就是运行的结果（图6）：

图6：运行ChangeIPAddress.vbs 172.16.11.144的结果

这是所发生的概述：捕捉持续了总共90秒，捕捉到274个帧。错误消息发生在第241个帧，命令提示符在第274帧返回。（我之所以知道这些是因为在跟踪正在捕捉时，我在观察命令行输出。）这里有许多的流量要分析！看一下上面的图6，我们至少可以开始分析它了：

• 帧3-4显示主机名TEST125正被DNS转换成IP地址172.16.11.125。
  
• 帧5-6显示IP地址172.16.11.125正被ARP转换成一个MAC地址。
  
• 帧7-9显示一个三向TCP握手（SYN，SYN/ACK，ACK）在test124和test125之间发生。
  
• 帧10-11显示一个ROC绑定正在2个主机间建立。
  
• 帧12-13显示DCOM正在RCP（WMI使用DCOM处理远程调用）间使用。

……等等。

显然我们不能在图中显示所有的274个帧，所以我将Frame Summary信息拷贝到一个文本文件。（我也将捕捉另存为一个.cap文件。）你可以点击这个链接（Frame Summary）查看我们运行ChangeIPAddress.vbs的结果。

这是非常难懂的，不是吗？我们要怎么才能理解这个捕捉正在说什么呢？

当你在修复故障时，最好是从你了解的地方入手，而不是从不懂的地方开始。而我们知道我们在前一篇文章中开发的其他脚本（ChangeGateway.vbs）都是正常工作并不会产生任何错误消息的。所以在我们继续探究ChangeIPAddress.txt之前，让我们重启我们的工作站并执行另一个捕捉，这次显示在test124上运行命令“ChangeGateway.vbs 172.16.11.2 1”的结果，它将test125的默认网关从172.16.11.1修改成172.16.11.2（并指定跳数为1）。这是第二次捕捉的结果（图7）：

 
图7：运行“ChangeGateway.vbs 172.16.11.2 1”的结果

你可以从Frame Summary看到这次只有217帧需要分析。

分析ChangeGateway.vbs的捕捉

让我们尝试通过将帧概要（Frame Summary）分成一块块地分析第二个捕捉（运行后不产生任何错误的）。如下所示：

这只是NM3的头信息——可以忽略它。

这是名称和地址解析信息（DNS和ARP）

Test124刚刚与Test125建立一个TCP连接。

Test124建立一个与Test125绑定的RCP并调用DCOM。

提示：如果你对理解这个跟踪的RPC部分存在困难的话，可以链接see KB 159258 for help。

这个是主机间的另一个TCP三向的握手。

Kerberos身份验证（2个主机都是域联结的）。

这是更多的RPC和DCOM。我认为“Alter Cont”表示正在使用替代的上下文，但我不能保证是这样的。同样的，既然脚本已经正常工作并不产生任何错误，那么一切运行就必然是OK的。

这里是另外一个TCP握手。

这是更多的Kerberos信息。

这里还有许多的RPC/DCOM信息。看起来很奇怪，对吗？如何你仔细观察你会看到有一些WMI信息出现，如WMI-IWbemLoginClientID，WMI-IWbemLevel1Login， WMI-IWbemServices，WMI-IWbemFetchSmartEnum等等。搜索MSDN我们会知道更多关于这里的具体细节。比如，Microsoft Developer Network库告诉我们“IWbemServices接口是客户和提供者用于访问WMI服务的”，所以看起来似乎所有这些I-thingies都是WMI接口（API），而这些接口是在我们运行脚本的工作站上的远程主机（使用DCOM）正在调用的。并且事实上这些接口中有一些似乎没有文档化，所以我们将不用太着急去理解它们。

从这里开始东西变得越来越多。首先会有更多的TCP信息和ROC“Continued Response”数据包，这些数据包似乎暗示之前建立的连接正在被用于某些用途。我准备从跟踪的下一部分开始忽略一些帧：

现在仅仅过去两秒钟而已。现在有一组DCOM信息，随后是使用FIN/ACK来中断TCP连接，所以我猜想这个脚本很可能已经完成它的工作并，并且现在正在清理中：

现在有一些DNS和LDAP信息出现在Test124和域控制器之间。我不确定为什么有这些信息，但由于太多了，我将略过这些帧中的一些：

到这里，脚本已经结束了，所以我停止了这个跟踪。

分析ChangeIPAddress.vbs的捕捉

我们现在知道了一些关于一个成功的远程脚本的捕捉大概会是什么样子的了：

• 一些DNS和ARP信息
  
• 使用三向握手建立TCP会话
  
• RPC绑定和DCOM
  
• 更多的TCP握手
  
• Kerberos信息（主机是在同一个域中）
  
• 更多的RPC/DCOM信息
  
• 更多的TCP握手，Kerberos，RPC/DCOM及TCP通信
  
• 更多的DCOM及随后的TCP会话拆除

所有这些仅仅在两秒钟内发生。

现在让我们看看我们对ChangeIPAddress.vbs（远程运行时产生一个RPC错误的脚本）的捕捉，看它与之前的有什么不同。

这仅仅是一些Netmon信息。

这是一个ARP，一个DNS，然后是一个TCP握手——与前面的一样。

RPC，DCOM，另一个TCP握手，然后是一些Kerberos信息。它看起来与之前的一样。

我们看到相同的模式。

然后一整串的RPC/DCOM信息，与其他跟踪一样的。

这里是RPC和TCP。你可以看到WMI接口的调用。

这又是什么？脚本已经成功将目标主机（Test125）的IP地址从172.16.11.125修改成172.16.11.144，那么为什么目标使用ARP去尝试把它自己的IP地址解析成MAC地址呢？这是一个无故的ARP（Gratuitous ARP），它发生在一个节点向它自己的IP地址发送一个ARP请求的情况下。为了确认它的新IP地址172.16.11.144没有被网络上的其他节点所使用。如果在它发送了几个ARP请求后没有收ARP响应，它就会认定它的新地址在网络中是唯一，然后这个地址将被保留。但如果另一个节点收到ARP请求发送了一个ARP响应，第1个节点就会认定网络上有IP地址冲突，然后它将失效它的IP地址（设为0.0.0.0）。

提示：如果你想要学习更多关于ARP的知识，请阅读Thomas Lee和Joseph Davies的《Microsoft® Windows® 2000 TCP/IP Protocols and Services Technical Reference》的第3章“寻址解析协议（Address Resolution Protocol， ARP）”。

这里事情似乎变乱了——你可以发现数据包的时间间隔明显增大。而且接下来似乎还发生了源节点（Test124）不停地尝试向目标发送告知TCP包，但总是到达不了。

让我们使用NM3仔细地看看第159个数据包。（如图8）

图8：TCP连接问题

从图中我们注意到源主机（Test124）仍然认为目标主机有IP地址172.16.11.125，所以它不停地尝试向Test125主机发送ACK以维持之前建立的连接。

现在让我们看看第161帧（如图9）：

图9：RPC/DCOM问题

我们注意到由源主机（Test124）之前建立的与目标主机Tet125的RPC绑定正在尝试使用DCOM去调用Win32_NetworkAdapterConfiguration类的EnableStatic方法。（查看右侧的Hex Details窗口，你可以看到显示为UNICODE文本的RPC包的十六进制负载。）但在尝试使用DCOM时，源主机认为目标主机的IP地址仍然是172.16.11.125（见图中的Frame Details窗口）。

所以看起来那位读者说的是对的！

尝试和分析其余的ChangeIPAddress.vbs捕捉是很有趣的，但看起来我们已经可以判断我们远程脚本不能正常运行的原因了。正如我们在前一篇文章提到的，如果我们使用On Error Resume Next工作区，那么它就能正常工作了。