Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#5,489 5 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Área
desktop, operating-systems

Línea de trabajo

Comienza ejecutando el programa mínimo #lang racket/gui de ./repro.rkt en Windows 11 26H1 build 28000.1643 y, después, revisa las evidencias de ProcDump y WinDbg del issue. Compara la ruta de inicio de la GUI y de despacho de mensajes con el fallo reportado de CoreMessaging.dll; se considera terminado cuando se haya identificado el límite que lo desencadena y se haya documentado o validado una solución reproducible o una limitación específica de la plataforma.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

platform:windows

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.

Lenguaje dominante
Racket
Estrellas
5.2k
Forks
705
Merge medio
1 d 19 h
PR fusionados (30 d)
15

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de racket/racket

Todos los issues de racket/racket

Issues similares

Más issues de Desktop Dev

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.