我们有一个Service Broker应用程序，我们在两台独立的非域计算机上的两个SQL Server实例之间进行通信。我们的测试配置之一是在我们以前从未见过的模式中失败。类似配置的系统似乎工作正常，SSBDiagnose没有表明任何问题。
以下是我们看到的错误：
一方记录此错误：
接收数据时发生错误：＆＃39; 10054（远程主机强行关闭现有连接。）＆＃39;。
系统的另一端在SQL Server日志中记录这些错误：
2012-04-24 10:45:52.58 spid17s Error: 9650, Severity: 16, State: 5. 2012-04-24 10:45:52.58 spid17s A system cryptographic call failed during a Service Broker or Database Mirroring operation: system error '5(Access is denied.)'. 2012-04-24 10:45:52.59 spid17s Error: 9641, Severity: 16, State: 12. 2012-04-24 10:45:52.59 spid17s A cryptographic operation failed. This error indicates a serious problem with SQL Server. Check the SQL Server error log and the Windows event logs for further information. 2012-04-24 10:45:52.59 Logon Service Broker login attempt failed with error: Connection handshake failed. An OS call failed: (0) (null). State 87.'. [CLIENT: 192.168.220.3]
我们猜测问题出在我们的证书配置上，但重新安装证书就好像我们从头开始重建系统一样没有帮助。
之前有没有人看到过这些错误，或者知道他们指出了哪些失败？
答案 0 :(得分：3)
我以前见过这个，而且一直是一些限制访问RSA密钥库的流氓应用程序的问题。我从来没能找到更改权限的罪魁祸首......是不是特定于Service Broker，其他应用程序遇到同样的问题，例如。 RSA Key Store Permissions
解决方案是为目录\ProgramData\Microsoft\Crypto\RSA\MachineKeys上的SQL Server服务帐户和所有包含的文件授予读写权限。
如果问题仍然存在，请与产品支持小组联系。
更新。是的，我记得：有一篇关于这个问题的知识库文章Error message when you use Service Broker or database mirroring to connect to an instance of SQL Server 2005: "Connection handshake failed"。我应该记得，我为该KB编写了存根：）
答案 1 :(得分：2)
这对某人有帮助。我们遇到了这样的问题（sys.transmission_queue中的传输状态为Connection handshake failed. An OS call failed: (0) (null). State 87.。原因是磁盘空间不足。