How to debug slow Office application interop constructor?

Question

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();

Answer 1

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

Answer 2

I don't think the problem is with this constructor. Try to create the object dynamically:

var obj = Activator.CreateInstance(Type.GetTypeFromProgID("Excel.Application"));

Then cast it to Microsoft.Office.Interop.Excel.Application:

var xlApp = (Microsoft.Office.Interop.Excel.Application)obj;
MessageBox.Show(xlApp.Name);

I'd expect the slow-down to move to the Activator.CreateInstance call.

Anyway, you can try to work it around by placing the following into you app.config file (more details):

<runtime>
    <generatePublisherEvidence enabled="false"/>
</runtime>

I'd also suggest to make sure you're running the latest VSTO Runtime and the latest Office PIAs.