This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
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 that installations are now failing everywhere.
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?
I have a test script and test files but I can't attach them to this forum, it won't accept zip or .doc/.docx files
Your test seems to work in "Microsoft® Word for Microsoft 365 MSO (Version 2208 Build 16.0.15601.20072) 64-bit", in Windows 11.
I've reproduced this on 3 computers here (2 running Windows 11 and one running Windows 10). All running the Current Channel Click-to-Run. I've tested rolling back across 7 previous builds. Plus another customer yesterday in Australia running Windows 10 and the current 2208 build fails and got it working rolling back to the July 18.
• Version 2208 (Build 15601.20088) Aug 31 (fails) Click-to-Run, Current Channel
• Version 2207 (Build 15427.20210) Aug 9 (fails)
• Version 2207 (Build 15427.20194) Aug 3 (fails)
• Version 2206 (Build 15330.20264) July 18 (WORKS)
• Version 2206 (Build 15330.20230) July 6 (WORKS)
• Version 2206 (Build 15330.20196) June 29 (WORKS)
• Version 2205 (Build 15225.20288) June 14 (WORKS)
On another forum I got confirmation from 2 different MVPs who reproduced it today. They tested it and it worked for them on 2 builds that it fails on here. BUT they both reproduced the error on another computer running the current Aug 31 build. So there is a problem, its just not showing up on every computer, just a lot of them. Enough to show there is a problem that has started cropping up recently.
One MVP's confirmation was "However, I did encounter the error after updating the Windows 11 machine to the same version as on the Windows 10 machine - Version 2208 (Build 15601.20088 Click-to-Run) Current Channel."
Maybe you should try to work around the problem, i.e. to do the same things in a different manner.
There are only a few different ways calls to the InsertFile function are made and I've tried every variation of coding it I've found. Using a range variable like in the test code. Using a Selection and collapsing that which is how our code in the product has been doing the last 20 years and a minor variation on how its called from the ActiveWindow.
The only test that has worked that would be a very ugly hack would be to have our product save the .docx files its inserting first as .doc files, insert the temporary .doc file then delete that temp file. But only if a flag has been set that the error occured in the first place that could be toggled if the user didn't want to rollback their Office. And that would almost double the amount of time it takes to assemble complex documents.
This is a business software product that's been on the market since 1997, the code for assembling proposals, business plans, contracts, etc has been in use since the first versions of Word used the VBA system, I think that was back in Word 2002 or Word 2003. We have a library of 500 products spanning over 1 million templates and years ago everything was upgraded to work on the current format .docx files. Having to this ugly of a hack to use legacy 2003-2007 formats under the covers because an Office patch a month ago is breaking our product is not a solution. We'll do it if we have to and have already started the work just in case Microsoft can't give us a solution of some kind.
We have also done a lot of testing of the files to see if different formats of the same file work or don't work and its pointing to something within current version formats of our files that fail but legacy formats work - of the same source file. Which seems to eliminate the file itself being corrupt or something wrong with it as its being resaved and converted by Word as follows:
If we take a file that fails to insert like ExecSummaryA.docx (which is a current format file), then do a Save As in Word's toolbar as a legacy 2003-2007 .doc file ExecSummaryB.doc (that will will insert without errors). But if we then open ExecSummaryB.doc and using the Info screen > Convert to convert the file, then Save As ExecSummaryC.docx. That file fails to insert again.
We've reproduced this with more than one template like this. We did have to close the test macro document and all documents and start clean each run of the test script.
If I save a failing .docx file as an legacy .xml or .odt file they do insert without errors. But saving them as current format .xml or strict .xml files the inserted .xml version fails.
So all these variations of resaving and converting documents where legacy formats are showing to work, but current format documents fail seems to show the InsertFile function is balking on something within current format files (of more than one format).
I also tried rolling back office back and forth to fix it then make it come back again. If I rollback Office to the July 18 build the problem goes away, the test scripts work and our product works.
If I update Office back to the current build, the problem comes back. I rollback to the July 18 build and it goes away again.
The problem is definitely spreading as customers upgrade their Office 365. This weekend a company in Australia encountered the problem when I started reporting it in these threads. Today a company in the UK is getting it. And both of these companies are using our templates that are different than the ones I used in the test cases.
![](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(57.599999999999994, 75%, 15%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EHM%3C/text%3E%3C/svg%3E)
How do we submit this problem to Microsoft's Office 365 team as a bug report?
The "official" way is to use the File/Feedback option available in the Office 365 desktop applications. You can see all the feedback you submitted via this option in the Microsoft 365 Admin Center under Health/Product feedback.
That having been said, my personal experience in reporting bugs (Access VBA) is that getting the attention of the MVPs is more likely to lead to success. They have channels to the developers that we mere mortals don't.
Thanks, I posted this in another forum somewhere that got picked up by a couple MVPs who reproduced the problem over the weekend and one sent it up the chain to the Office 365 team.
![](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(192, 28.999999999999996%, 28%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EIW%3C/text%3E%3C/svg%3E)
It's still an ongoing problem, as of 1/6/2023 the most recent build is still failing. Last we heard from the MVP on the other thread as you probably saw by now is that the Office team did reach out to him that they have opened a case for the problem but are backlogged at the moment.
We are using a workaround now that does more or less get around it by not using the InsertFile function anymore and instead opening the document that is to be inserted then doing a Copy and Paste operation. Its not as seamless as you can't open the file to be inserted minimized either, and sometimes footers get lost.
Were about another month in and the most recent Office 365 update and Windows updates didn't change anything. We continue to have more and more customers from all over the world experiencing this problem. Some are new customers some are longtime customers who have had their Office 365 recently updated who are now having the problem. All are using different sets of templates as well. The only commonality is that they all have one of the more recent Office 365 builds that is failing.