Socket error 11004(“网络节点错误，tcp”)

本人维护的一个软件A【MFC实现的界面，C#实现的后台代码，为我所属部门研发的主要软件X服务】，在大多数同事的电脑上都可以进行正常调试【socket通信】，唯独在Y同事的电脑上出现了调试不了的情况。这种情况总是不禁让人怀疑要么Y同事的电脑系统出了问题，要么是公司加密软件的影响下导致调试失败，失败的信息提示为“网路节点错误，tcp”，一直在网上疯狂的搜索这几个关键字，相似度最吻合的一些文章也不过是介绍网络相关的知识。尽管我也在软件源代码上搜索相关字，但是还是没有发现，即当时以为这个是操作系统给的提示信息。而且该软件项目是之前外包给别人写的，尽管是我与我导师维护，但究其原因毕竟是个为了主软件而设计的一个工具，代码层面上是能尽量少改就少改【即前台代码少改】。

1、向信息技术部求助【怀疑是软件加密有关】，信息技术部的同事帮忙调了一个上午，防火墙开关，加密软件允许通过等皆试过，结果就是不知道哪里出了问题，信息技术部同事也劝我别太浪费这时间，实在不行给Y同事重装系统，这Y肯定是不乐意的。

2、向信息技术部申请借了一台电脑，把Y同事的系统给拷贝了一份，拿到我办公桌上我自己调试【之前也在叶某的电脑上进行了代码调试，毕竟调试几个小时也没看出来哪里出了问题，也不能浪费人家时间，遂拷贝其系统】，从源代码调试的情况下看，显然是在调用某个函数指针返回的对象的成员出现了“网络节点错误：tcp”字样，但是这个函数指针指向的函数调试时并没有进入，因此怀疑是被外部调用了，果然一查，是项目里引用了一个link.dll库，反编译还看不了，有历史记录记载是被前员工编译签入的，目前的项目是没有这个link项目的源码，向旁边的同事X求助，同事X以前也维护过这个软件的代码，遂在老版本的服务器上捞到一份2年前的Link项目。编译这个项目不容易，因为公司最近刚好换加密软件，各种解密后打开该Link项目，编译后生成的Link.dll替换当前最新维护的软件A下的Link.dll是铁定不行的，于是在服务器上拿了A最陈旧的包，放进去之引用后成功了，后面发现错误信息“网络节点错误：tcp”就是link项目自定义的错误信息，而不是系统给的。

可见维护软件无源代码的蛋疼之所在。

在Link项目全局搜索tcp关键字，发现是一个异常抛出的，大概就是调用getprotobyname("tcp")函数时，若返回的对象是空的就抛异常。百度了一波getprotobyname【获取协议相关信息的WinSocket函数】，决定调用WSAGetLastError()函数【获取上一次WinSocket的错误信息】查看信息，自然就出现了11004，有了这个结果还不知道在哪错的呢，四处搜信息11004，也看google上面的人是怎么解决的，都说是重置网络的配置，我跟着他们做也不行，再后来就觉得是不是应该跟IP，DNS有关，就去查看了Windows\System32\drivers\\etc文件夹下的hosts文件，自己好奇心比较大，就对比了一下自己原来的电脑和借来的电脑hosts文件有什么不同，结果一看，我靠，借来的电脑系统上etc目录下只有hosts文件，我电脑上除了hosts文件还有networks、protocol、services等，后面发现getprotobyname这个函数在执行的时候就先去etc文件夹下protocol找是否有tcp协议，没有就返回一个空的结构。最后自然是把我电脑的那几个文件拷贝到出现问题的系统的etc目录下，问题就解决了。

总结：深刻意识到无源代码的蛋疼之处，尽管代码已经维持的非常固定，也不要轻易的丢弃源代码，否则一旦出现错误，带来的有可能是非常严重的后果。【我接到这个任务时，我导师还有一些意思要劝我Y同事是其电脑问题不用管太多，以及之前调试时我把问题方向放在link.dll上，导师还怀疑我的方向。后面当我把电脑还给信息技术部的同事时，导师就迫不及待的来问我原因，这可能跟我的较真性格有关系吧，反正最后问题解决了，自己也查看了一些关于etc下面的文件相关知识，真香！！！！】