[Problem/Bug]: WebView2 Local Storage LevelDB intermittently loses persisted data after checksum corruption

[cozyboy]

What happened?

Summary

A Tauri 2 desktop application on Windows 11 uses localStorage to persist an authentication token. After working normally for more than a year, the application started requiring the password again on every launch for approximately two days. The server and network were not involved. The symptom later disappeared without an application change.

Inspection of the WebView2 user data folder showed Local Storage LevelDB recovery errors:

Recovering log #3
000003.log: dropping 4731 bytes; Corruption: checksum mismatch
Reusing old log

Seventeen seconds later, another launch reported:

Recovering log #3
000003.log: dropping 5029 bytes; Corruption: checksum mismatch
Reusing old log

The localStorage token key is present again and the application currently starts normally, but the physical LevelDB log still contains the corrupted region and WebView2 recovered the same log on each observed startup.

Timeline

• 2026-08-11: WebView2 Runtime 151.0.4129.78 installed automatically.
• 2026-08-14: WebView2 Runtime 151.0.4129.86 installed automatically.
• Around 2026-08-15 to 2026-08-17: repeated login prompt observed on every application launch.
• Current runtime: 151.0.4129.86.

Environment and checks

• Windows 11 x64, build 10.0.26200.
• Tauri 2.10.3, wry 0.54.4, webview2-com 0.38.2.
• The UDF is under %LOCALAPPDATA%\<app-identifier>\EBWebView and has existed since 2025; it was not recreated.
• The application identifier and production origin did not change.
• The UDF is writable and no WEBVIEW2_* environment or policy overrides are configured.
• The system volume reports healthy, with no recent NTFS or disk errors.
• Restarting the remote server had no effect.

Could Runtime 151 be producing or exposing Local Storage LevelDB tail corruption during shutdown/startup? Is repeatedly ignoring and reusing the same corrupted log expected, or should WebView2 compact/rebuild it after recovery?

No raw LevelDB files are attached because they contain authentication data.

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

151.0.4129.86

SDK Version

webview2-com 0.38.2 (Tauri 2.10.3 / wry 0.54.4)

Framework

Other

Operating System

Windows 11

OS Version

10.0.26200

Repro steps

This issue is intermittent and is not currently reproducible on demand.

1. Launch the Tauri application and sign in. The authentication token is written with localStorage.setItem(...).
2. Exit and relaunch the application.
3. During the incident, the token was unavailable after every relaunch and the application requested the password again.
4. Inspect %LOCALAPPDATA%\<app-identifier>\EBWebView\Default\Local Storage\leveldb\LOG.
5. The log reports recovery of 000003.log followed by Corruption: checksum mismatch and thousands of dropped bytes.

Expected: Local Storage data written during a successful login remains readable after clean application restarts.

Actual: During the incident, the persisted token was unavailable on every restart. Later launches recovered enough data for the token to become readable again, while the checksum-corruption entry remained in the LevelDB recovery log.

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

Regression in newer Runtime

Last working version (if regression)

Runtime version before 151.0.4129.78 (exact previous version not captured)

[vipulgupta11]

Hi Eric (@cozyboy) We'll be needing a repro and logs in order to investigate it. Can you please help with it?

[ambikakunnath]

Thank you for the detailed report. The LevelDB messages show that Local Storage encountered a checksum failure and recovered by ignoring damaged log data, but they do not yet establish whether Runtime 151 caused the original corruption.

To narrow this down, could you please provide:

1. Whether the first affected launch followed a normal application shutdown, a forced termination, an OS restart/update, or a crash, and approximately how long elapsed between localStorage.setItem() and process exit.
2. A minimal repro that writes non-sensitive test data to DB, including the launch/close loop needed to reproduce the issue.
3. ETW trace https://github.com/MicrosoftEdge/WebView2Feedback/blob/main/diagnostics/etw.md of the repro scenario

[cozyboy]

Thank you. I now have a deterministic normal-exit reproduction, with one important qualification: it reproduces on isolated copies of the already-corrupted production UDF, but not on a fresh UDF.

Original incident context

I can no longer reliably determine whether the launch immediately before the first affected launch ended with a normal shutdown, forced termination, OS update/restart, or crash. The application is normally closed through the Tauri shutdown path, and I am not aware of a crash at that boundary. The backend process had been running for more than a month; restarting it did not resolve the repeated-login behavior.

Minimal reproduction

I created a standalone English-only Tauri 2 application pinned to the affected dependency chain:

• Tauri 2.10.3
• tauri-runtime / tauri-runtime-wry 2.10.1
• wry 0.54.4
• webview2-com 0.38.2

Each cycle uses two independent processes:

1. The writer stores a deterministic 4 KiB JSON record with localStorage.setItem(), immediately reads it back, validates its contents and checksum, writes an external result record with sync_all, and requests a normal exit through AppHandle::exit().
2. A new verifier process regenerates the expected record and reads the same localStorage key.

Using Runtime 151.0.4129.93 and three independently copied snapshots of the affected UDF:

• 0 ms configured post-write delay, snapshot 1: 4 failures in 5 normal-exit cycles.
• 0 ms configured post-write delay, snapshot 2: 4 failures in 5 normal-exit cycles.
• 1000 ms configured post-write delay, snapshot 3: 4 failures in 5 normal-exit cycles.

In every run, all five writer processes successfully read and validated the value immediately after setItem(). Verifier processes 1 through 4 then reported that the key was completely missing; verifier 5 passed. Normal exit is requested after the configured delay and the synced result write, with an additional 50 ms host-side exit delay.

The corrected runner captured 25 LevelDB recovery error lines in each recorded run. The dropped region grew from 8,655 bytes to 24,586 bytes, followed by:

Corruption: checksum mismatch
Corruption: missing start of fragmented record(2)

This also explains why the original symptom could disappear temporarily after repeated launches: once appended records crossed the damaged/fragment boundary, a later record became readable again.

Controls

• Runtime 151.0.4129.86, fresh isolated UDF, 200 normal-exit cycles: 0 cross-process failures.
• Runtime 151.0.4129.93, fresh isolated UDF, 100 + 200 normal-exit cycles and a 50-cycle stress run: 0 cross-process failures.
• Forced process-tree termination caused stale-value failures on both .86 and .93 (19/20), but did not produce the checksum-corruption evidence seen in the affected UDF.

I am attaching one ZIP containing the buildable minimal project, the complete affected Default/Local Storage/leveldb snapshot, and path-sanitized results for the 0 ms and 1000 ms normal-exit runs. The LevelDB snapshot contains historical application token records; all of those tokens were revoked before this public upload.

I have not included ETW yet because the current reproduction session is not elevated, while WPR capture requires elevation. I can capture an ETW trace from this normal-exit reproduction next if that remains useful now that the corrupted UDF makes the failure deterministic.

webview2feedback-5674-repro-and-corrupted-leveldb.zip