OneDrive Personal: XML_E_INVALID_UNICODE in EnumChanges — crashes on one PC, sync stuck on another

I am experiencing a OneDrive Personal synchronization problem with the same Microsoft account on two computers. I have an active Microsoft 365 Family subscription.

Symptoms

On the Windows 11 desktop, OneDrive initially displays folders and online-only files, and can download and open individual files. After a few minutes, it crashes during subsequent synchronization activity. Opening an online-only file after the crash produces error 0x80070194 (“The cloud file provider exited unexpectedly”).

On the laptop, OneDrive remains on “Looking for changes”. Changes do not propagate in either direction:

• A folder deleted through the website remains visible locally.

New folders created through the website do not appear locally.

A new folder created locally does not appear on the website.

Both computers are using OneDrive version 26.178.0913.0006 according to the diagnostic records.

An important comparison: a different Microsoft account belonging to another Windows user synchronizes normally on the same desktop.

Troubleshooting already performed

The desktop problem persists after:

Reinstalling OneDrive and configuring a fresh synchronization folder, without enabling standard-folder backup.

Connecting the affected Microsoft account from a newly created Windows user profile.

Performing a clean boot.

Uninstalling Dropbox and restarting. Dropbox and Start11 modules are absent from the latest crash report.

Switching the desktop connection from Ethernet to Wi-Fi.

Diagnostic findings

A full desktop crash dump shows:

Exception: 0x80000003, an internal assertion.

Function: StorageServiceApi::EnumChanges.

Message: “FAILED: Could not deserialize findChanges xml”.

Assertion GUID: 153e8d4d-f950-4e52-b1be-64eddd4e4dc9.

Client source reference: StorageServiceApi.cpp, line 1152.

Laptop SyncEngine logs contain two sequences on October 9, 2026, around 22:45:30 and 22:45:32 UTC:

EnumChanges receives a response.

LoadXML reports “Invalid Unicode character value” (the original localized message is “Valore del carattere Unicode non valido”).

Error code: 0xC00CE51F, XML_E_INVALID_UNICODE.

The sequence includes StorageSerializer::DeserializeFindChangesXML and StorageServiceApi::EnumChanges.

Non-fatal diagnostic GUID: 5f976877-9262-4790-8124-0fce87375787.

After the first failure, the logs show RestartChangeEnumerationInline and UnexpectedFailure. After the second, they show: PossiblySoftLockSyncEngine_RedoNeededCantRefreshNow UnexpectedFailure FindChangesRedoNeeded

The same pagination cursors recur around both failures. However, no filename, offending character, or response XML body has been identified. We do not assume the cursor IDs identify a corrupt item.

Questions

Is this a known OneDrive Personal issue involving invalid Unicode in the findChanges response or a client parser defect?

Is there a supported, read-only method to identify the offending item or metadata, or obtain more specific parser diagnostics?

Can Microsoft correlate the failed requests using their SPRequestGuid/SPLogId values? I have those identifiers and can supply them through a private support channel.

How can this be escalated to OneDrive engineering? The support website and Windows Get Help app currently redirect me to self-help articles or this community.

Logs and a full crash dump are available for secure private submission. I am avoiding speculative cloud deletions, bulk renaming, or further resets because no responsible item has been identified and preserving the files is essential.I am experiencing a OneDrive Personal synchronization problem with the same Microsoft account on two computers. I have an active Microsoft 365 Family subscription.

Symptoms

On the Windows 11 desktop, OneDrive initially displays folders and online-only files, and can download and open individual files. After a few minutes, it crashes during subsequent synchronization activity. Opening an online-only file after the crash produces error 0x80070194 (“The cloud file provider exited unexpectedly”).

On the laptop, OneDrive remains on “Looking for changes”. Changes do not propagate in either direction:

A folder deleted through the website remains visible locally.

New folders created through the website do not appear locally.

A new folder created locally does not appear on the website.

Both computers are using OneDrive version 26.178.0913.0006 according to the diagnostic records.

An important comparison: a different Microsoft account belonging to another Windows user synchronizes normally on the same desktop.

Troubleshooting already performed

The desktop problem persists after:

Reinstalling OneDrive and configuring a fresh synchronization folder, without enabling standard-folder backup.

Connecting the affected Microsoft account from a newly created Windows user profile.

Performing a clean boot.

Uninstalling Dropbox and restarting. Dropbox and Start11 modules are absent from the latest crash report.

Switching the desktop connection from Ethernet to Wi-Fi.

Diagnostic findings

A full desktop crash dump shows:

Exception: 0x80000003, an internal assertion.

Function: StorageServiceApi::EnumChanges.

Message: “FAILED: Could not deserialize findChanges xml”.

Assertion GUID: 153e8d4d-f950-4e52-b1be-64eddd4e4dc9.

Client source reference: StorageServiceApi.cpp, line 1152.

Laptop SyncEngine logs contain two sequences on October 9, 2026, around 22:45:30 and 22:45:32 UTC:

EnumChanges receives a response.

LoadXML reports “Invalid Unicode character value” (the original localized message is “Valore del carattere Unicode non valido”).

Error code: 0xC00CE51F, XML_E_INVALID_UNICODE.

The sequence includes StorageSerializer::DeserializeFindChangesXML and StorageServiceApi::EnumChanges.

Non-fatal diagnostic GUID: 5f976877-9262-4790-8124-0fce87375787.

After the first failure, the logs show RestartChangeEnumerationInline and UnexpectedFailure. After the second, they show:
PossiblySoftLockSyncEngine_RedoNeededCantRefreshNow
UnexpectedFailure
FindChangesRedoNeeded

The same pagination cursors recur around both failures. However, no filename, offending character, or response XML body has been identified. We do not assume the cursor IDs identify a corrupt item.

Questions

Is this a known OneDrive Personal issue involving invalid Unicode in the findChanges response or a client parser defect?

Is there a supported, read-only method to identify the offending item or metadata, or obtain more specific parser diagnostics?

Can Microsoft correlate the failed requests using their SPRequestGuid/SPLogId values? I have those identifiers and can supply them through a private support channel.

How can this be escalated to OneDrive engineering? The support website and Windows Get Help app currently redirect me to self-help articles or this community.

Logs and a full crash dump are available for secure private submission. I am avoiding speculative cloud deletions, bulk renaming, or further resets because no responsible item has been identified and preserving the files is essential.