How to debug slow interop constructor of Office applications?

Question

I have an application that deals with excel. I recently ran into a problem with very slow creation of an Excel object.

I recreated the problem with this simple code:

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

The second line causes a delay.

In order to measure the time required to host the new facility, the above code has been expanded with a time tracking solution, and the results are final. In the NORMAL situation above, the code is executed in 0.5 s, and in the case of FAULTY-BEHAVIOR this can take up to 5 minutes.

There are no memory leaks, and excel objects are properly freed. My solution works around the clock and without problems. I'm not sure if this is important, but the application runs on 20 separate user sessions (server machine). Thus, 20 instances of this application work simultaneously, and this can lead to simultaneous 20 instances of Excel.

The problem was first noticed 2 months ago and was resolved by updating Office (2010 → 2013). This time I have more time for research, and, unfortunately, the results do not promise.

Facts:

• Only one machine is affected in this situation (24 processor cores, 24 GB RAM)
• The CPU is not stressed at all when there is a “delay”
• I tried using the "Process Monitor" application to check what happens when we create the "new Excel.Application ()" (to see if there is excessive disk / memory / processor usage) - there are no signs of resource limitations. There are no signs of log files associated with COM objects, etc.
• The only problem here is a few minutes of delay. All other Excel Interop commands work as usual.

The main question:

• Is there a way to debug this Microsoft.Office.Interop.Excel.Application () constructor to find out what part of the problem is here?

External content

• One guy with a similar problem. His solution did not help me in my problem.

EDIT - optional test

PowerPoint Designer is Delay-Free

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

Answer 1

I found a solution myself. I will post it, as someone else might run into a similar problem, and this could save him hours / days of investigation.

What did I find to find a solution?

I analyzed a test application (basically just one line where a new excel application is created) using Process Monitor , and it showed nothing important. Then I repeated the analysis with the recently launched Excel process. He highlighted numerous Windows registry reads.

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

In the above location, I found tens of thousands of keys. All of them were created using the "automatic recovery" function of Excel. Because of the numbers, loading them when you start a new Excel object takes about 40 seconds. This number was additionally multiplied by another 10-20 simultaneously loaded sessions (did I mention that my application runs on 20 user sessions?).

Solution: Removing the "Resilency" registry tree does the trick.

Why were all these “auto-recovery” entries there in the first place? I think I'm not very good at closing Excel, and he "thinks" that I am having regular crashes and "attempts" to help.

---

Now what remains is bothering him again and again. I will take a closer look at the ExcelClose () function.

Thank you for your attention - Adrian

Answer 2

I do not think the problem is with this constructor. Try creating the object dynamically:

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

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

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

I expect the slowdown to move to an Activator.CreateInstance call.

In any case, you can try to do this by placing the following in the app.config file (in more detail ):

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

I also suggest making sure you use the latest VSTO Runtime and the latest Office PIA .