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 s

Answer 1

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.

Answer 2

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