C# MSOffice Interop Word will not kill winword.exe

cinteropzombie-process

I'm writing an application that needed a MSWord document parser.

I'm using Microsoft.Office.Interop.Word.Document to extract the texts from the documents, but even if i use doc.Close() the document, from taskManager i can see that winword.exe are not killed, and after parsing a couple dozens documents it eats up some much resources.

is close() the wrong method?

please help me and point me to the right direction on how to terminate these processes properly. =)

~~~update~~~

Thanks for all the help. I use the app.quit() and also ran a loop that checks for the process and problem solved! =)

Best Answer

Are you calling Application.Quit , additionally since you're doing Interop it may be worthwhile to release the RCW wrapper.

So basically something like:

yourWordAppObject.Quit();
System.Runtime.InteropServices.Marshal.FinalReleaseComObject(yourWordAppObject);

Note some folks use: ReleaseComObject but there are some potential pitfalls

Related Solutions

C# – How to properly clean up Excel interop objects

Excel does not quit because your application is still holding references to COM objects.

I guess you're invoking at least one member of a COM object without assigning it to a variable.

For me it was the excelApp.Worksheets object which I directly used without assigning it to a variable:

Worksheet sheet = excelApp.Worksheets.Open(...);
...
Marshal.ReleaseComObject(sheet);

I didn't know that internally C# created a wrapper for the Worksheets COM object which didn't get released by my code (because I wasn't aware of it) and was the cause why Excel was not unloaded.

I found the solution to my problem on this page, which also has a nice rule for the usage of COM objects in C#:

Never use two dots with COM objects.

So with this knowledge the right way of doing the above is:

Worksheets sheets = excelApp.Worksheets; // <-- The important part
Worksheet sheet = sheets.Open(...);
...
Marshal.ReleaseComObject(sheets);
Marshal.ReleaseComObject(sheet);

POST MORTEM UPDATE:

I want every reader to read this answer by Hans Passant very carefully as it explains the trap I and lots of other developers stumbled into. When I wrote this answer years ago I didn't know about the effect the debugger has to the garbage collector and drew the wrong conclusions. I keep my answer unaltered for the sake of history but please read this link and don't go the way of "the two dots": Understanding garbage collection in .NET and Clean up Excel Interop Objects with IDisposable

C# – How to remedy “The breakpoint will not currently be hit. No symbols have been loaded for this document.” warning

Start debugging, as soon as you've arrived at a breakpoint or used Debug > Break All, use Debug > Windows > Modules. You'll see a list of all the assemblies that are loaded into the process. Locate the one you want to get debug info for. Right-click it and select Symbol Load Information. You'll get a dialog that lists all the directories where it looked for the .pdb file for the assembly. Verify that list against the actual .pdb location. Make sure it doesn't find an old one.

In normal projects, the assembly and its .pdb file should always have been copied by the IDE into the same folder as your .exe, i.e. the bin\Debug folder of your project. Make sure you remove one from the GAC if you've been playing with it.

Best Answer

Related Solutions

C# – How to properly clean up Excel interop objects

C# – How to remedy “The breakpoint will not currently be hit. No symbols have been loaded for this document.” warning

Related Topic