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

WASAPI: cached IMMDeviceEnumerator is created in one thread's STA and used after that thread exits

Abierto
  • ¿Algo no está bien?
#1,302 18 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
rust
Área
backend

Línea de trabajo

Start with the ENUMERATOR initialization in src/host/wasapi/device.rs and COM lifetime handling in src/host/com.rs; then trace how default_device_monitor() stores the enumerator and how DefaultDeviceMonitor::drop unregisters its callback. Reproduce the failure with Windows tests run using --test-threads=1, then determine a lifetime strategy that covers both paths. Done means device enumeration and monitor cleanup remain safe after the creating thread exits.

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

Descripción

correctness host - wasapi platform - windows

Calling cpal's safe API on Windows can crash the process with STATUS_ACCESS_VIOLATION rather than returning an error.

Symptom

In a test binary run with --test-threads=1, a test that enumerates devices passes when run alone, but the process faults when other tests run in the same binary. The fault lands on an arbitrary later test and moves between runs. Two stacks from cdb, both faulting at +0x19d — the vtable read:

INVALID_POINTER_READ_c0000005
  windows::Win32::Media::Audio::IMMDeviceEnumerator::GetDefaultAudioEndpoint
  cpal::host::wasapi::device::default_device
  cpal::host::wasapi::device::default_input_device
  cpal::traits::HostTrait::default_input_device

INVALID_POINTER_READ_c0000005
  windows::Win32::Media::Audio::IMMDeviceEnumerator::EnumAudioEndpoints
  cpal::host::wasapi::device::Devices::new
  cpal::host::wasapi::impl$1::devices
  cpal::traits::HostTrait::input_devices

Observed on windows-latest GitHub Actions runners, cpal 0.17.3, and the same code is present on main.

Diagnosis

ENUMERATOR in src/host/wasapi/device.rs is a process-wide OnceLock<Enumerator>, created on whichever thread calls first, with unsafe impl Send + Sync. COM is initialised as COINIT_APARTMENTTHREADED through a thread-local in src/host/com.rs whose Drop calls CoUninitialize.

An STA belongs to the thread that created it. So once the first thread to touch cpal exits, the cached interface pointer is dangling, and every later caller reads a dead vtable. The comment at the initialisation site states the assumption that does not hold:

// COM initialization is thread local, but we only need to have COM initialized in the
// thread we create the objects in
com::com_initialized();

This is most visible where audio work happens on short-lived threads: whichever one touches cpal first owns the enumerator, and its exit breaks device access for the rest of the process.

Ruled out

  • CoCreateInstance failing is not a fit — that would panic at the .unwrap(), not fault at a vtable read.
  • Absent audio endpoints is not a fit either — that surfaces as an HRESULT from GetDefaultAudioEndpoint / EnumAudioEndpoints, not an invalid dereference.

Two affected paths

Making ENUMERATOR a thread_local fixes enumeration, but is not sufficient. default_device_monitor() clones the enumerator into DefaultDeviceMonitor, which is unsafe impl Send + Sync and stored in Stream. Its Drop calls UnregisterEndpointNotificationCallback, and carries this comment:

// Ensure COM is initialised on this thread before making COM calls. Drop can run on
// any thread (e.g. the audio run thread), which may not have called CoInitialize.

Initialising COM on the dropping thread does not help if the apartment that owns the object has gone. That path shares an apartment-bound pointer regardless of what the enumeration path does.

Possibly related earlier reports

#517, #539 and #596 all report this exit code and were closed as ASIO issues. #517 in particular describes "enumerate devices in another thread, after the thread returns, I get access violation", and its workaround was to spawn a thread and join it — which on the WASAPI path is precisely what destroys the apartment. It may be worth re-reading those with this in mind.

History

The cached enumerator dates to e8a0537 (Jun 2019). DefaultDeviceMonitor arrived with #1183 (May 2026), which widened the exposure to a second path.

Possible fixes

Listing these with tradeoffs rather than proposing one, since the ASIO and winit constraints are yours:

  • Per-thread enumerator (thread_local) — simple; fixes enumeration; leaves the monitor path.
  • No caching, create per call — same coverage as above; costs a CoCreateInstance per call.
  • A dedicated long-lived COM thread owning the enumerator and servicing calls — covers both paths, keeps STA, costs one parked thread.
  • Marshal via the Global Interface Table — canonical COM answer; the most machinery.
  • MTA — would solve it outright, but conflicts with the deliberate COINIT_APARTMENTTHREADED choice for ASIO and winit.

I have a branch with the per-thread change if it is useful as a starting point, but since it only closes the first path I have not opened it as a PR.

Open question

Does UnregisterEndpointNotificationCallback require the same IMMDeviceEnumerator instance that registered? The documentation reads that way. If so, it rules out "create a fresh enumerator at drop time" as a fix for the monitor path.

Minor, separate

CoCreateInstance(...).unwrap() in the enumerator initialiser lets a safe API abort the process on failure.

Lenguaje dominante
Rust
Estrellas
4k
Forks
554
Merge medio
2 d 11 h
PR fusionados (30 d)
3

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 RustAudio/cpal

Todos los issues de RustAudio/cpal

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.