我有一个处理 Excel 的应用程序。最近我遇到了创建 Excel 对象非常慢的问题。
我用这个简单的代码重新创建了这个问题：
Microsoft.Office.Interop.Excel.Application xlApp;
xlApp = new Microsoft.Office.Interop.Excel.Application();
第二行导致延迟。
为了测量新对象分配所需的时间，上面的代码已使用时间跟踪解决方案进行了扩展，并且结果是结论性的。在正常情况下，上述代码在 0.5 秒内执行，而在故障行为的情况下，可能需要长达 5 分钟的时间。
没有内存泄漏，Excel 对象被正确释放。我的解决方案全年 24/7 运行，没有出现任何问题。我不确定这是否重要，但应用程序正在 20 个单独的用户会话（服务器计算机）上运行。因此，该应用程序有 20 个副本同时运行，可能会导致 20 个 Excel 副本同时运行。
该问题首次在 2 个月前被发现，并已通过升级 Office（2010 -> 2013）解决。这次我有更多时间进行调查，但遗憾的是结果并不乐观。
Facts:
- 目前只有一台机器受此问题影响（24 个 cpu 核心，24GB RAM）
- 当“延迟”发生时，CPU完全没有压力
- 我尝试使用“进程监视器”应用程序来验证当我们“new Excel.Application()”构造函数时会发生什么（查看是否有任何过多的磁盘/内存/CPU 使用率）-没有资源限制的迹象。没有与 COM 对象等相关的日志文件的迹象。
- 这里唯一的问题是这几分钟的延迟。所有其他 Excel Interop 命令照常工作。
主要问题：
- 有没有办法调试此 Microsoft.Office.Interop.Excel.Application() 构造函数以查看哪一部分存在问题？
外部内容
- 一个有类似问题的人。他的解决方案对我的问题根本没有帮助。
编辑-附加测试
PowerPoint 构造函数不受延迟影响
ppApp = new Microsoft.Office.Interop.PowerPoint.Application();
我自己找到了解决方案。我会将其发布，因为其他人可能会遇到类似的问题，这可以节省他数小时/数天的调查时间。
我做了什么来找到解决方案？
我分析了测试应用程序（基本上只有一行正在创建新的 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() 函数。
感谢您的关注 - 阿德里安
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
