В моем случае остановка AudioSrv, а затем отключение / включение звука AMD HDMI при последнем возобновлении AudioSrv устранили проблему.
Я даже взял некоторые трассировки ProcMon (как усердно предложено magicandre1981), но единственным трудным открытием было то, что окно открывается путем выдачи "C:\Windows\System32\rundll32.exe" C:\Windows\System32\shell32.dll,Control_RunDLL C:\Windows\System32\mmsys.cpl
Похоже, что тогда этот процесс проходит через HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render HDMI-устройства AMD, проверяет их CLSID в HKLM\SYSTEM\CurrentControlSet\Control\MediaCategories (запрашивая драйвер, я полагаю? Так как они были определены только в разделе HDAudioInstall.e0VirtualEPOutputTopo драйвера .inf)
...
В конечном счете, в моей системе на 6 секунд происходит остановка, и процесс продолжается, как будто ничего не произошло по HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses\{6994AD04-93EF-11D0-A3CC-00A0C9223196}\##?#HDAUDIO#FUNC_01&VEN_1002&DEV_whatever связанной записи топологии HDMI; повторяйте, пока все выводы HDMI не пройдут.
РЕДАКТИРОВАТЬ: итак, у меня снова возникла эта проблема сегодня, и я продолжил копать (на этот раз с ProcExp), и я даже не уверен, что больше это вообще касается диалога. Стек Rundll32 не только по какой-то причине загружает AtihdW76.sys (драйвер), но и хакон других HDAudBus.sys, portcls.sys, ks.sys, ksthunk.sys, MMDevApi.dll .... Все вещи, которых нет, когда они открываются гладко, нормально.
Но, скорее всего, проблема, по-видимому, связана с тем, что если я просто перезагружаю AudioSrv (не касаясь устройства AMD HDMI), также потребуется целая минута, чтобы начать снова. Интересно, что даже когда он остановлен, в svchost есть еще 2 ручки.
EDIT2: И по какой-то причине запуск и остановка устройств HDMI ... также запускает и останавливает множество экземпляров dhcp (да, вы правильно прочитали) в одном и том же контейнере.
