我用两台机器，一台win10作为发单的客户端。一台win7作为服务端。两个机器都是用同一个wifi。

最近发现，服务端的程序会不定时会崩溃，开启事件大约2-3个小时后发生崩溃。
之前第一次发生的时候以为是个偶然问题，所以没有每天测试，不确定是否每次都会崩溃，不过今晚又发生了一次，从10月23日截止现在共发生了两次。
崩溃的时候，客户端都只有在接受publish，没有向服务端发送请求。

win7的事件查看器，截图如下：
10.23的日志：

10.29的日志

日志内容看上去是差不多，就是id，内存地址等等的这些略有不同。

因为需要rpc服务端能稳定运行，麻烦帮忙分析一下，谢谢。

后续跟踪

2019.10.30，用ctp测试api的环境测试了一夜，没有出现崩溃窗口。回想了一下之前的操作，有两个与正常使用不太一样的情景，不懂是否有影响：
1、了模拟网络不稳定的情况，有对客户端进行多次的wifi连接手动断开再重连的操作。
2、服务端同时开启了两个vn_trader。一个用于普通的跑cta策略（用run.py文件运行的），一个开启rpc服务（用vn_station运行的）。

后续跟踪2

自从上次反馈RPC服务会不定时崩溃之后，把服务端和客户端都同时运行在一台电脑上，zmq模块就没有出现过类似问题了。

但是最近从2020年3月开始，又不定期随机出现服务端程序直接崩溃终止运行的情况（没有弹出任何错误，整个进程直接消失了），并且难以重现这个错误。最近一次在崩溃的时候，客户端没有向服务端调用过任何主动函数，所以推测会不会在pub的问题上？
另外，已经在两台电脑上都出现过此问题。

有什么思路可以排查这个问题吗？

这个报错来源于底层的zmq库（C++代码中的内容），不属于vn.py的代码范围，请试试在google搜索吧。

客户端多次断开重连的操作，理论上不应该会影响到服务端，但因为你是用wifi就不确定了，对于交易程序请使用传统的网线方案。

用Python的交易员 wrote:

这个报错来源于底层的zmq库（C++代码中的内容），不属于vn.py的代码范围，请试试在google搜索吧。

客户端多次断开重连的操作，理论上不应该会影响到服务端，但因为你是用wifi就不确定了，对于交易程序请使用传统的网线方案。

这几天进行了持续跟踪：
1、同样的wifi环境，没有故意多次人为断开wifi连接再重连，没有出现崩溃的情况。
2、在公司的环境下，客服端和服务端均在同一台电脑下运行，也没有出现崩溃的情况。

所以，可能还是和wifi多次断开重连有一定关系吧。
确实如您所说，我们一般也是使用网线的方案的，只是刚好在测试阶段，是用家里的电脑测试的，才产生了这个问题。