This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
We have a product that assembles custom templates that has been around for about 20 years that operates on a library of about 1 million Word .docx format templates. With users across the world. Its been in use on every version of Word since 2003 (currently only supported on all versions of Office 365 but it also still works on Word 2010). We use the Word VBA function InsertFile to append pages together to create custom documents from the template library.
Recently all of our installations started failing with the InsertFile function returning error 5097 - "Word has encountered a problem". And customers have started reporting the same error.
We traced it down to being introduced in the Aug 3 Build of Word and verified it on multiple computers (both Windows 10 and Windows 11). If we roll back our Word builds through the last 7 builds we found that in every case the June 14, June 29, July 6, July 18 builds of Word work fine. But all 3 builds after that which are Aug 3, Aug 9 and the current Aug 31 fail.
Something appears to have been recently broken by Microsoft in the Aug 3 Build that causes the Word's InsertFile function to fail. This happens on almost all of our Word .docx template we have tested. But when inserting the file via the Word toolbar's Insert > Text From File > browse to the file it works. But it always fails now when calling the InsertFile function via VBA. Again, this is not a new macro or templates. This code has been in use for almost 2 decades and the templates have been in use for for many years. Its only since the recent builds of Word in the last month that installations are now starting to fail everywhere.
This zip file linked below contains the macro vba test function and some example files to reproduce the problem.
When we save those templates that are failing to insert as legacy Word 2003-2007 .doc files they do insert without failing. And if we save them in Word 2003-2007 XML or as an OpenDocument .odt file they insert correctly. But if we save them as Word XML .xml or Strict Word XML .xml they also fail. So there is nothing corrupt in the files, it appears to be inserting current format files of various file formats are failing, but saving those failing files as legacy formats they insert correctly.
How do we submit this problem to Microsoft's Office 365 team as a bug report? This is a serious problem that breaks our product and requires us to have everyone roll back their Office 365 to the July 18, 2022 build and we're in the process of having to update our product to provide instructions when the error occurs on how to roll back Office 365.
The code in the test script is also here. But it needs the .docx files from the ZIP file to operate on.
Sub InsertTest()
Dim DocRng As Range
Dim FileToInsert As String
Dim SourceFile As String
Dim MsgStr As String
Dim MsgResult As Long
On Error GoTo ErrHandler
SourceFile = "c:\temp\CoverLetter.docx"
FileToInsert = "c:\temp\ExecSummaryA.docx" ' This file fails to insert
' FileToInsert = "c:\temp\ExecSummaryB.doc" ' This file works (this was the ExecSummaryA.docx Saved As a .doc file in Word 2003-2007 format)
' FileToInsert = "c:\temp\AccessoriesA.docx" ' This file fails to insert
' FileToInsert = "c:\temp\AccessoriesB.doc" ' This file works (this was the AccessoriesA.docx Saved As a .doc file in Word 2003-2007 format)
Documents.Open FileName:=SourceFile
ActiveWindow.ActivePane.View.Type = wdPrintView
Set DocRng = ActiveDocument.Content
DocRng.Collapse (wdCollapseEnd)
DocRng.InsertFile FileName:=FileToInsert, Range:="", ConfirmConversions:=False, Link:=False, Attachment:=False
Exit Sub
ErrHandler:
MsgStr = "Error: " & Err.Number & " - " & Err.Description
MsgResult = MsgBox(MsgStr, vbSystemModal + vbMsgBoxSetForeground, "Insert Error")
End Sub
A family of Microsoft word processing software products for creating web, email, and print documents.
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
Great news. The 2302 patch just came out, tested it on a couple computers here and the InsertFile function is now working properly.
Hi Doug,
Here is a screenshot from my 2nd Windows 10 PC running 64-bit Word showing the same 5097 error still occurring. Again I did all the Windows updates and did a full uninstall and reinstall then an update of Word to get a clean install with the latest build.
One thing to note is that my documents that are completely plain text documents have always worked fine. But all my other documents (the bulk of them) that have some embedded graphics are the ones that have been failing. My templates that have embedded graphics were created by starting with my plain text documents then running VBA scripts that embed a small inline graphics (a logo) at the start of the page and an accent logo in the footer, and changing the bullet point word style to use a small graphic. That's the only difference between docs that work and docs that fail with InsertFile. The graphics were added with the AddPicture VBA call.
The 2nd person who jumped on the thread the other day who also has the same problem now with InsertFile and the 5097 error mentioned they have graphics in their documents. That seems to be something common now across all the docs failing with InsertFile. When I use the copy/paste method of getting my content back into a new document and those new documents work they still have the same graphics and content in the new files. But since the graphics were put into the new document via a Paste operation and not an AddPicture operation could there be something in the formatting of the file that InsertFile is now balking on that was introduced unexpectedly back in that July build? Or its just a coincidence or a side effect of something else. Only way to know is having someone who can debug the actual InsertFile code tell us.
Thanks for the update Doug.
When the problem originally happened I reproduced it on 2 different PCs running Windows 10 Home. I just did so again.
I ran all the system updates and downloaded the most recent Word build and tried it again on the Windows 10 computers and it still fails here on all the PCs. I also updated my Windows 11 dev PC to the lastest Word build and it fails there as well still.
See attached pics of my Windows 10 versions. And in the debugger where it captures the 5097 error on the InsertFile call still.
Note I'm running the 32-bit Word on one of the Windows 10 PCs shown in the screenshot as I have to use 3rd party DLLs which aren't supported in the 64-bit for some testing. The other Windows 10 PC is running the 64-bit edition of Word. Fails on both of them.
I have sent another message to the Product Team to advise them that the problem still occurs on a Windows 11 machine running Version 2211 (Build 15831.20190 Click-to-Run) Current Channel
As with prior Versions of Office, the error does not occur here with that version on a computer that is running Windows 10.
Unfortunately the extra save as I recall didn't work. I tried it again 2 different ways.
The only 2 things that have gotten around the 5097 errors for me so far are:
A) Save the .docx files as .doc files using temp file names, use InsertFile on the legacy format .doc file, delete the temp file (this works but I tend to loose items in the footers).
B) Create a new docx file from scratch, open the .docx file with the content, use a Copy/Paste operations to copy from the original .docx to the empty .docx file, I use custom Word styles so have to also reapply all my custom Word styles that don't come over from the copy/paste. This works but I get an artifact of a bullet point graphic added in front of the content of the file when InsertFile inserts the rebuilt .docx file. So then I have to run a batch process to post-process the assembled file to find and remove all the added bullet point graphics. And sometimes I lose something in the footer.
Neither workaround is great but that's all I came up with so far barring having to use the copy/paste to rebuild all 1 million plus templates to go back to using InsertFile without my software having to kick into a work around mode that isn't always perfect and adds overhead. And then having to post process every created document to remove added bullets is kind of hack.