Windows 11 26H1: minimal #lang racket/gui program crashes with first-chance AV in CoreMessaging.dll #5489

Racket version: 9.1 [cs] x64
OS: Windows 11 x64, version 26H1, build 28000.1643

Minimal repro

#lang racket/gui
(define f (new frame% [label "test"] [width 300] [height 200]))
(send f show #t)

Observed behavior

GRacket.exe and Racket.exe exit immediately when running this program on the above Windows build.

Event Viewer reports a crash in CoreMessaging.dll. I have seen both 0xc0000005 and 0xc000041d at the process level, but the earliest observed fault during debugging is a first-chance access violation.

I captured both a first-chance dump with ProcDump and a live WinDbg session with full page heap enabled for GRacket.exe.

• ProcDump command used: procdump -ma -e 1 -x ./dumps GRacket.exe ./repro.rkt
• Live debugging setup:
  • full page heap enabled for GRacket.exe
  • WinDbg attached from process start
  • sxe av
  • crash reproduced immediately

What seems established from the dump/debug session:

The earliest observed fault is a first-chance access violation in CoreMessaging.dll, not a later secondary crash after obvious earlier corruption.

The faulting instruction is:

CoreMessaging!Microsoft::CoreUI::Messaging::MessageSession::Callback_DeliverMessage+0x263
movups xmm0, xmmword ptr [rax]

At the fault:

rax = 0
r8 points to readable memory
rcx = [r8+0x90] is readable

Relevant stack top:

CoreMessaging!Microsoft::CoreUI::Messaging::MessageSession::Callback_DeliverMessage
CoreMessaging!Microsoft::CoreUI::Messaging::MessageSession::Callback_DeliverMessageBatch
CoreMessaging!Microsoft::CoreUI::Messaging::CrossProcessReceivePort$AlpcReceiveSource::Callback_ProcessBuffer
CoreMessaging!Microsoft::CoreUI::Messaging::AlpcServerThunk::Callback_ProcessAsynchronousBuffer
CoreMessaging!AlpcConnection::HandleSubsequentBufferInBatch
CoreMessaging!AlpcConnection::Callback_HandleRequest
CoreMessaging!AlpcConnection::Callback_HandleReceivedBuffer
CoreMessaging!AlpcConnection::Callback_ProcessIncoming
CoreMessaging!Microsoft::CoreUI::Messaging::CrossProcessReceivePort$AlpcReceiveSource::OnReceive
CoreMessaging!Microsoft::CoreUI::Dispatch::OffThreadReceiver::Callback_OnDispatch
CoreMessaging!Microsoft::CoreUI::Dispatch::Dispatcher::Callback_DispatchLoop
CoreMessaging!Microsoft::CoreUI::Dispatch::EventLoop::Callback_RunCoreLoop
CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter::DrainCoreMessagingQueue
CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter::OnUserDispatch
CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter::DoWork
CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter::WindowProc
user32!UserCallWinProcCheckWow
user32!DispatchClientMessage
user32!_fnDWORD
ntdll!KiUserCallbackDispatcherContinue
win32u!NtUserPeekMessage
user32!PeekMessageW

Disassembly around the fault:

movq    r8,xmm6
mov     rcx,qword ptr [r8+90h]
psrldq  xmm6,8
movq    rax,xmm6
movups  xmm0,xmmword ptr [rax]

This seems to show that CoreMessaging expects a non-null pointer-sized value extracted from xmm6, but the extracted value is null and is dereferenced immediately.

I also reproduced the same first-chance fault with full page heap enabled. In this configuration, the failure still occurs at the same CoreMessaging instruction, and I did not see the fault move earlier to a more conventional user-mode heap-corruption site.

Because of that, ordinary user-mode heap corruption seems less likely, but I cannot tell from the dump alone whether the root cause is a Windows 26H1 CoreMessaging/TextInput regression, or something in the GUI startup path that triggers an unexpected state which this Windows build does not handle safely.

Modules loaded around the relevant path include:

IMM32.dll
MSCTF.dll
textinputframework.dll
CoreMessaging.dll
CoreUIComponents.dll

Representative first-chance exception record:

ExceptionAddress: CoreMessaging!Microsoft::CoreUI::Messaging::MessageSession::Callback_DeliverMessage+0x263
ExceptionCode: c0000005
Attempt to read from address 0000000000000000

Representative register state at the fault:

rax=0000000000000000
r8=0000000000771bb0
rip=CoreMessaging!Microsoft::CoreUI::Messaging::MessageSession::Callback_DeliverMessage+0x263

Representative faulting instruction:

movups xmm0, xmmword ptr [rax]

This looks like a stable first-chance null dereference in CoreMessaging.dll during GUI startup / message dispatch on Windows 11 26H1 build 28000.1643.

I am not yet claiming that this definitively proves a Windows-only bug. What I think the current evidence supports is narrower: a minimal racket/gui program reliably reaches a CoreMessaging code path that dereferences a null pointer-sized value on this Windows build.