Windows 10 COM crash under loader lock - c++

Question

I stumbled across a Windows 10 crash that's probably new since the Windows 10 update to 2004.
The problem is a crash in ntdll when COM is starting. COM is needed to use Core Audio.
Code which triggers it:
IMMDeviceEnumerator* enumerator = nullptr;
CoInitializeEx(nullptr, COINIT_MULTITHREADED); // Also with STA
HRESULT hr = CoCreateInstance( CLSID_MMDeviceEnumerator, 0, CLSCTX_ALL, IID_IMMDeviceEnumerator,
(void**)&enumerator);
Popup:
Unhandled exception at 0x00007FFE7846D3D1 (ntdll.dll) in MicTest.exe:
A LIST_ENTRY has been corrupted (i.e. double remove).
Callstack:
ntdll.dll!LdrpInsertDataTableEntry()
ntdll.dll!LdrpMapDllWithSectionHandle()
ntdll.dll!LdrpMapDllNtFileName()
ntdll.dll!LdrpMapDllFullPath()
ntdll.dll!LdrpProcessWork()
ntdll.dll!LdrpLoadDllInternal()
ntdll.dll!LdrpLoadForwardedDll()
ntdll.dll!LdrpGetDelayloadExportDll()
ntdll.dll!LdrpHandleProtectedDelayload()
ntdll.dll!LdrResolveDelayLoadedAPI()
combase.dll!00007ffe769ab1c2()
combase.dll!00007ffe769c56fd()
combase.dll!00007ffe769b3b27()
ntdll.dll!RtlRunOnceExecuteOnce()
KernelBase.dll!InitOnceExecuteOnce()
combase.dll!00007ffe7696c11f()
combase.dll!00007ffe7696baf8()
combase.dll!00007ffe7696b9e6()
combase.dll!00007ffe76907df2()
combase.dll!00007ffe76906fce()
combase.dll!00007ffe76907928()
combase.dll!00007ffe76907718()
MicTest.exe!Microphone::Microphone() Line 23 C++
[External Code]
MicTest.exe!main(int argc, char * * argv) Line 67 C++
It's not 100% reproducible there, sometimes the crash is a few lines later in IAudioClient::Initialize when ntdll crashes under loader lock in
> ntdll.dll!LdrpInitializeThread()
ntdll.dll!_LdrpInitialize()
ntdll.dll!LdrpInitialize()
ntdll.dll!LdrInitializeThunk()
This happens in one of the new Windows 10 threadpool threads that Windows itself uses to load a DLL. The offending code shows up as AudioSes.dll!CAudioClient::CreateRemoteStream (Note: AudioSes.dll is Core Audio, symbols per the Microsoft Symbol Server.)
Is this a known problem? Is there a workaround?
For completeness, complete code:
Microphone::Microphone()
{
IMMDeviceEnumerator* enumerator = nullptr;
CoInitializeEx(nullptr, COINIT_MULTITHREADED); // crash near here
HRESULT hr = CoCreateInstance( CLSID_MMDeviceEnumerator, 0, CLSCTX_ALL, IID_IMMDeviceEnumerator, (void**)&enumerator);
if (!enumerator) throw std::system_error(hr, std::system_category());
IMMDevice* device = nullptr;
hr = enumerator->GetDefaultAudioEndpoint(eCapture, eConsole, &device);
enumerator->Release();
if (!device) throw std::system_error(hr, std::system_category());
hr = device->Activate(IID_IAudioClient, CLSCTX_ALL, NULL, (void**)&client);
device->Release();
if (!client) throw std::system_error(hr, std::system_category());
WAVEFORMATEXTENSIBLE *pwfx = nullptr;
hr = client->GetMixFormat(reinterpret_cast<WAVEFORMATEX**>(&pwfx));
if (SUCCEEDED(hr) && pwfx)
{
this->span.sampleRate = pwfx->Format.nSamplesPerSec;
this->blockAlign = pwfx->Format.nBlockAlign;
// In general, this is NOT pwfx->wBitsPerSample;
if (pwfx->SubFormat == KSDATAFORMAT_SUBTYPE_IEEE_FLOAT)
{
this->format = fmt_FP32;
}
else if (pwfx->SubFormat == KSDATAFORMAT_SUBTYPE_PCM)
{
this->format = fmt_PCM;
}
else
{
// Can't deal with that format, and Core Audio ought to support FP32.
pwfx->SubFormat = KSDATAFORMAT_SUBTYPE_IEEE_FLOAT;
this->format = fmt_FP32;
}
}
// or crash here
hr = client->Initialize(AUDCLNT_SHAREMODE_SHARED, 0, 1000000, 0, &pwfx->Format, NULL);
if (!SUCCEEDED(hr))
{
throw std::system_error(hr, std::system_category());
}
CoTaskMemFree(pwfx);
// Start capture
hr = client->GetService( IID_IAudioCaptureClient, (void**)&capture);
client->Start();

Answer 1

As RbMm pointed out, this requires looking at the assembly. It turns out that Windows 10 2004 corrupts its PEB_LDR_DATA data structure. This is a per-process structure which contains important data. In particular, LdrpInitializeThread uses PEB_LDR_DATA::InLoadOrderModuleList directly after acquiring the Loader Lock. This can be a null pointer for unclear reasons.
Since this happens in a Windows-created thread in the default threadpool, it's unrelated to and unsynchronized with user code. The exact point of crash can vary - the damage to the PEB_LDR_DATA structure appears to be more extensive.
Workaround
While this is not a solution for the CoInitializeEx crash, it appears that the second crash due to PEB_LDR_DATA::InLoadOrderModuleList corruption can be avoided with minor changes:
Don't set a buffer size, but let Windows determine one and roll with that:
hr = client->Initialize(AUDCLNT_SHAREMODE_SHARED, 0, 0, 0, &pwfx->Format, NULL);
UINT32 bufSize = 0;
hr = client->GetBufferSize(&bufSize);
Determine when to call GetBuffer
auto samplePollRatio = pwfx->Format.nSamplesPerSec / 2666;
auto nextPoll = std::chrono::system_clock::now() +
std::chrono::milliseconds(bufSize / samplePollRatio);
And wait for it
std::this_thread::sleep_until(nextPoll);
auto hr = capture->GetBuffer(&buf, &samples, &flags, nullptr, nullptr);
This is a reasonable pattern anyway. The MSDN example also has a Sleep call, but sleep_until is more robust against variable delays in processing. (E.g. on the first call you may have some more delay when opening a WAV file to save the results etc). But by delaying the first sample acquisition you bypass an apparent race condition in Windows 10.