程序RPC 1726错误问题的追踪

        最近在客户环境中碰到了一个头疼的问题，一个节点通过RPC连接到另一个节点成功，但是在发送RPC报文的时候，却返回了1726错误。

错误信息

      先来看看MSDN的解释，"这个远程调用失败了"，这句话信息含量真是太少了啊，出现错误我肯定知道是远程调用失败了啊。

RPC_S_CALL_FAILED
1726 (0x6BE)
The remote procedure call failed.

      然后Google一把，对于RPC 1726错误的追踪也很少有一种明确的说法，那怎么办？客户又在催着，快帮我解决！！！我搜索了公司内部关于这个问题的case，大多数由于防火墙造成的，而且很多都是非Windows自带防火墙，如IPS，IBM的一些套件等等......可是发现，在客户的机器上Windows防火墙已经关闭，也没有可疑的第三方防火墙软件。那么两个节点通讯的中间节点是否有防火墙呢？客户说中间节点的防火墙不会对RPC的任何通讯进行阻挡。。。。。。呵呵，客户说的话，永远都要保持怀疑，事实最后也证明他们是错误的。

      这时候一方面对代码进行审查，另一方面不断的Google追踪这个问题的方法。客户也在焦急的催着，这时候发现微软一篇技术文章描述如下：

Explanation
A server connection was lost while the server was attempting to perform a remote procedure call. It is unknown whether the remote procedure call executed, or how much of it executed. The connection might have broken because of a problem with the network hardware or because a process terminated.

   
User Action
Wait a few minutes and then try the operation again. If this message reappears, check the server or try to connect to another server. You might also have to check the integrity of the network. If the problem persists, contact the supplier of the running application.

      首先微软说了，这个问题一般造成很可能两个原因：网络硬件问题（应该可以算作网络防火墙问题）或者是RPC Server的进程终止了。可以肯定的是我们的RPC Server进程并没有终止，那么就不得不怀疑网络原因造成的了！

问题追踪

      这样方向也够明确了，于是我们在客户环境中在RPC的Client端和Server端都采用非混合模式抓包。采用非混合模式抓包，就确保抓取的网络包都是经过指定的本机网卡。设置Wireshark的非混合模式如下图所示，并开始抓包:

      然后重现RPC 1726错误问题，停止Client端和Server端的抓包。开始进行分析，首先在Client端的Wirehshark过滤器中设置如下过滤器：

(ip.src_host==x.x.x.98 && ip.dst_host==x.x.x.207) || ((ip.src_host==x.x.x.207 && ip.dst_host==x.x.x.98)) && dcerpc

      其中“x.x.x.98”是Client的IP地址，“x.x.x.207”是Server端的地址，这个过滤表示只显示Client和Server交互的RPC包（在我们程序中默认采用基于TCP/IP的RPC通信），根据RPC的Request的内容，找到相应的Request包，在下图中可以看到选中的RPC Request包被Client发送出去后，并没有收到来自Server的Response包！

      那是不是RPC Server处理的问题呢？我们在Server端，用同样Wireshark Filter，过滤出Client和Server之间沟通的RPC包，果然并没有发现收到这个RPC Request请求。这个网络包被网络防火墙给吞掉了？？？ 虽然这个时候已经基本可以证明不是我们产品本身的问题了，可是有没有更强力的证据呢？

TCP连接Reset

      这时候就来看一看TCP的报文，首先在Client端采用如下过滤器：

(ip.src_host==x.x.x.98 && ip.dst_host==x.x.x.207) || ((ip.src_host==x.x.x.207 && ip.dst_host==x.x.x.98))

      在下图中看到，在发完No. 3372的Request之后，收到了一个TCP Reset的包！！！这个可是防火墙常干的事情。 也就是说Client和Server的连接被断开。

      然而这个连接Reset真是Server发给Client的吗？ 采用相同的Wireshark Filter在Server上进行分析后发现，Server并没有发送这个TCP Reset的包，而且于此同时也收到了IP Source为Client的 TCP Reset的包，可以从Client的Wireshark抓包中发现Client也并没有发送TCP Reset的报文给Server。 那么这个时候就基本可以肯定，Client和Server中间某个节点的防火墙，关闭的这个连接！！！

      大功似乎将要告成，既然根本原因不是我们产品造成的，那么总该让他们网络管理员去查找了吧。可是客户总是认为他们防火墙没问题，他只希望我们的产品能够正常的运行。。。。。。因为客户在美国，所以每次都是Webex，在这样的网络环境中更适合网络管理员去慢慢追中调查。

      我们希望他们管理员找，他们管理员不配合，那又得让我们的产品正常运行，那就只能找出其他的可行方案吧。最后给出的可行方案的是，改用基于Namepiped的RPC进行通讯，也是万不得已。

参考文章

RPC Error:

http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows+Operating+System&ProdVer=5.0&EvtID=1726&EvtSrc=RPC