IAudioClient::Stop() blocks infinitely under certain conditions RRS feed

  • Question

  • Since one of the latest Windows 10 updates (I suspect the famous October 2018 update) and with my test audio devices, IAudioClient::Stop() blocks infinitely under these conditions:

    • A USB 2.0 audio device with a native driver is used (Microsoft's UAC2 driver "usbaudio2.sys" is not used)
    • IAudioClient is initialized with exclusive mode (AUDCLNT_SHAREMODE_EXCLUSIVE) and event callback (AUDCLNT_STREAMFLAGS_EVENTCALLBACK)
    • During playback (after successfully calling IAudioClient::Start()), the USB cable is disconnected or the device is powered off

    Under these conditions, the event successfully set in IAudioClient::SetEventHandle() will no longer be signaled (which makes perfectly sense because the device is no longer available). Consequently, audio rendering stops because the thread calling IAudioRenderClient's GetBuffer()/ReleaseBuffer() combination waits infinitely for the event with WaitForSingleObject(). As a result,  the user no longer hears sound even though the audio application is still playing from his perspective. Therefore, he will most likely click on a button or press a key that stops playback (from his point of view). This will eventually call IAudioClient::Stop() at the depth of the application code. And this call blocks infinitely. Since this function is usually called in the UI thread, the application freezes and can only be terminated in the Task Manager (well, not really, see below).

    I know it's evil to disconnect the USB cable or power off the device during playback. However, this is part of my test routine, as the audio application should behave reasonable even under these unlikely conditions.

    This infinite blocking did not happen until I installed one of the latest Windows 10 updates. And I used the same audio devices and the same native drivers before. So I see a certain probability that Microsoft has introduced a bug here.

    Fortunately, this behavior can be easily reproduced using Microsoft's own "Windows-classic-samples-master" SDK samples and the VS project in the "Samples\Win7Samples\multimedia\audio\RenderExclusiveEventDriven" folder ( Simply migrate to the VS version you use (I use the latest VS2019), place a breakpoint in file WASAPIRenderer.cpp at line 428, start debugging, select your audio device in the console window of the application and (within ten seconds) disconnect the USB cable or power off the device. After ten seconds the code stops at the breakpoint. Now try to step over it.

    This is the call stack you get:
    WASAPIRenderExclusiveEventDriven.exe!CWASAPIRenderer::Stop() Line 428
    WASAPIRenderExclusiveEventDriven.exe!wmain(int argc=1, wchar_t * * argv=0x02688fa0) Line 412
    WASAPIRenderExclusiveEventDriven.exe!invoke_main() Line 90
    WASAPIRenderExclusiveEventDriven.exe!__scrt_common_main_seh() Line 288
    WASAPIRenderExclusiveEventDriven.exe!__scrt_common_main() Line 331
    WASAPIRenderExclusiveEventDriven.exe!wmainCRTStartup() Line 17

    You must stop the debugger if you don't want to wait forever. But even then, "WASAPIRenderExclusiveEventDriven.exe" does not really terminate. It is still present in Task Manager->Details and cannot be terminated via "End task": A message box titled "Unable to terminate process" pops up with the explanation "The operation could not be completed. Access is denied". You may have to reboot your computer.

    By the way, IAudioClient::Start() and IAudioClient::Reset() block infinitely, too.

    Of course, there is a possibility that this only happens with my specific audio devices. It may be that the native drivers always had a bug that only took effect after the latest Windows 10 updates. So can someone try to reproduce this behavior?

    My Windows 10 Pro version is 1809 17763.379.

    Sunday, May 5, 2019 9:11 AM

All replies

  • Can you report this as a bug in Feedback Hub?

    Once you've created the problem report, send me a direct link.

    Please include a process dump of the app in the hung state. Depending on what it shows, I may also need other information, like a kernel dump.

    Matthew van Eerde

    Monday, May 6, 2019 3:38 PM
  • OK, I have reported it in Feedback Hub. The process dump file is attached (though I can't see it anymore, is it not public?).
    Anyway, maybe you can see it. Here is the short link:

    Monday, May 6, 2019 5:32 PM
  • Thanks. Unfortunately I don't see any attachments on the problem report. Can you upload the dump and send it to me out-of-band? Email (mateer at microsoft dot com)

    Matthew van Eerde

    Monday, May 6, 2019 8:50 PM
  • I have no idea why it doesn't work. I tried three times, once with the original post and twice after. After I click on the "Submit" button there is no sign of failure. But the file is not sent. If 13 MB is too much data, then the Feedback Hub app should inform the user about it.

    Anyway, I send it to your work account. Look for a mail from powerchord at web dot de. It's a zipped dmp file.

    Wednesday, May 8, 2019 7:15 AM
  • Thanks for the dump file.

    The IAudioClient::Stop call on thread 0 is waiting for a critical section owned by thread 7.

    Thread 7 is processing a "stream disconnection request" callback and is waiting for the asynchronous I/O manager thread to exit. This is thread 5.

    Thread 5 is waiting on a CancelIo call into the kernel.

    At this point I need a kernel dump to see what's holding up the CancelIo call. It could be a bug in the audio driver, or it could be something else.

    Please follow these steps to force a bluescreen of death at the point of the hang, and send me the resulting memory.dmp file (compress it first)

    Matthew van Eerde

    Wednesday, May 8, 2019 1:18 PM
  • This time the mail comes from templatize at gmail dot com. The file is too large to send as an attachment, there should be a Google Drive link instead.
    Wednesday, May 8, 2019 3:53 PM
  • I got an email from templatize but it didn't have any links in it.

    Matthew van Eerde

    Wednesday, May 8, 2019 4:08 PM
  • OK, got the memory.dmp.

    The CancelIo thread is associated with two IRPs, but I'll need to do some digging to see what's holding things up.

    Matthew van Eerde

    Wednesday, May 8, 2019 4:22 PM
  • Too deep for me. Made an actual bug, attached the dump files, and linked it to the problem report. We'll see what the devs make of it.

    Matthew van Eerde

    Wednesday, May 8, 2019 5:45 PM
  • Is there a way for me to get feedback from Microsoft on this issue? I would really like to know whether or not this is a bug in the audio driver.

    If it is I would consider replacing my audio device as the driver development is finished.

    Wednesday, May 8, 2019 6:06 PM
  • If you'd like official updates on the status of the underlying bug you can open a support case at

    They may be able to pull the bug number from the Feedback Hub problem report, but just in case I will give it to you here: 21522520

    To my eyes it certainly looks like a bug in the audio driver, in particular the IOCTL_KS_WRITE IRPs are not being completed when the audio device is surprise-removed

    Matthew van Eerde

    Wednesday, May 8, 2019 6:12 PM
  • When you unplug the USB device, do you re-plug it back in right away? If this is the case, do you see a different behavior if you just unplug the device? Are you able to install and try the in-box audio drivers (usbaudio2.sys for UAC2 or usbaudio.sys for UAC1), do you see the same or different behavior? Thx.
    Thursday, May 16, 2019 10:25 PM
  • Do you mean to re-plug it before the ten seconds playback ends or after it has ended? That is, before the application calls Stop() or after it has called Stop()?

    I did both. In the latter case, I even tried powering the devices off and on just to see if it makes any difference.

    In all cases, the result is the same: once the device has been surprise-removed, Stop() blocks infinitely (and Start() and Reset(), too).

    I tried to install both Microsoft drivers, but in both cases the devices are not recognized. They only work with the vendor drivers.

    Do you have a USB audio device and Windows 10? If so, could you try to reproduce the behavior with the Microsoft console application mentioned above? All I did was to compile Microsoft's original sample (see my original post for details) with Visual Studio 2019. I can give you the compiled WASAPIRenderExclusiveEventDriven.exe. It only takes a little over ten seconds to see what's happening with your device. If you remove your device within the ten seconds playback but the console window closes nonetheless, then it's very probably only a device driver bug and a non-issue. But if the console window does not close it's very probably a Windows bug (unless we have the same device).

    Friday, May 17, 2019 9:34 AM
  • There is pending IRP sitting at the \Driver\emusba10 driver layer. This driver is a KS USB audio driver. The system is unable to remove the device b/c of this pending IRP reference.  The IRP has been tagged as cancelled although no one has taken any action to actually abort the request. Most likely the IRP is sitting in a non-cancellable queue or someone forgot to complete it.

    Do you see the same issue if you play a song using groove or media player and you unplug this device while streaming?

    It also looks like the USB device has an upper filter driver TotRec8 (just above the emusba10). The TotRec8 is part of the Total Recorder 8, are you able to remove that package and try to repro again?  

    Tuesday, May 21, 2019 4:05 PM
  • You make my day!

    If Total Recorder is uninstalled, IAudioRenderClient::GetBuffer() now reports error 0x88890026 (= AUDCLNT_E_RESOURCES_INVALIDATED) when I disconnect the cable or turn off the device. After ten seconds of playback, IAudioClient::Stop() does not block any longer but returns S_FALSE instead (which means success, but with a stream already stopped).

    To make sure that this is not a coincidence, I reinstalled Total Recorder. And yes, Stop() blocked again. So I uninstalled Total Recorder again and yes, the behavior is now as described above.

    I have been using Total Recorder 8 for quite some time only for loopback recording. I have always wondered why a TotRec8.sys driver appears in the driver list of an audio device. But I thought the developers know what they are doing. I guess I was wrong. The blocking behavior was triggered with one of the latest Windows updates. Is it still safe to say that the bug is only in TotRec8.sys?

    Thank you for taking the time to investigate this issue.

    Wednesday, May 22, 2019 8:55 AM
  • You should be able to do loopback recording without Total Recorder by using the AUDCLNT_STREAMFLAGS_LOOPBACK flag;see

    Matthew van Eerde

    Wednesday, May 22, 2019 3:28 PM