0

Suddenly calling:

((Microsoft.Office.Interop.Word._Application)word).Quit(SaveChanges: Microsoft.Office.Interop.Word.WdSaveOptions.wdDoNotSaveChanges, OriginalFormat: Type.Missing);

takes forever (30-60 seconds), instead of max 3 secs. It doesn't happen when I have used it to create pdf, but when I create docx. I haven't tried all the different options...

It could have something to do with a new version of Windows recently. I had that suspecion strentghed when I saw some guy had updated an old post less than 2 months ago regarding word interop: LINK See: "Edit on 2019-09-29" I have not tried any of that stuff they write about in there. Mostly because I don't understand it and it has not been neccessary before.

For me, the problem is on 2 windows 10 machines. My desktop has been updated to 1903 a week ago, so it could be that. It still works fine on my windows server running word 2016. My desktop runs word 365, but so does my friend's surface pro 3 and he doesn't have the problem. I don't know if he has updated his windows10 rececently.

Interestingly I had the same problem when I opened word just normally with an empty document and then closed it again. The windows closed, but the task manager word process took a long time to close, so that ofc made me suspecious. I then tried to play with the word settings and when I turned off "Show the Start sceen when this application starts", it started to close down the process immediatly. Ofc I then though: "GREAT, problem solved", but no. Still same problem when use interop. I tried to simulate the turn off of "show the start screen" by adding the following line: word.ShowStartupDialog = false; That just throw an expection, telling me that the ShowStartupDialog is not available when there is no window open. It could be because I run word in non-visible mode.

I ended up solving the problem by putting the quit code in a thread like this, at the end:

System.Threading.Thread t = new System.Threading.Thread(() =>
{               
    ((Microsoft.Office.Interop.Word._Application)word).Quit(SaveChanges: 
    Microsoft.Office.Interop.Word.WdSaveOptions.wdDoNotSaveChanges, OriginalFormat: Type.Missing);             
});

t.IsBackground = true;
t.Start();

Then I can continue working in the program and even call the same function again creating another document. It will then start another process while the old one is still closing down. I just tried having 3 closing at the same time, which is enough for my use. Also it takes up quite a lot of cpu 25+% per instance! My computer is not suuuuper new, but it is able to run CS GO just fine, so I really think that should be more than enough machine power :).

Please help be find the actual reason for this and a solution, so I can go back to my original code, which has worked for 4 years.

Cindy Meister
  • 25,071
  • 21
  • 34
  • 43
Flemming Bonde Kentved
  • 191
  • 1
  • 6
  • Where is `instead of max 3 secs` this documentation located at? – Trevor Nov 05 '19 at 19:56
  • The office COM interop is at least a decade too old to still be used today. Any chance you could limit this case to only accepting the new formats (.docx)? – Christopher Nov 05 '19 at 19:56
  • 3
    `The office COM interop is at least a decade too old to still be used today` based on what facts, why can't you *use* it? To be honest, I use it quite often and don't have any issues; based on lighter work loads. Yes, there are other libraries, but what if current development is preventing using other libraries at this time? – Trevor Nov 05 '19 at 19:58
  • I agree with Christopher. There are other options like OpenXML SDK etc. However do you have the excel data, would like to reproduce the issue? – Bendram Nov 05 '19 at 19:59
  • 1
    Quit() can only initiate shutdown, but Word cannot quit while there are still live interop interface references. Hurrying that along requires GC.Collect(). [Look here](https://stackoverflow.com/a/25135685/17034) for important details. Ideally you don't have to do this at all, use only one Word instance to do everything and have your program quit when the job is done. – Hans Passant Nov 05 '19 at 20:02
  • Mentioning that the COM interop is old and to not be used, offering up other libraries doesn't help the OP right now. Of course it's useful information to know, but how does this information actually help with what is going on? – Trevor Nov 05 '19 at 20:03
  • @Çöđěxěŕ Sometimes the most importanta information, is that there is a fundamental issue with your code that needs to be fixed anyway. And changing to Open XML will also fix the issue, of wierd COM Interop Behavior. – Christopher Nov 05 '19 at 20:13
  • @Christopher `And changing to Open XML will also fix the issue` so what's the OP's exact issue at this point; you must know something. – Trevor Nov 05 '19 at 20:14
  • Thanks for the quick responses! I know about open xml, but word interop is so nice and easy to use and everytime we have thought about changing the code, we have thought to ourselves: "If it works, why fix it?". Well maybe now is the time, buuuut I still doubt OpenXML has all the different nice options we get from COM interop. – Flemming Bonde Kentved Nov 05 '19 at 20:23
  • To begin with,I will try to see if this can be fixed. I have thought of using just one instance of Word, for the entire application and that could be a solution, but for now, I aim for a simpler option. I'm afraid a global use, could have some dangerous consequenses. It's a very large application with lots of different uses of Word, so it will require a lot of changes. – Flemming Bonde Kentved Nov 05 '19 at 20:27
  • I have tried the: "GC.Collect() GC.WaitForPendingFinalizers()" like @HansPassant suggested Not working unfortunately. Also, after doing some more tests of the "fix" I thought I had. It's not working very well either. It just postpones the wait and does the wait in the background as long as I don't do another Word task before it's done closing. Else it will, often, wait until the priveous instance is fully closed :/ – Flemming Bonde Kentved Nov 05 '19 at 20:58
  • @Çöđěxěŕ The max 3 seconds, is just the amount of time we are used to wait for Word to quit. It depends on the computer. On my desktop I would think it's maybe 1 second. Just like when you close a normal instance of Word. – Flemming Bonde Kentved Nov 05 '19 at 21:05
  • @Çöđěxěŕ: The issue is inherently to the way Office COM interop works. COM Interop has a ton of Idiosyncracies. **Office** COM Interop has issues on **top** of that. Not using Office COM interop will avoid the very thing causing this issue. I am unsure what kind of special knowledge you require to understand that, but for me it seems straighforward. – Christopher Nov 05 '19 at 22:15
  • `Not using Office COM interop will avoid the very thing causing this issue` it may, may not... what is the `very thing` causing this issue; you haven't answer my question still. You keep saying there are *issues*, of course there are, but what issue is happening here? – Trevor Nov 05 '19 at 22:18
  • 1
    https://dotnetfiddle.net/7iT6J7 shows that Quit will close down Word even with COM references still existing (copy and paste it locally into a .NET Framework console app to run it). This is consistent with my experience with Word (Excel acts differently). – mjwills Nov 05 '19 at 22:56
  • It turns out, the problem had nothing to do with interop so I don't have to change any code. If I opened any docx file (local or nonlocal) in word and then closed it again, it would take that long time to for the Microsoft Word (32 bit) proces to close. If I then, inside Word, opens the Account tab down in the left corner and Sign out of my account. The problem goes away... Omg I considered doing that all day, but nahhh, and ofc it's that. DOH. Sorry guys. – Flemming Bonde Kentved Nov 05 '19 at 23:07
  • After some tests, by opening several documents, suddenly it started taking longer again. Apparently it automatically signed me in again. After another sign out, it fixed the problem again, so I'm convinced. Ofc I didn't want to stay signed out forever on my personal computer, I then manually signed in again and yes, it takes longer, but not that much longer this time. Maybe 3-4 seconds. Still better than 20-30. It seems to be as soon as Onedrive is up and running under "Connected Services". – Flemming Bonde Kentved Nov 05 '19 at 23:12

1 Answers1

2

It turns out, the problem had nothing to do with interop so I don't have to change any code. If I opened any docx file (local or nonlocal) in word and then closed it again, it would take that long time to for the Microsoft Word (32 bit) proces to close. If I then, inside Word, opens the Account tab down in the left corner and Sign out of my account. The problem goes away... Omg I considered doing that all day, but nahhh, and ofc it's that. DOH. Sorry guys.

After some tests, by opening several documents, suddenly it started taking longer again. Apparently it automatically signed me in again. After another sign out, it fixed the problem again, so I'm convinced. Ofc I didn't want to stay signed out forever on my personal computer, I then manually signed in again and yes, it takes longer, but not that much longer this time. Maybe 3-4 seconds. Still better than 20-30. It seems to be as soon as Onedrive is up and running under "Connected Services".

Flemming Bonde Kentved
  • 191
  • 1
  • 6