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.
Using a 64-bit installation of Microsoft 365 Apps for enterprise Version 2210(Build 15726.20174 Click-to-Run) Current Channel on Windows 11 Pro Version 21H2, OS Build 22000.1098, no errors were received when running the code in your original post after making suitable modifications in the code for the path\filename of the SourceFile and the FileToInsert.
I am not sure from where that extraneous character comes, but it can be deleted by adding the following command to the code immediately after the DocRng.InsertFile
DocRng,Paragraphs(1).Range.Characters(1).Delete
If I try to get the ASC code for the character, it returns 1
In the backstage Print view, the character appears in the position shown below, which is also where it appears if the document is saved as a pdf.
There is definitely a difference then between the enterprise and what I and many of our customers are running. I don't have the enterprise version. Since I first posted about this months ago everyone who has tried Enterprise versions has said it worked, but non-enterprise versions are the ones that are consistently failing.
I just upgraded 2 of my PCs to the current build "Microsoft Word for Microsoft 365 MSO (Version 2210 Build 16.0 15726.20070) 64-bit (that's what the About screen shows) but the Account screen says Version 2210 (Build 15726.20174 Click to Run) Current Channel and both are still failing with the original InsertFile error code 5097 that goes back to the Aug 3 build. And I continue to get more customers computers encountering it. Running Windows 11 Pro (current version).
Also reinstalled Office on both computers.
I really need to figure out these glitches to have proper working product again. Everything else so far are just hacks and bandaids.
I know I can add an extra process to find and delete all the bullet characters but its kind of a cleanup hack that shouldn't have to be done. But why would it work fine when inserting the document via the toolbar (when I record a macro of it as well, the macro is only a single line which is Word calling the InsertFile function with the same parameters the VBA code uses). But via VBA it adds this extra bullet graphic.
Thanks for the input. Hoping someone somewhere sees this and has some kind if insight or something that helps point me in a direction for something to try.
Wow. I've been giving 5 stars to just about anything Ian and Doug have posted.
To Ian for excellent, civil "pleas" for help.
To Doug for providing Ian the continued opportunity to give Microsoft examples of failure, making a great effort to help Ian (and all his customers and everybody else with the problem).
This thread, sort of ironically, implements Doug's (and V Ramaswamy's) plea for ‘Excellence, Opportunity & Civility’, as both Doug and Ian have demonstrated that Microsoft will, indeed, listen, especially if addressed in such a civil and erudite manner, and will (I have to believe) find a fix. It has, possibly only because of Doug, made me hopeful of more such exchanges, with Microsoft's "stock" among users rising with each.
There are MVPs and then there's Doug. I'm sure he's not the only "Doug" out there, but it's a rare MVP who would stay with a user this long, and a rare thread that wouldn't have been closed by now, but, understandably, is still open.
(I hope there's a happy ending to the thread, for Ian's and the entire Microsoft community's sake. I hope find this thread again and read that happy ending.)
(Microsoft: I will not be offended if it is deemed that this message, contributing nothing to the thread, should be deleted. I just felt I had to express gratitude for the unusual opportunity to experience an hour's worth of the most incredibly bright thread I've ever stumbled upon.)
Doug is fantastic for sure. No luck yet on a resolution, the last few updates haven't changed anything.
Another curious thing that also happened recently also with the InsertFile function is a 2nd behavior that is different when calling InsertFile vs using the Toolbar option Insert > Object > Text from File (which if you run a macro says it calls InsertFile).
After testing the workaround where I open a brand new document, copy/paste the content from a document that fails on InsertFile, reapply my custom Word styles then use those rebuild documents with InsertFile, as Doug noted that does get around the InsertFile failing with the 5097 error (but since I have a library of over 1 million templates that would take me about a year to rebuild and retest even with the automation I have to do it, its not a great long term option still).
But now InsertFile is leaving an artifact in the pages. If I take those rebuilt templates (which are literally just some plain text and a graphic .png file at the start with some Word Styles applied to the text). And I did add a custom bullet point graphic to the Bullet Word Style. But even with templates that don't use bullets what InsertFile does now is it inserts a graphic from the bullet point style (not as a bullet point style applied, just the graphic) first, then the contents of the file. The graphic has the Normal font style and an asterisk as the AltText which is what bullets have, but its not in the bullet font type.
Now if I manually do the same process with the toolbar to use Insert > Object > Text From File and pick the same templates it inserts without adding the bullet graphic to the start of the contents of what it inserted.
It is odd that I'm getting 2 completely different behaviors with InsertFile now that both work when using the toolbar option.