我用这个简单的代码重新创建了这个问题：
Microsoft.Office.Interop.Excel.Application xlApp; xlApp = new Microsoft.Office.Interop.Excel.Application();
第二行导致延迟.
为了测量新对象分配所需的时间,上述代码已经通过时间跟踪解决方案进行了扩展,其结果是决定性的.在正常情况下,上述代码在0.5秒内执行,而在FAULTY-BEHAVIOR的情况下,最多可能需要5分钟.
没有内存泄漏,excel对象被正确释放.我的解决方案一年一整年都没有任何问题.我不确定是否重要,但应用程序在20个单独的用户会话(服务器机器)上运行.所以这个应用程序有20个副本同时运行,可能会导致同时运行的Excel的20个副本.
首次在2个月前注意到这个问题,并已通过Office(2010 – > 2013)的升级解决.这一次我有更多的时间来调查,悲伤的结果并不乐观.
事实：
目前只有一台机器受到这个问题的影响(24个cpu内核,24GB的Ram)
>当“延迟”发生时,cpu根本就没有压力
>我尝试使用“进程监视器”应用程序来验证当我们“新的Excel.Application()”构造函数(以查看是否有过多的磁盘/内存/ cpu使用)时会发生什么 – 没有资源限制的迹象.没有与COM对象相关的日志文件等等.
>这里唯一的问题是这几分钟的延误.所有其他Excel Interop命令正常工作.
主要问题：
>有没有办法调试这个Microsoft.Office.Interop.Excel.Application()构造函数来查看哪个部分是一个问题？
外部内容
> One guy with similar issue. His solution didn’t help with my problem at all.
编辑 – 附加测试
PowerPoint构造函数不受延迟的影响
ppApp = new Microsoft.Office.Interop.PowerPoint.Application();
解决方法
我做了什么找到解决方案？
我已经使用Process Monitor分析了测试应用程序(基本上只有一行新的excel应用程序被创建),并没有显示任何重要的东西.然后我重新分析了新开始的Excel过程.它突出显示了Windows注册表的大量读数
HKEY_USERS\S-1-5-21-2929665075-1795331740-364918325-1024\Software\Microsoft\Office\15.0\Excel\Resiliency\DocumentRecovery
在以上位置,我发现了数以万计的钥匙.它们都是由Excel的“自动恢复”功能创建的.由于数字,启动新的Excel对象时加载它们需要大约40秒.这个数字另外被另外10-20个同时加载的会话乘以(我提到我的应用程序是在20个用户会话上运行的吗？).
为什么所有这些“自动恢复”条目首先在那里？我想我没有很好地处理Excel的关闭,并且“认为”我正在定期崩溃和“尝试”来帮助.
现在剩下的是阻止它再次发生.我将仔细看看我的ExcelClose()函数.
感谢您的关注 – 阿德里安
