如何调试缓慢的Office应用程序互操作的构造？ [英] How to debug slow Office application interop constructor?

问题描述

我有一个与Excel涉及的应用程序。最近我遇到一个问题很慢创建Excel对象的

我已经重新发行这个简单的代码：

  Microsoft.Office.Interop.Excel.Application xlApp; 
 xlApp =新Microsoft.Office.Interop.Excel.Application（）; 
  

第二行导致的延迟。

为了测量所需的新对象分配的时间，上述代码已被扩展以时间跟踪溶液和结果是结论性的。在正常情况下，上面的代码在0.5秒，而执行在FAULTY行为的情况下，它可能需要长达5分钟。

有没有内存泄漏和Excel对象正在正确释放。我的解决方案已经运行7天24小时全年没有任何问题。我不知道这是否是重要的，但在应用程序上的20个独立用户会话（服务器计算机）上运行。所以有在同一时间运行此应用程序的20个拷贝，并将其可能导致在同时运行的Excel 20份。

第一次问题已经2个月前发现和（2010 - > 2013）办公的升级已经解决了。这一次，我有更多的时间进行调查，遗憾的是结果并不乐观。

事实：

• 只有一台机器，目前受此问题的影响（24个CPU核心，拉姆24GB）


• CPU是不是在所有的时候强调延时发生


• 我已经尝试过使用过程监控应用程序来验证时会发生什么，我们新Excel.Application（）的构造函数（看是否有过多的磁盘/内存/ CPU使用率） - 无资源的限制迹象。有关COM对象的日志文件没有迹象等。


• 这里唯一的问题是延迟这一几分钟。所有其他Excel互操作命令照常上班

主要问题：

• 有没有办法调试此Microsoft.Office.Interop.Excel.Application（）构造函数，看看哪些部分是一个问题吗？

外部内容

• 的有类似问题的一个家伙。他的解决方案并没有与我的问题在所有帮助

修改 - 额外的测试

PowerPoint中的构造不受延迟

  ppApp =新Microsoft.Office.Interop.PowerPoint.Application（）; 
  

我自己的解决方案

我已经找到解决方案。我会后为别人可能会遇到类似的问题，它可以救他的调查小时/天。

我所做找到解决办法？

我已经分析测试应用程序（基本上只有一条线在那里正在创建新的Excel应用程序）是进程监视器，并没有显示任何东西重要。然后，我重复新开工Excel进程分析。它强调了无数读取注册表

  HKEY_USERS\S-1-5-21-2929665075-1795331740-364918325-1024\\ \\Software\Microsoft\Office\15.0\Excel\Resiliency\DocumentRecovery 
  

在上述地点我发现钥匙数以万计。他们都被Excel的自动恢复功能创建的。由于数字，开始新的Excel对象以约40秒的时候加载它们。这个数字被加乘以另一个10-20同时加载会话（我提到我的应用程序在20个用户会话中运行？）

解决方法：Resilency注册表树的
拆卸的伎俩。

为什么所有这些自动恢复条目在第一个地方在那里？我想我不处理的Excel收盘非常好，它认为我有定期的崩溃和尝试，以帮助。

---

现在剩下的就是防止它在再次发生的所有。我要在我ExcelClose（）函数一探究竟。

感谢您的关注 - 阿德里安

I have an application which deals with excel. Recently I encountered a problem with very slow creation of Excel object.

I've recreated the issue with this simple code:

Microsoft.Office.Interop.Excel.Application xlApp;
xlApp = new Microsoft.Office.Interop.Excel.Application(); 

The second line causes the delay.

In order to measure the time needed for new object allocation, above code has been extended with time tracking solution and the results are conclusive. In NORMAL situation, above code executes in 0.5s while in case of FAULTY-BEHAVIOR it can take up to 5 minutes.

There are no memory leaks and excel objects are being properly freed. My solution has been running 24/7 whole year without any issues. I'm not sure if it's important but the application is running on 20 separate user's sessions (server machine). So there are 20 copies of this application running at the same time and it may result in 20 copies of Excel running at the same time.

First time the issue has been noticed 2 months ago and has been solved by upgrade of Office (2010 -> 2013). This time I have more time to investigate and sadly results aren't promising.

Facts:

• only one machine is currently affected by this issue (24 cpu cores, 24GB of Ram)
• CPU isn't stressed at all when the "delay" happens
• I've tried using "process monitor" application to verify what happens when we "new Excel.Application()" constructor (to see if there is any excessive disk/memory/cpu usage) - no signs of resources limitations. No sign of log files related to COM objects, etc.
• The only issue here is this few minutes of delay. All other Excel Interop commands work as usual.

Main Question:

• Is there a way to debug this Microsoft.Office.Interop.Excel.Application() constructor to see which part is an issue here?

External content

• One guy with similar issue. His solution didn't help with my problem at all.

EDIT - additional test

PowerPoint constructor is not affected by the delay

ppApp = new Microsoft.Office.Interop.PowerPoint.Application();

解决方案

I've found solution on my own. I'll post it as someone else may encounter similar problem and it can save him hours/days of investigation.

What i did to find solution?

I've analyzed test application (basically only one line where new excel application is being created) with Process Monitor and it didn't show anything important. Then I repeated analysis with newly started Excel process. It highlighted numerous reads of windows registry

HKEY_USERS\S-1-5-21-2929665075-1795331740-364918325-1024\Software\Microsoft\Office\15.0\Excel\Resiliency\DocumentRecovery

Under above location I've discovered tens of thousands of keys. They all were created by Excel's "auto-recovery" functionality. Because of the numbers, loading them when starting new Excel object was taking about 40 seconds. This number was additionally being multiplied by another 10-20 simultaneously loaded sessions (did I mention my application is running on 20 user sessions?).

Solution: Removal of "Resilency" registry tree does the trick.

Why all these "auto-recovery" entries were there in a first place? I guess I don't handle closing of Excel very well and it "thinks" I'm having regular crashes and "tries" to help.

---

Now what's left is preventing it from happening all over again. I'll have a closer look at my ExcelClose() function.

Thanks for your attention - Adrian

这篇关于如何调试缓慢的Office应用程序互操作的构造？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！