Vom Grundsatz läuft da sowieso etwas falsch.
Office wird per COM-Interop als Out-of-Process-Komponente gesteuert.
Ich nehme mal an, dass oWord auf Word.Application und oDoc auf das Dokument verweist.
oWord.Quit() ist in der Regel wirkungslos, da du auf diesem Wege eine COM-Referenz nicht los wirst und Word sich damit nicht beendet.
Wenn du das Objektmodell von Office betrachtest, so hält oDoc wiederum selber eine Referenz auf Word, so dass der Prozess da immer noch nicht beendet werden kann.
Der normale Weg ist ganz einfach:
C#:
oDoc = null;
oWord = null;
VB
oDoc = nothing
oWord = nothing
Auch ggf. alle anderen Variablen, die irgendwann mal auf Objekte in Word verwiesen haben, sind auf jeden Fall auf null/nothing zu setzen.
Wenn der letzte Verweis entfernt ist, schlägt der GC irgendwann zu und setzt die COM-Referenz auf 0, so dass der Prozess dann endet.
Dies kann man forcieren, wenn man GC.Collect() mit GC.WaitForPendingFinalizers() gezielt aufruft.
Man darf nie ReleaseDispatch() oder Marshal.ReleaseComObject() verwenden, wenn irgend ein Objekt noch Referenzen haben sollte.
COM-Objekte werden aufgelöst, wenn der Verwendungszähler auf 0 gesetzt wird.
Die Release-Funktionen setzen den Zähler direkt auf 0, egal wieviele Verweise es noch gibt. Wird dann irgendeine andere Variable vom GC erfasst und aufgelöst, so versucht dieser wiederum den Zähler um 1 zu vermindern.
Da das Ziel-Objekt aber zerstört ist, kommt es intern beim GC auch zu Exceptions, was den Prozess verlangsamen kann.
Wichtig ist bei COM-Objekten vor allem eins:
Sobald die Variable nicht mehr benötigt wird muss diese auf "null" gesetzt werden.
Mehr ist nicht zu tun.
Nachtrag:
Ich habe gerade geshen, MFC-Anwendung.
In diesem Fall verwendest du ja COM-Pointer, die mit Release() den Zähler um 1 vermindern und bei 0 das Objekt freigeben. Verwendest du CComPtr macht das die Klasse selber bei der Zuweisung von NULL.
