Share via

We are experiencing an issue specifically with PowerPoint Online editing through WOPI. For the first time able to edit the ppt file but next time when try to open the same document it is not opening.

Santanu DonePact 0 Reputation points
2026-06-04T08:25:25.59+00:00

Issue Summary

We are experiencing an issue specifically with PowerPoint Online editing through WOPI.

First Open (Edit Mode)

When a user opens a PowerPoint document in edit mode for the first time:

CheckFileInfo is called.

GetFile is called.

LOCK is received.

User edits the presentation.

PutFile is received.

UNLOCK is received.

Session completes successfully.

Everything works as expected.

Subsequent Open (Edit Mode)

When the same user reopens the same PowerPoint document in edit mode:

CheckFileInfo is called repeatedly.

GetFile is called.

No LOCK request is ever received.

No RefreshLock requests are received.

No PutFile requests are received.

Office Online appears to remain in a non-editable state.

The Office client continuously polls CheckFileInfo but never initiates an editing session.

Observations

CheckFileInfo Response

The response returned during the failed edit attempt is:

{
  "BaseFileName": "DNPT_20260604_073554_document.pptx",
  "Size": 23956,
  "OwnerId": "2",
  "UserId": "29",
  "Version": "1780558558670",
  "UserCanWrite": true,
  "SupportsLocks": true,
  "SupportsGetLock": true,
  "SupportsUpdate": true,
  "ReadOnly": false
}

Office Discovery

The discovery endpoint returns:

ACTION = edit

OFFICE_URL =
https://FFC-powerpoint.officeapps.live.com/p/PowerPointFrame.aspx?PowerPointView=EditView&

File Validation

The PowerPoint file has been verified:

Opens correctly in Microsoft PowerPoint Desktop.

Downloads successfully from WOPI GetFile.

ZIP structure validation succeeds.

MD5 checksum remains consistent.

File size remains consistent.

Lock Status

We confirmed:

No stale WOPI locks exist.

wopi_locks table is empty after successful UNLOCK.

Subsequent edit attempts occur with no active lock record.

Version Consistency

For all CheckFileInfo and GetFile requests during the failed edit attempt:

Version = 1780558558670

The same version is returned consistently.

Access Rights

For failed edit attempts:

{
  "UserCanWrite": true,
  "ReadOnly": false
}

indicating the document is presented as editable by the WOPI host.

Expected Behavior

When opening the document in edit mode:

CheckFileInfo
GetFile
LOCK
RefreshLock
PutFile
UNLOCK

Actual Behavior

When reopening the document:

CheckFileInfo
GetFile
CheckFileInfo
CheckFileInfo
CheckFileInfo
GetFile
...

No LOCK request is ever sent.

Additional Question

Is there any known PowerPoint Online behavior where:

A presentation that was previously edited successfully through WOPI

Has no active lock

Returns UserCanWrite=true

Returns ReadOnly=false

can still be prevented from entering edit mode without issuing a LOCK request?

Additionally, are there any PowerPoint-specific CheckFileInfo fields or session requirements that differ from Word Online and could cause PowerPoint Online to remain in polling mode without initiating an editing session?

Request

Please advise:

  1. Why PowerPoint Online may refuse to issue a LOCK request on subsequent edit attempts.

Whether any additional CheckFileInfo properties are required specifically for PowerPoint Online. Whether there are known caching/session behaviors related to PowerPoint documents and WOPI that could cause this behavior. Any diagnostic logs or CSPP-side telemetry that can be enabled to identify why the edit session is not being initiated. Whether the repeated CheckFileInfo polling pattern without LOCK is indicative of a known validation failure within Office Online.

Microsoft 365 and Office | Development | Other
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Peter E PV 0 Reputation points
    2026-06-18T11:57:06.8966667+00:00

    Hi,

    I found this question here now, while trying to figure out what has started happened with our Microsoft Office for Web integration. Was there any solution found?

    A few days ago we started to get reports from our users (production environment) that PowerPoint files are not opening, showing the same error as @Santanu DonePact posted here. Investigation showed that opening a pptx file the first time works, and the file can be edited. After closing it and then trying to re-open it fails with this error.

    Analysis of this shows exactly the same flow as described here. During the first edit, the document is properly locked, putfile, unlocked. When opening a second time, it does the checkfileinfo, getfile, checkfileinfo, checkfileinfo. No locking requests are received. And after a while the GUI reports the error.

    We have tried a most of the suggestion by @Gabriel-N (in development environment)

    • Validating that version is consistent. A new version is generated after the putfile.
    • "DisableCoauthoring": true
    • Use the WOPI Validation Tool - works both in production and development environments (50 successful, 178 skipped).

    This error only occurs for PowerPoint. Excel and Word works without any problem.

    Was this answer helpful?

  2. Gabriel-N 19,210 Reputation points Microsoft External Staff Moderator
    2026-06-04T12:40:28.2466667+00:00

    Hello @Santanu DonePact

    I would like to first clarify that this is a user-to-user support forum, and we are not Microsoft support. Moderators here do not have backend access and cannot directly intervene in Microsoft products or perform escalations. We can only provide technical guidance and best-practice recommendations based on reported issues.

    Based on my research, I have a few ideas that might be helpful to check.In some cases, if the co-authoring capability signals are not fully aligned or appear inconsistent, the client may stay in a safe polling state instead of proceeding to LOCK. You may want to try adding "DisableCoauthoring": true in the CheckFileInfo response to enforce single-user locking behavior. If co-authoring is intended, you could also verify that related signals (such as consistent FileId/WopiSrc and capability flags) remain stable across sessions.

    Another area that may be worth checking is versioning behavior. Even if the same Version value is returned consistently, some clients rely on version changes to determine whether a fresh edit session should be initiated. If the version does not change after a PutFile, or if there is any mismatch between the Version in CheckFileInfo and the X-WOPI-ItemVersion header returned by GetFile, the client might decide not to proceed with LOCK.

    As a test, you could try generating a new unique Version value after each successful PutFile, and ensure the exact same Version string is returned both in CheckFileInfo and in the X-WOPI-ItemVersion response header from GetFile.

    You could also consider including a few additional standard metadata fields in CheckFileInfo to see if it improves consistency, for example:

    • "LastModifiedTime" (ISO 8601 format)
    • "IsEncrypted": false
    • "BreadcrumbDocName"
    • "UserFriendlyName"

    These are not strictly required for PowerPoint, but in some implementations they appear to help the client establish a more stable edit context.

    For diagnostics, you might want to capture a browser network trace while the polling is happening:

    • Open Developer Tools (F12) > Network tab
    • Observe requests to the Office endpoints
    • Compare the request/response pattern between the first (working) open and the second one

    This may not always expose a clear error, but sometimes subtle differences in headers or flow can provide useful clues.

    Or you might want to use Microsoft’s official WOPI Validator tool. It is designed to test exactly these scenarios (edit flows, locking, PutFile, and version handling).

    However, please note that these are suggestions based on research. I don’t currently have the same environment to reproduce this scenario, so I wouldn’t want to draw a definitive conclusion.

    If the issue continues, it might be helpful to open a support request with Microsoft Cloud Storage Partner Program so they can review it from the service side and provide deeper diagnostics.

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.