›_ Codex Issues
Codex Issues / #33488

[Bug] Windows Codex Desktop intermittently freezes with desktop-notifications DLL failure (0xc06d007f)

Open 💬 4 comments Opened Jul 16, 2026 by ginishuh
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop intermittently becomes completely unresponsive on Windows 11. The window can reopen in the same frozen state after being closed and relaunched. The same launch also records a Windows desktop-notification DLL initialization failure, repeated notification-service initialization, and repeated Windows Application Error events with exception code 0xc06d007f.

The problem survived Windows app Repair, Reset, uninstall, and reinstall. The currently installed package is the same build after reinstall.

Environment

  • Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
  • Executable: ChatGPT.exe
  • Windows 11 25H2, build 26200.8875, x64
  • Main workspaces are hosted in WSL, but WSL remained responsive during the freezes
  • Codex app-server connection to WSL succeeded and reported version 0.144.4

Observed behavior

  1. Start Codex Desktop and use it normally.
  2. The entire Codex UI intermittently stops accepting input.
  3. Closing only the window and launching Codex again can reopen the window in the same unresponsive state.
  4. Windows may still report the main process as Responding=True, even while the UI accepts no input and process CPU remains flat.
  5. Windows Application log repeatedly records failures for packaged ChatGPT.exe with:
  • Exception code: 0xc06d007f
  • Repeated exception offset: 0x00007ff8c5361ada
  • Repeated WER bucket/hash: fe840c3ed30ba850ddeac7488b0e9f2e

The Codex Desktop log records:

[desktop-notifications][unhandled-rejection] Error: A dynamic link library (DLL) initialization routine failed.

On one launch that remained usable for more than an hour, the same log contained:

[desktop-notifications] service starting  # 43 occurrences
[desktop-notifications][unhandled-rejection] Error: A dynamic link library (DLL) initialization routine failed.  # 1 occurrence
ResizeObserver loop completed with undelivered notifications  # 0 occurrences

This indicates that the DLL error does not always immediately kill the UI, but it is present in the same affected launch family. Earlier affected launches sometimes contained many ResizeObserver warnings, while other affected launches contained none, so ResizeObserver does not appear to be the root cause.

Troubleshooting already performed

  • Windows Settings > Apps > Codex > Repair
  • Windows Settings > Apps > Codex > Reset
  • Uninstalled and reinstalled Codex Desktop
  • Temporarily disabled the Windows notification registry entry for Codex (Enabled=0); the freeze/DLL failure still reproduced
  • Restored the notification setting afterward
  • Removed a custom UI font-size setting; the issue still reproduced
  • Verified that WSL boots, systemctl reports running, and memory is available
  • Verified that the OpenAI service and mobile app were operational

Windows integrity checks also reported a repairable component store and SFC integrity violations. The specific SFC files reported were Bluetooth drivers (BthA2dp.sys, BthHfEnum.sys, and bthmodem.sys), not an obvious WinRT/notification DLL. DISM /RestoreHealth and a full sfc /scannow repair are being completed separately, so I am not claiming the SFC findings are unrelated until post-reboot verification is complete.

Expected behavior

Codex Desktop should remain interactive, initialize its desktop-notification service once, and handle a notification DLL initialization failure without freezing or repeatedly crashing the packaged application.

Related issues

  • #16374 - Windows Codex/Windows shell intermittent freezes
  • #25197 - Windows desktop notification activation problem and repeated service starting logs
  • #20544 - Codex Desktop UI freeze on Windows
  • #13019 - Desktop notification configuration behavior in app-server mode

This report adds a distinct local signature: desktop-notifications DLL initialization failure together with Windows exception 0xc06d007f on package 26.707.9981.0.

I can provide sanitized Codex Desktop logs and matching Windows Event Viewer entries if maintainers need them. No local SQLite databases or private conversation data will be uploaded.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #33483
  • #33466
  • #33375
  • #33460
  • #33438

Powered by Codex Action

ginishuh · 1 month ago

Post-repair clean-boot reproduction:

  1. DISM.exe /Online /Cleanup-Image /CheckHealth after reboot reported: no component store corruption detected.
  2. sfc.exe /verifyonly reported: Windows Resource Protection did not find any integrity violations.
  3. Codex Desktop was then launched for the first time after that clean verification.

Timeline (local time, 2026-07-16):

  • 13:15:53 - main packaged ChatGPT.exe process PID 20368 started.
  • 13:16:11 - Windows Application Error 1000 recorded for PID 20368.
  • 13:16:34 - Windows Application Error 1000 recorded again for the same PID.
  • The main process was observed as Responding=False shortly after launch. It later returned to Responding=True, but WER had already recorded two MoAppCrash reports.

Both reports have:

Package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
Exception: 0xc06d007f
Faulting module: unknown
Fault offset: 0x00007ffdb7de1ada
WER event: MoAppCrash
WER bucket/hash: fe840c3ed30ba850ddeac7488b0e9f2e

The pre-repair failures had the same exception and the same WER bucket/hash. Their absolute fault address differed because of process/module relocation, but also ended in the same 0x1ada offset pattern.

The new Codex Desktop log files for this launch were created but remained 0 bytes through the crash window, so this failure can occur before normal desktop logging is flushed.

This clean post-reboot reproduction rules out the previously detected Windows component-store/SFC corruption as the cause of this Codex failure.

Racterrus · 1 month ago

The same issue is present in ChatGPT Desktop build 26.707.12708.0 as well.

15230745073 · 1 month ago

Additional cross-machine forensics (2 independent machines): server-side config refresh appears to be the trigger; WER full-dump collection is the freeze mechanism

We hit the same signature on two independent Windows 11 machines (build 26200.8875, zh-CN) on 2026-07-16 and ran a read-only forensic comparison. Sharing what may help narrow this down.

Same fingerprint as this issue

  • All Application Error events: exception 0xc06d007f (delay-load PROC_NOT_FOUND family), faulting module unknown, WER hash bucket fe840c3ed30ba850ddeac7488b0e9f2e — identical to the OP; fault bucket 2155754486034767662.
  • Desktop log: [desktop-notifications][unhandled-rejection] Error: A dynamic link library (DLL) initialization routine failed.

Trigger correlates with server-side config refresh, not local state

  • Machine A (MSIX 26.707.9981.0): statsig-refresh "values updated" at 08:34:23.931 local → first 0xc06d007f event at 08:34:25 (+1.1 s), with no user interaction in between; median interval between subsequent events ≈ 9.3 s (153 events by 15:13).
  • Machine B (same MSIX, installed 07-14): ran all day 07-15 with zero events; first event 07-16 09:00:12 local, at the first UI activity following that morning's refresh cycle (~40 events/hour under active use).
  • Both machines first crashed on 07-16 morning within ~25 minutes of each other → consistent with a staged server-side rollout. This would also explain why Repair / Reset / reinstall did not help (as the OP observed): the trigger is not local install state.

Why the whole UI freezes (and input/IME lags while the window has focus)
Each exception triggers WER MoAppCrash collection: memory.hdmp full heap dump + WPR/ETL snapshots (visible in the Event 1001 attachment list). Collection suspends all process threads. Under active use we measured the main process reading 11.7 GB in ~20 minutes while events fired every ~2 minutes — the app spends much of its time frozen inside dump collection, which also saturates the disk.
Stopgap that restored usability immediately on machine B (admin, reversible): Disable-WindowsErrorReporting — the underlying exceptions continue but cost ~nothing; re-enable after a fix lands.

Ruled out locally

  • WinAppRuntime 1.8: on machine A it was installed 3h14m after the first crash → not the cause. (It looked causal on machine B due to coincidental timing — installed 50 min before first crash — and removing it did not stop the exceptions; the cross-machine comparison settled it.)
  • Windows KB5101650 (→26200.8875): crashes preceded it and behavior was unchanged across it and 3 reboots.
  • config.toml plugin flags: disabling browser@openai-bundled / computer-use@openai-bundled / chrome@openai-bundled had no effect — the failing component appears to be core / server-flag driven.
  • Disk hardware: NVMe, HealthStatus Healthy on both machines.

Build 26.707.12708 (auto-rolled out 07-16 ~15:22 CST) reduces but does not fix
After the silent update + app restart on machine B, the event rate dropped ~6x (4 events in 36 min vs ~40/hour before), but the same desktop-notifications DLL init failure still logs during startup, and events still fire mid-turn (during reasoning streaming) and around browser-sidebar syncs — so the broken native path is still present in 26.707.12708.

Happy to provide sanitized Windows event-log extracts and desktop-log excerpts on request (no SQLite databases or conversation data).