Tatsächlich: Diesmal hat Windows ganze Arbeit geleistet. Während ich über all’ die Jahre verschont geblieben bin, hat es mich diesmal auch erwischt.
Tja, und da half dann auch das Audiogeräte-Backup nichts mehr.
Diesmal ist Windows da aber wirklich mit einem harten Besen durchgefegt. Ich stelle mich auf einen knackigen Support ein…
Kurios: In Windows bleiben die intern vergebenen Soundkartennamen ja erhalten.
mAirList 7 baut darauf auf (nein, das ist keine Werbung!). Da hat’s bei mir zwar auch zugeschlagen, aber unter gewissen Umständen orakelt 
mAirList die Einstellungen zurück, versehen mit einem Warnzeichen (“bitte überprüfen”).
Das sieht dann so aus:
Warum ist das so?
Ich habe Torben dazu im internen System befragt, und ich zitiere auszugsweise:
Jedes WASAPI-Gerät hat eine eindeutige, von Windows bei der ersten (Hardware-)Erkennung vergebene GUID. Nach dieser richtet sich mAirList.
Nach einem Update (oder auch Umstecken einer USB-Soundkarte auf einen anderen Port etc.) kann es ein, dass Windows das Gerät neu erkennt - also eine neue GUID vergibt, wohl aber unter demselbem Anzeigenamen.
Und jetzt kommt der Trick:
mAirList 7 merkt sich nun zusätzlich zu den GUIDs auch noch den Anzeigenamen. Und ist eine GUID verschwunden, aber dafür ein Gerät mit einer neuen GUID, aber demselben Namen erschienen, sieht man das kleine Warn-Icon und kann es mit einem Klick reparieren.
Im Changelog der v7 liest sich das nüchterner:
[+] Redesigned Audio Routing configuration with improved identification/testing
and built-in repair function when device IDs change after Windows update
Genau für solche Anwendungsfälle wurde das eingeführt.