InvalidOperationException: Sys.InvalidOperationException: Invalid BaseDocQuerySignature in appSettings

Question

We are experiencing an issue with the Microsoft Office Online / WOPI document editing integration in our application.

When a user clicks**“Edit Document”**, our application opens the Microsoft Word Online editor page in an iframe/new page. However, the document does not load and Microsoft Word displays:

“Sorry, we ran into a problem. Please try again.”

In the Chrome Developer Tools console, we can see the following error:

Sys.InvalidOperationException:

Invalid BaseDocQuerySignature in appSettings

The functionality was working correctly previously, but recently stopped working.

Around the same time, we made the following changes in our application environment:

• Upgraded Node.js to version 24
• Upgraded related packages, including undici
• Made changes to the CSRF handling/process

We have not yet confirmed whether these changes are related to the issue.

Could you please help us investigate the “Invalid BaseDocQuerySignature in appSettings” error and identify why the Microsoft Word Online editor is no longer able to load the document?

We have attached a screenshot showing the Word error and browser console error for reference.

Answer 1

Please note that our forum is a public platform. Kindly ensure that you hide any personal or organizational information to protect personal data.  

Hi Lalu Prasad

The Invalid BaseDocQuerySignature in appSettings message appears to be raised inside Word for the web during initialization. I would not recommend trying to add or modify a BaseDocQuerySignature setting directly in your application, as this is not a WOPI host configuration parameter documented for customers.

Since the integration was working previously and stopped around the same time as the Node.js, undici, and CSRF changes, I would first verify whether the WOPI host page or the request sent to Microsoft 365 for the web has changed.

According to Microsoft's WOPI host-page requirements, the host should use the WOPI action URL obtained from discovery and submit access_token and access_token_ttl to the Microsoft 365 for the web iframe using an HTTP POST rather than placing the access token in the query string.

For more information, you can refer to:

Set up a host page | Microsoft Learn

PnP-WOPI - Code Samples | Microsoft Learn

I suggest checking the browser Network trace for the failing session and comparing it with the implementation before the recent application changes. In particular, verify:

• The WOPI action URL generated from discovery has not been modified, re-encoded, decoded, or reconstructed unexpectedly.
• WOPISrc and any query-string parameters are preserved exactly as expected when constructing the action URL.
• access_token and access_token_ttl are still POSTed correctly by the host page.
• The recent CSRF changes are not rewriting, rejecting, or injecting parameters into the form POST.
• The Node.js/undici upgrade has not changed URL serialization or query-string encoding.
• The WOPI endpoints such as CheckFileInfo, GetFile, and the editing/locking operations are still receiving requests and returning their expected responses. Microsoft's WOPI sample describes the host as consisting of the Office frame plus the WOPI endpoints that Microsoft 365 for the web calls to work with the document.

A particularly useful isolation test would be to temporarily run the previous Node.js/package version or the previous CSRF implementation. If Word begins loading again, that would considerably narrow the problem to a change in how the host page, WOPI URL, or POST data is being generated.

The console also shows Microsoft-hosted Word resources loading successfully, while Word subsequently encounters the BaseDocQuerySignature exception during initialization. Therefore, the BaseDocQuerySignature exception by itself does not establish that the problem is with the Word JavaScript files shown in the stack trace.

If possible, please also capture a HAR/network trace from a session where the issue occurs and check the generated WOPI action URL and the POST payload (with the actual access token removed before sharing). That should help identify whether the problem occurs before Word calls the WOPI endpoints or after communication with the WOPI host begins.

I hope this information helps and look forward to your response.