I have a component that runs before, during, and first thing after the upgrade.
I know when those phases happen, that's the easy part. The problem lies with
first boot. During first boot AudioEndpointBuilder starts up and starts setting
up all of the endpoints and migrating the user settings, while at the same time
PNP is finalizing all of its upgrade work and getting all of the drivers to
come up for the first time. Interfaces come and go, drivers come and go,
AudioEndpointBuilder is not a PNP component and has no insight inside of PNP to
know when to wait, no insight into why stuff is happening (beyond me meeting up
with the person i know in PNP with questions, which happens regularly). In some
cases AudioEndpointBuilder would start up before PNP completed migration, it
would detect that the driver was missing, interpret that as a removal, and
delete the user settings. In other cases, AudioEndpointBuilder would process an
endpoint coming up, migrate the user settings to endpoints, only to have PNP
remove the driver and re-enumerate it a short time later, causing the user
settings to be lost.
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. The core problem here is that
AudioEndpointBuilder and MMDevapi are legacy components that have been bolted
onto the side of pnp and try to do PNP-like operations, but is not actually a
PNP component. I've been working to detangle this spaghetti code (you may have
noticed that audmigplugin has shrunken dramatically and mmci.dll is gone
entirely), and working with the PNP team on real solutions. The retention of
these settings is an area that needs additional work.
Regarding Matthew's recommendation, that's an unfortunate mistake. 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, simple miscommunication. It was never meant to be communicated broadly,
it was only ever intended for testing. You won't find MSDN documentation for
the tag. It has been removed from the sysvad sample driver. I cannot recommend
the approach, it is not a supported feature and future support for it is
uncertain.
I can give you a bit of insight into how AudioEndpointBuilder works, so
hopefully you can understand what is going on and are better equipped to figure
out what is going wrong when there are problems. Needing to do an uninstall and
reinstall is a symptom of a larger problem, so how can I help with identifying
the root cause, and help to fix those issues.
take a look at:
hklm\software\microsoft\windows\currentversion\mmdevices\audio\<flow>\<mmdevice
id guid>\properties {840b8171-b0ad-410f-8581-cccc0382cfef},0.
This property key contains the string which is used for the comparison for
settings migration. 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.
Regarding USB, yes, that is exactly what would happen. If the hardware id is
the same and the reference strings are the same, whether you have devices from
different vendors or two of the same device, then the settings will match and
migration will have problems. That's true for all versions of windows, i have
not yet had an opportunity to address that class of bugs, but I am aware of it.
-Gary
-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> On
Behalf Of Eugene Muzychenko
Sent: Saturday, February 2, 2019 1:51 AM
To: Gary Daniels <wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] Re: Is there a way to force clearing device property
cache on device uninstallation?
Hello Gary,
To you uninstall and reinstall, and OS upgrade are two different
things. To AudioEndpointBuilder service, they are intermingled.
I accept your feedback that you preferred the prior behavior of the
settings being deleted, but please understand that these changes were
not done lightheartedly, they were done as a direct result of many
user feedbacks and have been largely beneficial for users.
I currently have no way to distinguish a user initiated uninstall from
system initiated transient condition that is part of a driver update
or OS upgrade.
0001 and 0002 are ignored, as those are generated instance numbers
which change across OS and (some) driver updates depending on how the
driver update package is made.
The correct thing to do here is to use a unique reference string that
correlates to the function of the device and is, preferably, unique
enough to not get mixed up with other manufacturers
