Windows desktop white-screen hang: CrBrowserMain CPU-bound in UI Automation text attribute callback #49648

Codex desktop version

Windows package: OpenAI.Codex_26.928.2636.0_x64 (verified from the running executable's package path; not read from the About dialog).
Executable: ChatGPT.exe.
Bundled chrome.dll: 154.0.8037.57.

Platform

Microsoft Windows Server 2025 Datacenter, x64, OS version 10.0.26100, build 26100.
Loaded Microsoft components:

• tiptsf.dll: 10.0.26100.32230
• UIAutomationCore.dll: file version 7.2.26100.32522

Subscription: not collected.

Problem

The entire desktop window turns white and Windows displays "Not Responding". This is a window hang, not merely a chat waiting for a model response.

During live inspection the window-owning main process reported Responding=False. Windows Error Reporting logged five AppHangTransient events for ChatGPT.exe on 2026-09-30 at 22:12:20, 22:13:48, 22:14:57, 22:23:16, and 22:36:04 (UTC+08:00). The events do not establish that every hang has the same cause.

Reproduction

The user reported the symptom while it was occurring, allowing collection during the hang. The initiating interaction and a deterministic minimal reproduction are not yet known. No claim is made that typing, a particular IME, Computer Use, or a specific conversation caused it.

Expected behavior

The desktop window should remain responsive and repaint normally while processing focus/accessibility events and ongoing conversations.

Repeated native dump evidence

A full main-process dump was collected at approximately 22:41:21 UTC+08:00. Two additional thread/context snapshots of the same process and same CrBrowserMain thread were collected at approximately 22:47:24 and 22:47:27. The process identity and creation time match across these captures.

The two later samples are approximately 3.46 seconds apart. The main thread's user-mode CPU time in MINIDUMP_THREAD_INFO increased from 731.765625 to 734.9375 seconds: 3.171875 CPU seconds during that interval, close to one logical CPU being continuously occupied.

Both later snapshots show the same synchronous call path, and the earlier full dump shows the same class of path. Microsoft PDB symbols were loaded for the Windows components:

user32!PeekMessageW
  -> user32!DispatchHookW
  -> tiptsf!TabletMsgWndProc
  -> tiptsf!CImmersiveFocusTracker::HandleAutomationEvent
  -> tiptsf!CImmersiveFocusTracker::_HandleAutomationEvent
  -> tiptsf!CAutomationProperties::CAutomationProperties
  -> tiptsf!CAutomationProperties::_SetReadOnly
  -> uiautomationcore!CTextRange::GetAttributeValue
  -> uiautomationcore!InProcClientAPIStub::InvokeInProcAPI
  -> uiautomationcore!ComInvoker::CallTarget
  -> uiautomationcore!InProcClientAPIStub::TextRange_GetAttributeValue
  -> uiautomationcore!ProviderCallouts::GetAttributeValue
  -> chrome.dll internal provider code

tiptsf.dll identifies itself as "Touch Keyboard and Handwriting Panel Text Services Framework". This does not prove that a touch keyboard was in use or that an IME is at fault.

The main thread's instruction pointers differ between samples, with frames remaining in the same Chromium call region. The samples support CPU-bound work in the text-attribute provider path and consequent UI starvation, rather than a simple sleeping wait. They do not yet distinguish a very large traversal, repeated computation, or an infinite loop.

Matching private symbols for OpenAI's chrome.dll were not available. Nearest exported-symbol labels such as sqlite3_dbdata_init+large_offset are therefore not evidence of SQLite involvement.

Other observations and limits

• Seven renderer thread snapshots and a full dump of the renderer with the largest working set were saved locally. That renderer's main thread was sampled in WaitForSingleObjectEx; whether that was an ordinary event-loop wait or a relevant dependency is unresolved.
• Logs also contained Received item/started for unknown conversation, Received item/completed for unknown conversation, Conversation state not found, and ResizeObserver loop completed with undelivered notifications. These have not been causally linked to the UI Automation path.
• No GPU dump was collected; this report does not exclude GPU or renderer issues.
• No controlled A/B reproduction, verified workaround, or fix has been established.
• No client data, session cache, input services, or GPU settings were modified as part of diagnosis.

Diagnostic artifacts and privacy

Main-process full dump, repeated thread snapshots, renderer captures, WER event records, debugger output, and SHA-256 manifests have been retained locally. Raw dumps and full logs are not attached because they can contain conversation text or credentials. The sanitized native call chain and measured CPU delta above are the evidence supplied publicly.

Please investigate the Chromium UI Automation text-range attribute provider called synchronously from Windows input focus tracking. If a private diagnostic channel or matching symbols are available, those would help identify the exact Chromium function without publishing memory dumps.