[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: Sat, 2 Feb 2019 10:51:18 +0100
Hello Gary,
To you uninstall and reinstall, and OS upgrade are two different
things. To AudioEndpointBuilder service, they are intermingled.
These processes are different not to me only, they are different by
the essense. If is't really that bad, Endpoint Builder definitely
should take OS upgrade process into account.
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 can understand that that such behavior is a kind of workaround. But
I cannot understand why such behavior should be considered as the only
right.
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.
It's very strange. I thought that OS upgrade process is a very specific
state that can be identified by many signs. Maybe you mean that OS
upgrade may be performed in the background, and user-initiated actions
may be indistinguishable from system-initiated ones? If so, a way to
trigger device entry deletion in MMDevice would be enough. Any
device uninstaller could use it to ask Endpoint Builder to remove
entries for the device being uninstalled.
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.
But why not to include device hardware IDs into the comparison?
Virtual devices have them as well as real ones.
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
I'm afraid it will be too ugly because reference strings are intended
to distinguish internal device functions, not variations of devices
derived from the same basic version.
In my opinion, much more correct way is to use a hardware ID to create
a specific branch in the ENUM\ROOT, as Matthew suggested:
https://www.freelists.org/post/wdmaudiodev/How-to-sign-up-with-MS-with-the-Win10-driver-no-charge-attestment-option,21
In such case, hardware ID becomes a part of the instance ID, as for
PCI/USB devices, and all migration problems you mentioned should be avoided.
But, in any case, there should be a way to remove MMDevice entries
that corresponds to a device being uninstalled permanently. Now
MMDevice database grows indefinitely, it obviously is not a correct
behavior.
Many USB audio devices are different in design but based on the same
chip, so they may have the same VID/PID/MI, and most of them have no
serial numbers. A user who changed endpoint names and/or other
settings for a USB device, then thrown this device away, and connected
a differently looking device based on the same chip several months
later, may be greatly surprised by its actual settings.
For an application uninstaller, it is considered incorrect
to unconditionally leave registry settings and/or profile
configuration files, offering no way to delete them. A device
uninstaller should have an opportunity to either delete the
appropriate system/user properties from MMDevice, or keep them for
further re-installation.
So I don't ask for changing the OS behavior by default. I'm only
asking for a signal to Endpoint Builder to delete cached properties
for a device that had already been uninstalled.
I had filed a proposal in the Feedback Hub but cannot retrieve the URL
because my Win10 cannot connect to the service for an unknown reason.
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:
