[wdmaudiodev] Re: Is there a way to force clearing device property cache on device uninstallation?

  • From: Eugene Muzychenko <reg.wad@xxxxxxxxxxxxxx>
  • To: Gary Daniels <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Mon, 4 Feb 2019 14:03:38 +0100

Hello Gary,

I sincerely agree that on a real uninstall it does make sense to
remove these keys. My problem is identifying when it's appropriate
to delete them, and when it's not because it's a transient
condition.

I think that the most appropriate solution is to keep the existing
behavior to prevent any non-obvious problems, but to add an explicit way
to ask AudioEndpointBuilder to remove entries corresponding to
non-existent devices.

It would work like INF/driver package database: by default, they are
kept upon device uninstallation, but there is SetupUninstallOEMInf
call that removes them, and Device Manager's uninstallation dialog
contains the "Delete the driver software for this device" checkbox.

So for most existing devices/drivers there will be no change. But
every developer of an audio device/driver will be able to add such
call to his uninstaller, either conditionally or unconditionally.

We were told by the PNP team to start using the DeviceInstall32 tag
in the sysvad driver, but we were not told at the time that they had
not intended for it to become public

Thank you for the clarification. I understand that adding arbitrary
named branches to the Enum tree is not a good idea. But MS could
reserve a particular enumerator subtree for them - for example,
"Enum\ThirdParty". Every virtual device developer might create a
single GUID-named vendor subtree under it, and particular device keys
as the descendants.

If you were to install two instances of your driver, you would see
that portions of this key changes. Those portions are ignored during
the migration comparison. The hardware id, if your device has one,
and reference strings don't change, they are what is used for the
comparison.

I understand that installing two instances of a virtual device
described by the same INF may lead some confusion. But I never do
that. All my virtual devices/drivers have unique HWIDs in their INFs.
Maybe there HWIDs are compared during the migration process, I didn't
try it. But I definitely see that their HWIDs are not taken into
account by AudioEndpointBuilder when it associates entries in
MMDevices with a newly installed virtual device. Only device instance
names (Root\MEDIA\nnnn) are used for comparison (together with
category class and reference strings). Since the "nnnn" is generated
automatically, I have no control over them, and in some cases,
AudioEndpointBuilder associates MMDevices entries from previously
uninstalled virtual device with the newly installed one, despite of
their HWIDs are different.

Making reference strings unique for each virtual device would be a
very ugly solution, because it violates the most common namespace
isolation principle. In the existing model, reference string namespace
(from AudioEndpointBuilder's point of view) appears to be global for
all virtual audio devices registered as "Root\MEDIA\nnnn", regardless
of their vendors and HWIDs. It is obviously not a good model.

Regards,
Eugene

******************

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx

URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/

Other related posts: