[Windows][Desktop][26.803.10989.0] Repeated chrome.dll invalid-pointer read during window teardown

What version of the Codex App are you using (From "About Codex" dialog)?

Microsoft Store package OpenAI.Codex 26.803.10989.0 (x64)

Bundled Chromium/product version: 151.0.7922.76

The installed package was compared with OpenAI's current signed x64 MSIX and the package versions matched exactly.

What platform is your computer?

Windows 11, Microsoft Windows NT 10.0.26200, x64

What issue are you seeing?

Codex Desktop repeatedly exits during normal use. ProcDump captured two new first-chance full dumps from the main Chromium/browser process on 2026-08-14. WinDbg reports the identical native crash signature in both captures:

Field	Value
Host process	ChatGPT.exe
Crashpad process type	browser (main process)
Exception	0xC0000005 access violation
Access type	Invalid pointer read
Failure bucket	INVALID_POINTER_READ_c0000005_chrome.dll!Unknown
Failure hash	{5cd13162-58f6-4190-dced-e6b658b0f99b}
Faulting offset	chrome.dll+0xF3CA304
Faulting instruction	mov rax,qword ptr [rax+38h]
Faulting register	RAX=EFEFEFEFEFEFEF
Attempted read	FFFFFFFFFFFFFFFF

The exception is on the main Chromium UI thread. The surviving stack passes through Chromium/V8/Node frames and Windows window destruction:

user32!_fnNCDESTROY
win32u!NtUserDestroyWindow
chrome.dll frames
chrome!ChromeMain
ChatGPT.exe

The EFEFEFEFEFEFEFEF register pattern and teardown stack are consistent with freed/poisoned state being dereferenced during window destruction (for example, a use-after-free or stale callback). This is a characterization, not a source-level root-cause claim.

Public Chromium symbols are insufficient here. In particular, the exported chrome!sqlite3_dbdata_init+... label shown by WinDbg is offset-based and should not be interpreted as evidence that SQLite caused the failure.

What steps can reproduce the bug?

There is not yet a deterministic click sequence:

1. Launch and sign in to Codex Desktop.
2. Use the desktop app normally for development tasks.
3. The main process eventually exits without a useful in-app error.

Two first-chance captures from the same day reproduced the exact signature:

Capture	Local time	Process uptime
1	2026-08-14 08:04:17 EDT	1:04:24
2	2026-08-14 09:42:38 EDT	0:33:43

The second identical crash after only 33 minutes, plus recurrence after reboot, weighs strongly against cumulative machine-memory exhaustion. The stack suggests a window or Browser-surface lifecycle path may be involved, but I have not isolated a specific triggering UI action and do not want to overstate that correlation.

What is the expected behavior?

Codex Desktop's browser/main process should remain stable. Window, Browser-surface, or webview teardown must not dereference freed state or terminate the entire desktop host.

Additional diagnostic information

• The exception was captured before process teardown with signature-verified ProcDump 12.01.
• WinDbg 10.0.29617.1000 analyzed both full-memory user dumps.
• Both dumps have the same bucket, failure hash, module offset, invalid register value, instruction, and window-destruction stack.
• No non-system third-party DLL path was loaded into the crashing process.
• Earlier event correlation found no matching Windows out-of-memory/resource-exhaustion, GPU reset, display-driver, WHEA, or ordinary Application Error event.
• Crashpad sidecars identify these exits as {"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}.
• Rebooting did not prevent recurrence.
• Reinstalling the same current MSIX would not change the affected binaries; the installed and current official signed package versions are identical.

Related issues

• #32334 — same failure hash on an older Codex/Chromium build, but a different fault offset and a Browser-sidebar creation trigger.
• #34923 — Windows main-process chrome.dll access violation on an older build and different offsets.
• #30178 — Windows Browser lifecycle/navigation chrome.dll access violation on an older build and different offset.
• #25358 — generic INVALID_POINTER_READ in chrome.dll.

I did not find an existing public report for this exact combination of app version 26.803.10989.0, Chromium 151.0.7922.76, fault offset 0xF3CA304, and window-destruction stack.

Private artifacts

Two full dumps are preserved locally. They are intentionally not attached because full process memory may contain conversations, credentials, repository contents, and other private data. I can provide a dump if an OpenAI maintainer supplies an approved private transfer method and specifies what is needed.

Suggested engineering investigation

Please symbolicate chrome.dll+0xF3CA304 for Chromium/product build 151.0.7922.76, correlate failure hash {5cd13162-58f6-4190-dced-e6b658b0f99b}, and inspect Chromium/Electron main-window or Browser-surface destruction for a stale callback/use-after-free path.

Start by symbolating chrome.dll+0xF3CA304 for Chromium 151.0.7922.76 and comparing the two full dumps' identical failure hash and window-destruction stack. Review the related lifecycle reports, especially #32334, then inspect the Chromium/Electron main-window or Browser-surface teardown path; done means identifying and addressing the stale callback or use-after-free path causing the crash.