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

[joshelson]

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.

[LastExceed]

This issue was written by an LLM, wasn't it?

---

Per-thread enumerator / No caching

This is a bad idea, as it doesn't actually solve the root problem for other COM objects, such as IAudioClient, which we can't just create multiple instances of for the same stream

A dedicated long-lived COM thread

Despite being an ugly solution, I'm afraid that for ASIO, it will actually HAVE to be this, since IASIO supports neither MTA nor marshaling

Marshal via the Global Interface Table

If we were to go the marshaling route, we should probably use agile references instead (via RoGetAgileReference()), as they seem much easier to work with. But given that WASAPI supports MTA, there is probably no need for that

MTA — would solve it outright

Not quite. Users of cpal could still end up Sending the COM objects to threads that haven't joined the MTA. This may happen to work for inProc COM objects, but is undefined behaviour. Maybe it would work if we also added a mechanism that automatically initializes COM on every thread the object is sent to (not sure what that would look like, I'd have to think about this for a while), but this feels like a hack. Then again, the dedicated thread solution isn't exactly great either, so maybe this is way to go for WASAPI regardless

deliberate COINIT_APARTMENTTHREADED choice for ASIO and winit.

• For ASIO it is a necessity, not a choice.
• I don't know why winit is brought up here, as there are no ties between it and cpal.

---

COM just doesn't play nicely with modern multi-threaded architecture, and I'm afraid the current COM code was written with an incomplete understanding of how COM actually works

cpal/src/host/com.rs

Lines 15 to 17 in e0893c3

	// This call can fail with RPC_E_CHANGED_MODE if another library initialized COM with MTA.
	// That's OK though since COM ensures thread-safety/compatibility through marshalling when
	// necessary.

Apparently it was assumed that marshaling just happens automatically under the hood (which is NOT the case), because there are multiple unsafe Send/Sync impls like this:

cpal/src/host/wasapi/device.rs

Lines 57 to 61 in e0893c3

	/// Wrapper because of that stupid decision to remove `Send` and `Sync` from raw pointers.
	#[derive(Clone)]
	struct IAudioClientWrapper(Audio::IAudioClient);
	unsafe impl Send for IAudioClientWrapper {}
	unsafe impl Sync for IAudioClientWrapper {}

I'm currently in the process of learning all about COM for my work on #1299 , and I will likely end up fixing this for the WASAPI backend as well along the way.