Pourquoi la boîte de dialogue «Périphériques de lecture» prend-elle tant de temps à s'ouvrir?

L’ouverture d’une des boîtes de dialogue des propriétés audio prend 2 minutes et 5 secondes à chaque fois. Aucune autre tâche ne prend un temps déraisonnable. C'est quelque chose de spécifique à la boîte de dialogue Propriétés du son. Si je redémarre mon ordinateur, celui-ci s’ouvrira immédiatement le premier ou les deux premiers jours.

C'est probablement un problème de conducteur. J'ai une carte graphique AMD avec sortie audio (via HDMI), une puce audio Realtek sur la carte mère, un microphone USB et un casque USB. Existe-t-il un moyen de déterminer lequel de ces comportements se comporte mal? Ou un moyen de comprendre ce qui retient les choses quand il attend?

http://www.overclock.net/t/903497/opening-playback-devices-is-slow suggère de désactiver les périphériques audio dans le Gestionnaire de périphériques.

Édité par Sean (le PO):

Cet article ne semble pas être complètement lié.   Leurs problèmes étaient liés aux feux croisés et au son via HDMI.   Cependant, désactiver le "Périphérique audio haute définition AMD"   dans le Gestionnaire de périphériques a travaillé pour moi.

Je l'ai réparé avec Pilote de périphérique audio HDMI ATI , testé dans ATI / AMD 7850 et R9 270x de realtek pour Windows 7 et 8.1.

J'ai le même problème et la mise à jour du pilote audio d'AMD n'a pas fonctionné. En fait, la mise à jour a entraîné l'arrêt du son HDMI.

Après être revenu à la version précédente du pilote, j'ai remarqué que le problème venait de l'utilisation de l'audio HDMI lorsque le téléviseur était éteint. Si je me souviens de le remettre sur "Haut-parleurs" lorsque le téléviseur est éteint, cela ne "s'arrête" pas.

Dans mon cas, arrêter AudioSrv, puis désactiver / activer le son AMD HDMI, la dernière reprise de AudioSrv a résolu le problème.

J'avais même pris quelques traces de ProcMon (comme suggéré avec diligence par magicandre1981) mais la seule découverte difficile fut que la fenêtre était ouverte en émettant "C:\Windows\System32\rundll32.exe" C:\Windows\System32\shell32.dll,Control_RunDLL C:\Windows\System32\mmsys.cpl

Il semble alors que ce processus passe par HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render Les périphériques AMD HDMI vérifient leur CLSID HKLM\SYSTEM\CurrentControlSet\Control\MediaCategories (en interrogeant le pilote, je suppose? Puisque ceux-ci n'ont été définis que dans la section HDAudioInstall.e0VirtualEPOutputTopo du pilote .inf)

... En fin de compte caler pendant environ 6 secondes sur mon système, et procéder comme si rien ne s'était passé HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses\{6994AD04-93EF-11D0-A3CC-00A0C9223196}\##?#HDAUDIO#FUNC_01&VEN_1002&DEV_whatever entrée de topologie HDMI associée; alors répétez l'opération jusqu'à ce que toutes les broches HDMI soient passées.

EDIT: Donc, j’ai eu ce problème à nouveau aujourd’hui et j’ai creusé un peu plus (avec ProcExp cette fois), et je ne suis même plus sûr que c’est une chose qui concerne particulièrement le dialogue en premier lieu. La pile Rundll32 ne charge pas seulement pour une raison quelconque AtihdW76.sys (le pilote) mais également un connard d'autres HDAudBus.sys, portcls.sys, ks.sys, ksthunk.sys, MMDevApi.dll .... Tous les fichiers qui n'y figurent pas quand il s'ouvre sans heurts normal.

Mais plus que tout, le problème semble résider en amont, dans la mesure où si je ne fais que redémarrer AudioSrv (sans toucher au périphérique AMD HDMI), le redémarrage prend également une minute entière. Fait intéressant, même à l’arrêt, il y a toujours 2 poignées dans svchost.

EDIT2: Et pour une raison quelconque, le démarrage et l’arrêt de périphériques HDMI .. démarre et arrête également de nombreuses instances DHCP (oui, vous avez bien lu) dans le même conteneur.