解惑 net send 命令无法成功之谜.doc

局域网中有两台工作站，通过Windows系统内置的“netsend”命令相互发送消息时，竟然出现了两种不同错误的故障提示，那么为什么一样的“netsend”命令，会出现不一样的故障提示呢?我们究竟该如何进行应对，才能解惑netsend无法成功之谜呢?现在笔者就将具体的故障现象以及故障排除过程贡献出来，供各位读者参考!故障现象网管网bitsCN.com局域网中有甲、乙两台工作站，其中甲工作站安装的是WindowsXP操作系统，它使用的IP地址为192.168.1.10，乙工作站安装的是Windows2003操作系统，它使用的IP地址为192.168.1.20。当笔者尝试在甲工作站系统中执行字符串命令“netsend192.168.1.20test”，来向乙工作站发送一条“test”的测试信息时，甲工作站系统竟然弹出“发生一般网络错误”的故障提示，同时还出现了“请键入nethelpmsg2136以获得更多的帮助”这样的提示信息;当笔者尝试在乙工作站系统中执行字符串命令“netsend192.168.1.10test”，来向甲工作站系统发送一条“test”的测试信息时，乙工作站系统竟然弹出“网络上找不到此消息的别名”的故障提示，同时还出现了“请键入nethelpmsg2273以获得更多的帮助”这样的提示信息。为什么在局域网里的两台不同工作站中，执行相同的“netsend”命令时，系统会弹出不同的故障提示以及不同的信息帮助号呢，我们究竟该如何进行应对，才能解惑netsend无法成功之谜呢?中国网管联盟www、bitsCN、com故障排除根据甲工作站系统弹出的“请键入nethelpmsg2136以获得更多的帮助”提示信息，笔者立即在甲工作站系统中执行了“nethelpmsg2136”字符串命令，在随后出现的如图1所示结果界面中，笔者得知该故障原因很有可能是网络硬件出现了损坏，那会不是网络连接线路或网卡等硬件设备发生了问题呢?为了验证这样的分析，笔者又在该系统中执行了“ping192.168.1.20”字符串命令，来Ping一下工作站，结果发现该命令执行成功，这表明甲工作站系统与乙工作站系统之间的物理线路以及网卡设备都不存在问题。在排除了网络硬件发生损坏的可能性后，还有什么因素会导致系统弹出“发生一般网络错误”的故障提示呢?会不会是甲工作站系统使用的“netsend”命令自身遇到了故障呢?为了确认“netsend”命令在甲工作站系统中是否运行正常，笔者又在该系统中执行了“netsend192.168.1.10test”字符串命令，尝试一下自己给自己发送信息，最后得到的结果是“该消息已经成功发送到192.168.1.10”，这表明“netsend”字符串命令在甲工作站系统中运行是很正常的。通过上面的排查分析，笔者估计很有可能是乙工作站系统自身出现了问题。图1中国网管联盟根据乙工作站系统弹出的“请键入nethelpmsg2273以获得更多的帮助”提示信息，笔者又在乙工作站系统中执行了“nethelpmsg2273”字符串命令，在随后弹出的如图2所示结果界面中，笔者发现该故障很有可能是乙工作站无法正确解释“netsend”命令引起的。为了检验“netsend”命令在乙工作站系统中是否运行正常，笔者又在该系统中执行了“netsend192.168.1.20test”字符串命令，尝试一下给自身发送一条测试信息，最后得到的结果同样是“网络上找不到此消息的别名”，这难道真是该系统中的“netsend”命令受到了破坏?笔者不甘心，又继续执行了“netsend192.168.1.30test”字符串命令，尝试给其他一台工作站发送了一条测试信息，最后得到的结果是“该消息已经成功发送到192.168.1.30”，这表明“netsend”字符串命令在乙工作站系统中运行也是正常的。中国网管论坛bbs.bitsCN.com【转自www.bitsCN.com】图那么为什么在乙工作站系统中，可以使用“netsend”命令给别人发送信息，而无法成功给自己和甲工作站发送信息呢?苦苦思索了很长时间，笔者始终弄不出个所以然出来;不得已，笔者只好到网上搜索了一下“netsend”命令的具体使用资料，通过查找资料得知，一个用户要想收到别人发送过来的消息，必须先要正确登录进Windows工作站系统，同时还需要在该系统中正确运行“Messenger”系统服务。对照一下这两个条件，笔者估计乙工作站系统之所以无法自己给自己发送消息，很有可能是该系统的“Messenger”系统服务被意外停止运行了;根据自己的估计，笔者用鼠标右键单击乙工作站系统桌面中的“我的电脑”图标，从弹出的快捷菜单中执行“管理”命令，打开对应工作站系统的计算机管理窗口，在该窗口的左侧显示窗格中，依次展开“计算机管理”/“服务和应用程序”/“服务”分支项目，在对应“服务”项目的右侧子窗格中，用鼠标双击“Messenger”系统服务，打开如图3所示的服务属性设置界面，在该界面中笔者发现乙工作站系统的“Messenger”系统服务果然处于禁用状态，看来乙工作站系统无法给自身发送消息的“罪槐祸首”就是“Messenger”服务了。找到故障原因后，笔者迅速单击图3界面中的“启动”按钮，将该服务重新启动了起来，同时又将该服务的启动类型设置为“自动”，确保该服务在系统重新启动之后也不会被停止运行;启动好“Messenger”系统服务后，笔者又尝试着在乙工作站系统中执行了一次“netsend192.168.1.20test”字符串命令，结果发现上次的“网络上找不到此消息的别名”故障提示没有再次弹出，至此乙工作站出现的“网络上找不到此消息的别名”故障就已经被顺利地解决了!网管联盟www.bitsCN.com【转自www.bitsCN.com】图3中国网管论坛bbs.bitsCN.com原以为现在从乙工作站中向甲工作站发送消息时，不会出现“网络上找不到此消息的别名”故障了，可是当笔者经过实践测试之后，发现在乙工作站启用“Messenger”系统服务的情况下，这种故障现象居然还存在。通过上面的排查与分析，笔者基本已经确认“netsend”命令在甲、乙两台工作站系统中都运行正常，而且每台工作站接受消息的功能也都正常;只是让笔者感到疑惑不解的是，为什么这两台工作站之间一直无法成功发送信息呢?难道真是甲、乙两台工作站之间的物理线路出现了问题?笔者不放心，又在乙工作站系统的MS-DOS窗口中执行了一次“ping192.168.1.10”字符串命令，想验证一下能否从乙工作站Ping通甲工作站，可这次执行的结果让笔者感到非常意外，竟然出现“Requesttimedout”这样的提示，难怪乙工作站无法成功向甲工作站发送消息。考虑到甲工作站可以Ping通乙工作站，而乙工作站又能发送消息给其他工作站，笔者估计甲、乙两台工作站之间的物理线路肯定是没有问题，而且乙工作站的系统设置也不应该有问题，而问题很可能是甲工作站的系统设置出现了错误，这种错误或许就是两台工作站使用“netsend”命令相互发送信息时出现不同故障提示的根本原因。