[wdmaudiodev] Re: Is there a way to force clearing device property cache on device uninstallation?
- From: Eugene Muzychenko <reg.wad@xxxxxxxxxxxxxx>
- To: Matthew van Eerde <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Thu, 31 Jan 2019 18:08:10 +0100
Forwarding reply from actual audio dev
Thank you for the forward.
the issues you're seeing now with virtual audio devices has existed
across all past releases of Windows.
They are observed in Windows 10 only. All previous 6.x systems delete
MMDevice entries as the appropriate audio device is uninstalled.
Let's start by covering how Windows OS updates work for audio.
I'm not telling about OS upgrades, just about device
In this particular case, because these virtual drivers are root
enumerated, there isn't a hardware ID available.
Why are HW IDs not available? Each virtual audio driver specifies its
unique hardware ID in its INF file.
The only comparable piece of information is the reference string.
I don't know how it works with OS upgrades, but with device
installation/uninstallation, the instance ID is compared too.
If a virtual device was installed as ROOT\MEDIA\0001, and its driver
exposed KS interfaces, device endpoints are registered in MMDevice
database with the appropriate interfaces names that include device
If then another virtual device that uses the same driver, with a
different hardware ID, is installed as ROOT\MEDIA\0002, new MMDevice
entries are created for it because there is no such instance ID in
But if both devices are uninstalled, but their MMDevice entries are not
deleted by Windows 10, and then the second device is installed as
ROOT\MEDIA\0001, there already are old entries in MMDevice with
matching interface names (instance ID + category GUID + reference
string). So Windows 10 Endpoint Builder supposes that the same device
was reinstalled, however device's hardware ID is different.
I have investigated and root caused many bugs from users about lost
settings and broken audio after an OS upgrade. As a result, we've
made a number of changes to improve consistency, reliability, and
user experience. The OS is much more persistent about retaining user
settings now and much more consistent about when to apply the
retained user settings.
I understand that retaining user audio settings after OS upgrade is
important. But what is the reason to retain such settings after device
uninstallation? If a user uninstalls a device, he either stops using
it at all, or wants to remove all traces from the system and install
it from scratch. But aggressive property caching in Windows 10 takes
away user's opportunity to perform a cleanup.
If you consider that such Windows 10 behavior is correct and
reasonable, there obviously should be a way (both programmatic and
manual) to force Endpoint Builder to delete MMDevice entries related
to the device being uninstalled.
The fix should be obvious now. For root enumerated software
devices, because it lacks a hardware ID, the OS has a limitation
that reference strings must be unique to ensure that settings aren't
mixed up on OS upgrades and driver updates.
Generating unique reference strings is not a good idea because they
identify particular resources within the device. The much more
reasonable is to have unique hardware ID, and use it instead of
auto-generated instance ID, installing the device in ROOT\hwid\0000
instead of ROOT\MEDIA\nnnn.
But, anyway, MMDevice database in Windows 10 can only grow but cannot
shrink. It is not a good design, there should be a way to remove
system and/or user settings related to a particular device, even
without uninstallation of the device.
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
Other related posts: