"Object has been deleted" error on earlier worked Word add-in

Question

"Object has been deleted" error on earlier worked Word add-in

ApsSanj 6

I've been maintaining a project (VSTO Word add-in) and it has been working fine for years. Now for some users, it is giving "System.Runtime.InteropServices.COMException HRESULT 0x800A16C1 Object has been deleted" error in certain scenarios. No recent changes to the code done in that area recently. The issue is not recreating in my machine, and for those users, it is not recreating every time. Once they got the error once on a document in a single Word application object, then the error began to appear on all Word documents open user the same application object.

There are several places where we identified as the error is generating.

Creating a temporary document copy of the active document. After the this.wordDocument.Save() is triggered, in the next line, when try to access the this.wordDocument.FullName , it throws the "Object has been deleted" error.

//If this document has a file name,
if (this.wordDocument.Path.Length > 0)
{
	//create a new document using this document as a template.
	this.wordDocument.Save();
	copy = tools.GetDocument(tools.WordApp.Documents.Add(Template: this.wordDocument.FullName, Visible: visible));  <-
}

Download Word documents from our server, and open it in Word. In here, we do several updates to the document content within the Application_DocumentOpen event. The document is having few document variables, lots of field tags, we do some updates to the document variables, refresh the field code content(when necessary) and then do a programmatic Save. We are adding some logs in the process for troubleshooting and logs are kind of weird.

//In ServerFile.cs, document open action calls in here

//...more code here
//Download the document
//Open the document. Add log line "Attempting to open the document"

wordDocument = wordApp.Documents.Open(fileName, ReadOnly: false);
if(wordDocument != null)
{
	//Add log "Document opened in Word"
}

Then it executes the ThisAddIn.Application_DocumentOpen and runs the Tools.DocumentOpen code.

//This goes inside the Tools.DocumentOpen code
if (IsDocumentProtected(objDoc, "DocumentOpen") == false)  
{      	
	objDoc.UpdateTagsIfBroken();      //logs related to UpdateTagsIfBroken, access oDocument.WordDocument.Fields within this.
	objDoc.RemoveFlagsIfNotCheckedOut();  //logs related to RemoveFlagsIfNotCheckout
	bool isChange = !objDoc.WordDocument.Saved;      		
	if (isChange)	
	{          		
		this.ReqDocumentSave = true;      	
	} 
}

//This goes in the ThisAddIn.cs class
public void Application_DocumentOpen(Word.Document doc)
{
	ABC.Application app = new ABC.Application();	
	app.Tools.DocumentOpen(doc);
				
	if (app.Tools.ReqDocumentSave) 	
	{		
		isDocumentSaveWhenOpen = true;		
		doc.Save();	
	}
}

The log should be like below.

Attempting to open the document
logs related to UpdateTagsIfBroken
logs related to RemoveFlagsIfNotCheckout
Document opened in Word

But it is like below when the error occurs.

Attempting to open the document
logs related to UpdateTagsIfBroken
logs related to RemoveFlagsIfNotCheckout
Error System.Runtime.InteropServices.COMException HRESULT 0x800A16C1 throws when accessing oDocument.WordDocument.Fields
Document opened in Word

The error line is occurring out of the normal steps. The oDocument.WordDocument.Fields executes within the UpdateTagsIfBroken function which should not execute again within this flow. But somehow it is executing. So, I feel like the DocumentOpen event is triggering again. I am not sure though.
Cannot add more logs and check as I don't recreate the issue and cannot bother the user always with test installers.

Important points about the error

Both identified issue generating places are having this error after a programmatic document save.
User is downloading the document into a One-Drive shared local location.
User claims they have 'auto save' off.
User is having Microsoft Office version 2607
As it started to happen recently, it should be due to some change in Word.
Apart from the customer who reported the error, we have another error report from other user of the same error.

As a fix, I tried reacquiring the wordDocument object by using a cached document name when this error occurred. But for the error that occurs during the DocumentOpen event, it is kind of tricky. And I don't know if it is the right way to fix this.

Please help me with figuring out what is happening and how to fix it.

Thank you.

Regards,
Apsara

0 comments

1 answer

Your answer

Answer 1

Kai-H 28,425 Microsoft External Staff Moderator

Hi, ApsSanj

The common clue is that the exception appears around a programmatic save, but I would not conclude from the logs alone that DocumentOpen fired a second time. DocumentOpen runs when a document opens; Word also has a separate DocumentBeforeSave event that runs before an open document is saved. A call made from a save-related handler, or another callback in your add-in, could account for the later UpdateTagsIfBroken() log entry. That is something to verify, not yet a confirmed diagnosis.

Here are some suggestions you can try:

Capture the path before saving in the copy routine. Read this.wordDocument.FullName before this.wordDocument.Save(), rather than making the next line depend on the same document reference still being usable. If Save() throws, or a subsequent access to the document fails, stop that operation instead of continuing with the cached object. A cached path can help you identify the document, but it does not make an invalid document reference valid again.

Trace every route into UpdateTagsIfBroken(), not just DocumentOpen. In particular, check your save-related handlers and any callbacks they invoke. Log entry and exit for Application_DocumentOpen, UpdateTagsIfBroken(), and each programmatic Save(), along with a per-operation ID and the document path captured before saving. That should tell you whether this is a second open event, a nested call during the first one, or a separate call after it. Word’s documented save event makes that distinction worth checking.

Guard the save inside Application_DocumentOpen. If your own save-related code can call back into document-processing code, use a per-document “save in progress” guard so it does not process that same document again while your doc.Save() is running. Clear the guard in a finally block. I would avoid a single application-wide flag unless you intend it to suppress processing for every open document.

Test the file location separately from the code path. On an affected machine, try the same document and add-in workflow from a non-synced local folder, then from the OneDrive-synced folder. Keep the Word build the same for that comparison. OneDrive-synced Office files have their own collaboration integration, but the location alone does not establish that synchronization caused this exception, and turning AutoSave off does not settle the question.

Reacquiring the document may be reasonable after you confirm that the original reference is no longer usable and identify the correct document. I would not make reacquisition by name the primary fix yet, especially with multiple documents open. First determine which call runs after the save and whether it is using a reference retained from an earlier step. I also would not label this a Word 2607 regression without a comparison against another build using the same file and workflow.

Kai-H 28,425 Reputation points Microsoft External Staff Moderator

2026-10-01T09:07:37.3966667+00:00

Hi, ApsSanj

It has been a while and I am writing to see how things are going with this issue.

Have you had a chance to check the replies provided?

Any update would be appreciated.
ApsSanj 6 Reputation points

2026-10-02T10:15:46.2+00:00

@Kai-H Thank you for your reply.

On issue 2, About the guess around DocumentOpen event is firing twice :
I checked all the code paths, but didn't found any other place where it executes the UpdateTagsIfBroken() in this situation. By this time, the product is trying to download a file from the server, and open it in Word. In the class where this document is opening, there's no additional code instead of the log for when download is done. When the document is opening, the DocumentOpen event is executing. Then with the programmatic Save, the DocumentBeforeSave() will execute. But we have written logics to not execute it when do programmatic save, only triggering with manual save. If due to some bug if this executed, still there should be more logs in this log then, but there's no logs from that function.
So, I still assume there's a second execution of a Document open function is happening.

Below is what claude is saying :
"The second DocumentOpen firing is a side effect of the first DocumentOpen itself modifying the document, which sets ReqDocumentSave = true, which causes doc.Save(). That save on OneDrive causes Word to recreate the document's COM proxy and re-fire DocumentOpen. The FieldTags.CollectionLoadByDocument errors are not a bug in CollectionLoadByDocument itself — the retry/reacquire logic is working as designed — but it's hitting a genuinely broken COM object because the event is firing prematurely during proxy recreation."

FieldTags.CollectionLoadByDocument is the actual function that has the oDocument.WordDocument.Fields code piece, which is executing inside objDoc.UpdatetagsIfBroken().

Is what claude says correct? I know AI answers are not 100% accurate.

I found that my reacquiring logic is having flaws. I am going to provide an installer build to the user after fixing them with some more logs. I can confirm about the DocumentOpen even suspicion by then.
Kai-H 28,425 Reputation points Microsoft External Staff Moderator

2026-10-04T08:12:50.8466667+00:00

Hi, ApsSanj

If UpdateTagsIfBroken() has no other path in this workflow, and your DocumentBeforeSave handler produces none of its expected logs, a second DocumentOpen invocation is a reasonable hypothesis. I would not dismiss it as a save-handler callback.

I would not treat Claude’s full explanation as confirmed, though. Word documents DocumentOpen as an event that occurs when a document is opened, and DocumentBeforeSave as an event that occurs before a save. I could not verify a documented behavior in which saving a OneDrive-synced document recreates its COM proxy and fires DocumentOpen again. That mechanism, including the claim that the event fires “prematurely,” goes beyond what the current logs establish.

Your plan to add logs to the next installer is the right next step. I’d keep the logging narrow: record entry and exit for DocumentOpen, an invocation ID, the doc.Save() call before and after it runs, and the entry to FieldTags.CollectionLoadByDocument. Capture the document path before saving where possible. If the second DocumentOpen entry appears before the first handler exits, you’ll have evidence of a nested invocation. If it appears afterward, you’ll know it is a separate invocation. Either result would confirm the event behavior without yet proving why Word raised it.

Fixing the reacquisition logic is worthwhile, but I’d keep that separate from the root-cause conclusion. If the new logs confirm a second open event, comparing the same workflow in a non-synced folder would be a useful way to test OneDrive’s involvement.
ApsSanj 6 Reputation points

2026-10-06T07:24:33.4966667+00:00

@Kai-H Thank you for the ideas. I build another installer and sent out to the users who is having the issue. Waiting for their feedback.
Kai-H 28,425 Reputation points Microsoft External Staff Moderator

2026-10-06T08:39:52.7533333+00:00

Glad to hear your heads up.

If you have further updates, feel free to let me know.
ApsSanj 6 Reputation points

2026-10-08T11:13:33.26+00:00
@Kai-H I got one error log from customer. It is related to the "Scenario 2" in my issue. In the installer, I added to print the stack trace inside "FieldTags.CollectionLoadByDocument" and I found out where the second call is coming from. Actually I totally forgot the customer is using a custom .dotm file. The installer is common to any customer, but as per the different customer requests, we have created .dotm files which is kept on Word/Startup folder. And this customer is using one - the important fact that I missed.

In their .dotm, a document open event is executing in WordEventHandler.cs via Macros.bas.

Public Sub AutoExec() Set mobjWordEventHandler = New WordEventHandler End Sub Public Sub AutoExit() Set mobjWordEventHandler = Nothing End Sub

Inside WordEventHandler.cs

Option Explicit Private WithEvents mobjWord As Word.Application Private Sub mobjWord_DocumentOpen(ByVal Doc As Document) On Error GoTo ErrorHandler Procedures.UpdateCrossRefTags WordDocument:=Doc, ShowMessage:=True ErrorHandler: Select Case Err.Number Case 0 Case Else MsgBox Procedures.automationObject.GetUIString("MyApp.Application.UnexpectedError") & " " & Err.Number & " - " & Err.Description & vbCr & vbCr & Procedures.automationObject.GetUIString("MyApp.Application.ErrorSource") & vbCr & Err.Source, vbExclamation + vbOKOnly, "My App" End Select Procedures.QuitMyApp End Sub Private Sub Class_Initialize() Set mobjWord = Word.Application End Sub Private Sub Class_Terminate() Set mobjWord = Nothing End Sub

This Procedures.UpdateCrossRefTags executes a function within the VSTO project AddInUtilities class.

Set addIn = Application.COMAddIns("MyAppAddIn") Set mobjAutomationObject = addIn.Object

Procedures.UpdateCrossRefTags

Public Function UpdateCrossRefTags(ByRef WordDocument As Word.Document, Optional ByRef ShowMessage As Boolean = False) As Long On Error GoTo ErrorHandler Dim objDocument As MyAppEntities.IDocument Dim objFieldTag As MyAppEntities.IFieldTag Dim objParameter As MyAppEntities.Parameter Dim strMessage As String WaitOn Set objDocument = automationObject.GetDocument(WordDocument) Set objFieldTag = automationObject.FirstFieldTagOfDocument(objDocument) <<<<<<< 'the line that access FieldTags.CollectionLoadByDocument Do While Not objFieldTag Is Nothing 'More code here Loop WaitOff End Function

So, when try to access Set objFieldTag = automationObject.FirstFieldTagOfDocument(objDocument), that is the place where the error occurs.

Customer was using this installer (it had several changes over the years, but no changes in AddInUtilities.cs) and the .dotm file (last modified in 2024), but issues are reported in the last month. I am not aware of the change happened recently. May be related to OneDrive document thing - when download the files via our app, customer has configured it to download them into a OneDrive shared Documents folder now. I am not aware it was changed recently or not. or may be related to a Word update. And most importantly

I need to execute the both parts in the two different document_open events. Do you have any thoughts to fix this situation.

About the "Scenario 1", it should be also related to this template. But it is not the document_open event. I am still investigating. Still didn't got any logs related to those.

Thank you in advance.

ApsSanj 6

@Kai-H About the "Scenario 1", not exactly sure if it is related to the .dotm file.
There's a "Publish" button on the ribbon. When click on it, we check for a macro named "ABC_PublishDocument". If it exists in the .dotm, it will execute, otherwise a function from vsto project will execute. For this customer, the "ABC_PublishDocument" macro is executing. The macro (3 steps) has a intermediate step along with what we do in VSTO publish (2 steps) function. The intermediate step is to check for some styles. Macro is also calling the vsto comAddin to execute the functions.
However the error occurs during the 1st step. As I mentioned, right after a Word programmatic save.

2026-10-08 08:45:26 Document.Copy : Calling wordDocument.Save
2026-10-08 08:45:27 Document before save event is executing for https://bcd-my.sharepoint.com/personal/eliz_brown_abcd_com/Documents/Documents/ABC/test.docx ID :1049494972
2026-10-08 08:45:27 ABC logic for document before save executing.
2026-10-08 08:45:29 Document.Copy : Save completed. Calling Documents.Add with template: https://bcd-my.sharepoint.com/personal/eliz_brown_abcd_com/Documents/Documents/ABC/test.docx
2026-10-08 08:45:29 Document.Copy : Document full name fetching fail - HRESULT: 800A16C1 - Object has been deleted.
2026-10-08 08:45:29 Document.TryReacquireWordDocument : Reacquired WordDocument reference for https://bcd-my.sharepoint.com/personal/eliz_brown_abcd_com/Documents/Documents/ABC/test.docx 
2026-10-08 08:45:29 Re-aquired document ID : 1049494972
2026-10-08 08:45:29 Document.Copy : Documents.Add (template) completed. copy is Document44
2026-10-08 08:45:30 Document before save event is executing for Document44 ID :1049494972

This log part happens within the 1step, it will to return the created temporary document to the vba macro back. This error is happening even before creating the document using Documents.Add. So I guess this is not related to the .dotm file. I am not sure.

The good thing is, the document re-acquiring logic seems to be working fine for Scenario 1. So customer is saying they doesn't get any errors during publish and only get during checkout.

This is the re-acquiring logic which is in Document class.

internal bool TryReacquireWordDocument()
{
	/* Attempts to get a fresh COM reference to the underlying Word document when the current
	reference has been invalidated (HRESULT 0x800A16C1 / error 5825 "object has been deleted").
	This can occur when Word internally recreates its COM proxy during background operations
	such as AutoSave, MIP/DLP sensitivity labelling, or co-authoring sync. */
	if (string.IsNullOrEmpty(this.cachedFullName))
	{
		tools.DiagnosticLog.LogWrite("Document.TryReacquireWordDocument : No cached FullName available — cannot reacquire");
		return false;
	}
	foreach (Word.Document doc in tools.WordApp.Documents)
	{
		try
		{
			if (doc.FullName == this.cachedFullName)
			{
				tools.DiagnosticLog.LogWrite("Document.TryReacquireWordDocument : Reacquired WordDocument reference for " + this.cachedFullName);
				this.wordDocument = doc;
                tools.DiagnosticLog.LogWrite("Re-aquired document ID : " + this.wordDocument.DocID);
                return true;
			}
		}
		catch (COMException) { }
	}
	tools.DiagnosticLog.LogWrite("Document.TryReacquireWordDocument : Document not found in open documents — " + this.cachedFullName);
	return false;
}

Still don't know what triggers this object status change when do programmatic save.

Kai-H 28,425 Reputation points Microsoft External Staff Moderator

2026-10-11T07:36:39.1933333+00:00
Hi, ApsSanj

That stack trace clears up an important part of Scenario 2: you have two handlers calling into the add-in, not evidence that Word raised DocumentOpen twice. The remaining question is why the document reference used by the second handler is no longer usable.

I would focus on coordinating those handlers and checking the cached wrapper, rather than assuming OneDrive recreates the COM proxy.

For Scenario 2, my suggested approach is to keep both pieces of functionality, but give their execution order one owner. For example, let the VSTO open workflow perform the standard updates, invoke the customer-specific VBA procedure, and then save after both have finished. Calling between VBA and a VSTO add-in through an exposed automation object is supported. The proposed ordering is a design change, not a documented fix for this exception.

If both event handlers must remain, I’d have them register their work with a shared coordinator instead of independently updating and saving the document. A simple “busy” flag that discards the second handler would not meet your requirement, since both operations need to run.

Also, check this boundary closely:

Set objDocument = automationObject.GetDocument(WordDocument)

Does GetDocument() return an existing MyAppEntities.IDocument wrapper whose WordDocument still points to the reference used before the save? As a diagnostic, log whether the incoming WordDocument can access FullName and Fields, then whether the returned wrapper’s WordDocument can do the same. If the incoming document works but the wrapper fails, that would isolate the problem to the cached wrapper. When rebinding it, also invalidate any cached field or range references associated with the old document reference.

For Scenario 1, your log contains another useful clue:“ABC logic for document before save executing” appears during the programmatic save. That deserves investigation even though the failure occurs before Documents.Add. DocumentBeforeSave occurs before any open document is saved; SaveAsUI indicates whether a Save As dialog is displayed, not whether the save was initiated manually.

My suggestion is to use one shared programmatic-save scope across the VBA and VSTO paths, reset it in finally, and have your custom save handlers consult it. Log any close, reopen, reload, or wrapper-replacement operations inside that handler.

Two cautions about the recovery code:

DocID is reserved for internal use, so the matching IDs do not prove document or COM-reference identity. Use your own operation IDs for tracing.

Reacquisition succeeding demonstrates that another usable reference was found. It does not establish that AutoSave, sensitivity labeling, or coauthoring recreated a proxy. I would remove those asserted causes from the comment until verified.

The publish recovery is encouraging. For checkout, I’d investigate GetDocument() and its cached child objects first, while treating OneDrive and the Word build as separate comparison tests rather than confirmed causes.