:gsvelto, the behavior you are talking about was introduced in bug 1419488. It works the way you suggest, but it's limited to Windows 7 , which means it can't be responsible for most of what we are seeing here (nearly all crashes are Win 10).
From here is gets complicated. The crash with CDeviceEnumerator::UnregisterEndpointNotificationCallback -- the one that came in when bug 1614585 was duplicated to this one -- very much mirrors what we saw in bug 1419488. And that crash is currently 100% in Windows 10, going back 6 months. So there may be 2 things there : (1) its not actually a dupe of this and (2) we should extend the code in  to work in Windows 10, not just Windows 7, as the hang now shows up there too.
That would still leave the crash in comment 0. The crash is in system code and doesn't seem to be giving any really useful data. It happens in all versions of Windows. Crash-stats says that many of them are actually startup crashes (I don't know how much to believe this). The crash is a core system-RPC-related operation and it looks like some of them have some audio stuff on the stack but most don't. The ones that look audio-related seem to be in shutdown/hang behavior (again, I'm not certain of this). So I took a look at the Windows 7 crashes under that signature . I've only checked a dozen or so but none were clearly audio related and most seemed very much not (most, but not all, seem to be in graphics). From all that, I'm thinking that extending the Win 7 audio fix above to the rest of Windows may also fix the audio-related crashes under this signature, but not fix the crash in its entirety since it probably has many causes.
I'm going to un-dupe bug 1614585 and extend the win 7 fix to the rest of Windows there. I'll leave this bug open because I don't know how best to deal with it.