故障现象

　　局域网中有甲、乙两台工作站，其中甲工作站安装的是Windows XP操作系统，它使用的IP地址为192.168.1.10，乙工作站安装的是Windows 2003操作系统，它使用的IP地址为192.168.1.20。当笔者尝试在甲工作站系统中执行字符串命令“net send 192.168.1.20 test”，来向乙工作站发送一条“test”的测试信息时，甲工作站系统竟然弹出“发生一般网络错误”的故障提示，同时还出现了“请键入net helpmsg 2136以获得更多的帮助”这样的提示信息;当笔者尝试在乙工作站系统中执行字符串命令“net send 192.168.1.10 test”，来向甲工作站系统发送一条“test”的测试信息时，乙工作站系统竟然弹出“网络上找不到此消息的别名”的故障提示，同时还出现了“请键入net helpmsg 2273以获得更多的帮助”这样的提示信息。为什么在局域网里的两台不同工作站中，执行相同的“net send”命令时，系统会弹出不同的故障提示以及不同的信息帮助号呢，我们究竟该如何进行应对，才能解惑net send无法成功之谜呢?

　　故障排除

　　根据甲工作站系统弹出的“请键入net helpmsg 2136以获得更多的帮助”提示信息，笔者立即在甲工作站系统中执行了“net helpmsg 2136”字符串命令，在随后出现的如图1所示结果界面中，笔者得知该故障原因很有可能是网络硬件出现了损坏，那会不是网络连接线路或网卡等硬件设备发生了问题呢?为了验证这样的分析，笔者又在该系统中执行了“ping 192.168.1.20”字符串命令，来Ping一下工作站，结果发现该命令执行成功，这表明甲工作站系统与乙工作站系统之间的物理线路以及网卡设备都不存在问题。在排除了网络硬件发生损坏的可能性后，还有什么因素会导致系统弹出“发生一般网络错误”的故障提示呢?会不会是甲工作站系统使用的“net send”命令自身遇到了故障呢?为了确认“net send”命令在甲工作站系统中是否运行正常，笔者又在该系统中执行了“net send 192.168.1.10 test”字符串命令，尝试一下自己给自己发送信息，最后得到的结果是“该消息已经成功发送到192.168.1.10”，这表明“net send”字符串命令在甲工作站系统中运行是很正常的。通过上面的排查分析，笔者估计很有可能是乙工作站系统自身出现了问题。

图1

　　根据乙工作站系统弹出的“请键入net helpmsg 2273以获得更多的帮助”提示信息，笔者又在乙工作站系统中执行了“net helpmsg 2273”字符串命令，在随后弹出的如图2所示结果界面中，笔者发现该故障很有可能是乙工作站无法正确解释“net send”命令引起的。为了检验“net send”命令在乙工作站系统中是否运行正常，笔者又在该系统中执行了“net send 192.168.1.20 test”字符串命令，尝试一下给自身发送一条测试信息，最后得到的结果同样是“网络上找不到此消息的别名”，这难道真是该系统中的“net send”命令受到了破坏?笔者不甘心，又继续执行了“net send 192.168.1.30 test”字符串命令，尝试给其他一台工作站发送了一条测试信息，最后得到的结果是“该消息已经成功发送到192.168.1.30”，这表明“net send”字符串命令在乙工作站系统中运行也是正常的。

图2

　那么为什么在乙工作站系统中，可以使用“net send”命令给别人发送信息，而无法成功给自己和甲工作站发送信息呢?苦苦思索了很长时间，笔者始终弄不出个所以然出来;不得已，笔者只好到网上搜索了一下“net send”命令的具体使用资料，通过查找资料得知，一个用户要想收到别人发送过来的消息，必须先要正确登录进Windows工作站系统，同时还需要在该系统中正确运行“Messenger”系统服务。对照一下这两个条件，笔者估计乙工作站系统之所以无法自己给自己发送消息，很有可能是该系统的“Messenger”系统服务被意外停止运行了;根据自己的估计，笔者用鼠标右键单击乙工作站系统桌面中的“我的电脑”图标，从弹出的快捷菜单中执行“管理”命令，打开对应工作站系统的计算机管理窗口，在该窗口的左侧显示窗格中，依次展开“计算机管理”/“服务和应用程序”/“服务”分支项目，在对应“服务”项目的右侧子窗格中，用鼠标双击“Messenger”系统服务，打开如图3所示的服务属性设置界面，在该界面中笔者发现乙工作站系统的“Messenger”系统服务果然处于禁用状态，看来乙工作站系统无法给自身发送消息的“罪槐祸首”就是“Messenger”服务了。找到故障原因后，笔者迅速单击图3界面中的“启动”按钮，将该服务重新启动了起来，同时又将该服务的启动类型设置为“自动”，确保该服务在系统重新启动之后也不会被停止运行;启动好“Messenger”系统服务后，笔者又尝试着在乙工作站系统中执行了一次“net send 192.168.1.20 test”字符串命令，结果发现上次的“网络上找不到此消息的别名”故障提示没有再次弹出，至此乙工作站出现的“网络上找不到此消息的别名”故障就已经被顺利地解决了!

图3

　　原以为现在从乙工作站中向甲工作站发送消息时，不会出现“网络上找不到此消息的别名”故障了，可是当笔者经过实践测试之后，发现在乙工作站启用“Messenger”系统服务的情况下，这种故障现象居然还存在。通过上面的排查与分析，笔者基本已经确认“net send”命令在甲、乙两台工作站系统中都运行正常，而且每台工作站接受消息的功能也都正常;只是让笔者感到疑惑不解的是，为什么这两台工作站之间一直无法成功发送信息呢?难道真是甲、乙两台工作站之间的物理线路出现了问题?笔者不放心，又在乙工作站系统的MS-DOS窗口中执行了一次“ping 192.168.1.10”字符串命令，想验证一下能否从乙工作站Ping通甲工作站，可这次执行的结果让笔者感到非常意外，竟然出现“Request timed out”这样的提示，难怪乙工作站无法成功向甲工作站发送消息。考虑到甲工作站可以Ping通乙工作站，而乙工作站又能发送消息给其他工作站，笔者估计甲、乙两台工作站之间的物理线路肯定是没有问题，而且乙工作站的系统设置也不应该有问题，而问题很可能是甲工作站的系统设置出现了错误，这种错误或许就是两台工作站使用“net send”命令相互发送信息时出现不同故障提示的根本原因。

　　依照上面的分析思路，笔者又回到了甲工作站系统，并对该系统的网络参数进行了仔细排查。笔者先打开了甲工作站系统的“本地连接”属性设置窗口，并选中该窗口中的“Internet协议(TCP/IP)”选项，再单击“属性”按钮，进入到TCP/IP参数设置窗口，在该窗口中笔者重点检查了IP地址和网关参数，结果发现一切正常;在关闭TCP/IP参数设置窗口，重新返回到“本地连接”属性设置窗口时，笔者突然将目光盯向了该窗口的“高级”标签，同时想到前几天刚刚安装了Windows XP系统的SP2补丁包，据说该补丁包对防火墙功能进行了强化与完善，难道甲、乙两台工作站无法相互发送消息的故障是由该系统的防火墙引起的?

　　想到这里，笔者迅速单击了“本地连接”属性设置窗口中的“高级”标签，然后单击对应标签页面的“设置”按钮，打开了防火墙的参数设置界面;当查看到该界面中的“例外”标签页面时，笔者看到其中的“文件和打印机共享”项目没有选中(如图4所示)，会不会该项目就是最终的“罪槐祸首”呢?笔者抱着试试看的态度，将这里的“文件和打印机共享”项目选中，并单击了“确定”按钮;之后又在乙工作站系统的MS-DOS窗口中执行了一次“ping 192.168.1.10”字符串命令，这次发现甲工作站可以Ping通了，再次执行“net send 192.168.1.10 test”字符串命令时，笔者发现现在乙工作站也能通过“net send”命令成功向甲工作站系统发送消息了，而且从甲工作站系统中执行“net send 192.168.1.20 test”字符串命令时，执行结果也是成功的，这说明甲、乙两台工作站无法相互发送消息的故障就是甲工作站的防火墙参数设置不当造成的。至此，两台工作站无法通过“net send”命令无法相互发送消息的谜底就算解开了!

图4

　　故障总结

　　到了这里，本文其实可以告一段落了。可是让笔者感到不明白的是，为什么一选中防火墙“例外”标签页面中的“文件和打印机共享”项目时，所有故障现象全部消失了。后来经过网上查阅资料，笔者终于弄清楚了原由，原来“文件和打印机共享”服务与系统的四个服务端口相互关联，它们分别是“UDP 137”端口、“UDP 138”端口、“TCP 139”端口、“TCP 445”端口，一旦没有选中防火墙中的“文件和打印机共享”服务时，那么甲工作站系统中的“TCP 139”端口、“TCP 445”端口就会处于关闭状态，而“Ping”命令会使用“TCP 445”端口进行通信，“net send”命令会使用“TCP 139”端口通信，这么一来我们在乙工作站系统中执行“ping 192.168.1.10”字符串命令时，自然就会出现“Request timed out”这样的提示，而且尝试向甲工作站发送消息时也就会出现“网络上找不到此消息的别名”故障提示了。而在乙工作站系统中的“Messenger”系统服务被停用的情况下，我们从甲工作站向乙工作站发送消息时，也就出现了“发生一般网络错误”的不同故障提示。

　　总结上面的故障排除过程，笔者认为在排除网络故障的过程中，我们除了要将目光重点盯向与故障发生直接联系的网络参数、网络硬件外，还需要考虑系统自带防火墙的干扰因素;而且在排除具体故障时，我们必须逐一分析、仔细思考、依次排除，才能快速有效地解决故障现象。