[English]Fehlen nach dem Setup von Windows 10 plötzlich die Bedienoberfläche für Treiber (z.B. für die Intel Graphics- oder Waves MaxxAudio-Einstellungen)? Ein kruder Bug bewirkt, dass die ursprünglich beim Setup aus dem Microsoft Store als UWP-App installierten GUI-Komponenten der Treiber in der OOBE-Phase entfernt werden. Hier ein paar Informationen zu diesen Thema, das in Windows 10 Version 1809 nachgewiesen wurde, aber alle Windows 10-Builds bis Windows 10 Version 2004 betrifft – erst in Windows 10 20H2 ist das Ganze korrigiert.
Anzeige
Windows 10-Treiberinstallation schlicht kaputt
Es ist eine krude Geschichte, auf die mich Blog-Leser Thomas K. Mitte Dezember 2020 per Mail hinweisen hat. In seiner Mail hat er mich mit der Bemerkung Es liegt nun schon einige Zeit bei mir ab und ich frage mich ob es bei Dir aufgeschlagen ist […] auf ein Problem in Windows 10 hingewiesen. Dieses ist bereits im Sommer 2019 durch Mikko Järvinen auf Twitter dokumentiert worden.
Järvinen ist aufgefallen, dass bei Windows 10 Enterprise SKU (1809 x64 Bit) etwas bei der Treiberinstallation gewaltig schief läuft. Nach der Installation von Windows 10 Enterprise und dem Einrichten des ersten Benutzers fehlt dort die graphische Benutzeroberfläche (GUI) für die Intel Grafik und die Waves MaxxAudio. Irgend etwas ist bei der automaischen Treiberinstallation kaputt gegangen. Järvinen glaubt gemäß obigem Tweet, dass das Problem prinzipiell alle Windows 10 Versionen betrifft. Inzwischen ist bekannt, dass Microsoft das Ganze in Windows 10 20H2 gefixt hat.
Windows Universal-Treiber-Installations-Problem
Das Ganze hängt damit zusammen, dass bei Microsoft die linke Hand nicht weiß, was die Rechte tut. Järvinen hat genauer nachgeschaut und das Ganze in einer Reihe von Tweets dokumentiert. Windows 10 lädt Gerätetreiber über Windows Update herunter und installiert diese auch sauber. Dabei handelt es sich um Universal Windows-Treiber. Die Installation der Dateien erfolgt über die Informationen in einer für das Gerät vorliegenden .inf-Datei. Soweit alles bekannt.
Anzeige
Die .inf-Datei zur Treiberinstallation weist Windows 10 darauf hin, dass eine 'Companion UWP-App' für diesen Treiber benötigt wird. Diese UWP-App gibt es aber nur im Microsoft Store (nicht per Windows Update oder im Treiber-Paket). Hinzu kommt, dass diese UWP-App 'versteckt' ist, so dass (wegen eines fehlenden .appx-Bundle) kein Download möglich ist. Nur wer einen Deep-Link in den Store kennt, könnte sich das Paket herunterladen. Aber Windows lädt die UWP-App automatisch und installiert diese. Der betreffende Treiber funktioniert zu diesem Zeitpunkt der Windows 10-Installation noch.
Jävinen hat dies in obigem Screenshot während der OOBE-Phase der Windows 10-Installation dokumentiert. Die benötigte Waves MaxxAudio-Komponente sowie die Windows-Apps-Dateien sind auf dem System vorhanden und installiert. Dann wird die OOBE-Phase durchlaufen, das System neu gestartet und der erste Benutzer eingerichtet.
Side-Loading-Policy entfernt UWP-App
Sobald sich dieser Benutzer anmeldet, gibt es die unangenehme Erfahrung, dass die Grafik-Oberfläche (GUI) diverser Treiber nicht mehr funktioniert. Im aktuellen Fall sind es die GUIs für Intel Graphics und Waves MaxxAudio. Die benötigten UWP-Apps werden schlicht durch die Side-Loading-Policy von Windows 10 geblockt bzw. entfernt. Dazu schrieb mir Blog-Leser Thomas K. in seiner Mail:
Uns hat es hart mit [Windows 10 Version] 1909 und dem Nvidia-Treiber getroffen. Bei denen rennt ein Service welcher die App ruft, die ja toller weise entfernt wurde, was in einer schönen Fehlermeldung für den Benutzer/In endet.
Jävinen hatte die Hoffnung, dass er das Ganze per Sideloading-Policy beheben könnte, so dass er auf Twitter einen Lösungsvorschlag unterbreitet: Beim Enterprise Deployment sollte Sideload apps für alle vertrauenswürdigen Apps in der Setup-Phase, bevor die Treiberinstallation per Windows Update und aus dem Microsoft Store beginnt, aktiviert werden. Das geht aus nachfolgendem Tweet hervor.
In weiteren Tweets kommt Jävinen aber zur Erkenntnis, dass es so aussieht, als ob die Sideloading-Richtlinie den Windows UWP-Status in einen Zustand versetzt, in dem er nicht sein sollte. Auf Twitter arbeitet Jävinen sich am Thema ab – eine Deinstallation ist nicht so einfach möglich. Blog-Leser Thomas schrieb mir dazu:
Soweit unsere Lösung… man drehe den Service ab. Hauptsache neues Treiber Modell…
Das Ganze ist zwar in 20H2 gefixt, aber diese Beta lassen wir auch erst mal bis nächsten Sommer gut reifen :)
Falls jemand von dem Problem betroffen ist, dass bei der automatischen Treiberinstallation benötigte UWP-Apps in der OOBE-Phase von der Sideloading-Richtlinie gelöscht werden, ist zumindest eine Erklärung gegeben. Details könnt ihr bei Bedarf auf Twitter nachlesen. Danke an Thomas für den Hinweis.
Anzeige
Etwas OT zum Feature-Upgrade…
Von HP-Treiber-Downloads kann ich berichten, dass in den SFX-Archiven nur INF-Installer gepaart mit AppX-Paketen drin sind (die wohl dann den nachzuladenden Apps entsprechen).
Zu NVIDIA kann ich berichten, dass auf der Treiber-Downloadseite erstmal nur die DCH-Treiber angeboten werden (also Nachladen der Store-Apps), über die "Beta-Treiber und Archiv"-Seite werden auch die Standardtreiber angeboten: https://www.nvidia.de/Download/Find.aspx?lang=de
Eigentlich bin ich ja ganz froh, wenn abseits der Treiber nicht so viele Dienstprogramme installiert werden, die vermutlich nur 1 Prozent der Nutzer überhaupt mal öffnet.
Es trifft sowieso nur Enterprise und Education. Alle anderen Versionen sind gar nicht betroffen!
Järvinnens vorgeschlagener Fix funktioniert nicht… habe ich ins image eingepflegt, keine Wirkung. Man darf davon ausgehen, dass die Sideloading-Policy in der Enterprise/Education einfach hin ist.
Bin bloß froh, dass sich die Audio Probleme mangels Wavesmax bei uns nicht manifestieren, denn die könnten wir so nicht lösen.
Ich finde sowas per Twitter zu kommunizieren echt anstrengend. Zudem fehlen mir hier ein paar Informationen. Welche Umgebung, Welches Installationsmedium. Hier wird meiner Meinung nach wieder ein Aufriss gemacht der so keiner ist. So typisch für diese Art der Kommunikation :(
Also man hat eine Enterprise Version von Windows 10. Dann betreibt man die eigentlich in einer Domänenumgebung. Die Lizenzen erhält man auch nur als Volumenlizenz. Dann wäre der erste eingerichtete Nutzer ein lokaler Adminaccount den man eigentlich nie wieder braucht.
Wenn man einen Windows 10 Client ordentlich mit Updates inklusive Store Apps versorgen will muss man eigentlich zur Enterprise/Education Version greifen, nur dann kann man überhaupt trotz WSUS und deaktiviertem Dualscan Updates für die Store Apps erhalten. Das läuft wohl über eine Art privaten Store. Das könnte ich mir gut als Hintergund des Problems vorstellen. Leider habe ich das noch nie gesehen weil mein Chef zu knausrig ist :) Dieser "Store" ist halt wahrscheinlich nicht definiert und deshalb wird die App deinstalliert. Wenn man drüber nachdenkt auch sinnvoll vielleicht ist die App schon auf dem Rechner ich will aber nicht das der Nutzer sie benutzen kann. Warum das nur beim ersten Nutzer greift wäre die spannende Frage.
Zumindest beim Intel Treiber gibt es außerdem sehr wohl eine App die ich nachträglich manuell aus dem Store installieren kann. Habe ich schon mehrfach gemacht. Ich habe mir diese Appx sogar per Webdienst heruntergeladen und auf einer Freigabe gespeichert damit ich sie manuell installieren kann.
Die Sache ist im Grunde genommen doch sehr einfach:
a) die Klientel fühlt sich nicht betroffen -> einfach schlafen legen
b) die Klieten ist betroffen -> Tweets/Artikel lesen und wissen warum
Leben muss nicht kompliziert sein – imho.
Sorry ich verstehe die Antwort nicht :)
Ich wollte darauf hinaus das hier wahrscheinlich ein System in einer Umgebung eingesetzt wird für die es vermutlich nicht vorgesehen ist. Damit arbeitet es vielleicht wie vorgesehen aber nicht wie vom Anwender gewünscht. Wie ich bereits schrieb kann man einen privaten Store konfigurieren, vielleicht muss man das sogar. Das Problem tritt dann mit einer Pro Version nicht auf da sie die Funktionalität gar nicht hat. Ohne die entsprechenden Informationen kann man aber gar nicht prüfen ob das ein Fehler vom Betretirebssystem ist. Oder der Admin einfach die entsprechende GPO verhunzt hat ;)
Die Antwort bezog sich auf den 'Aufriss' – hat von mir aber bewusst etwas Zen-mäßiges. Derjenige, der betroffen ist, findet Hinweise und kann das für sich klären. Für den Rest ist das Ganze eine 'sportliche Diskussion', die uns aber keinen Millimeter weiter führt.
Jain, als Admin vermeide ich es gerne in Zukunft von so etwas betroffen zu sein. Daher betrachte ich das nicht nur als "sportliche Diskusion". Gerade um solche Probleme zu vermeiden lese ich diesen Blog :) Im Gegenteil gerade bei IT-Nachrichten habe ich oft das Gefühl das die Kommentarsektion das wirklich Relevante ist. Zumal die Lösung für das Problem hier sogar schon nach wenigen Stunden genannt wurde.
Vielleicht war Aufriss das falsche Wort damit meinte ich aber auch die Twitteraktion und nicht den Artikel hier. Ich bin der festen Überzeugung das Twitter für einen solchen sehr komplexen Sachverhalt die falsche Stelle ist.
Darf ich um die Lösung bitten?
Denn kein einziges post hat eine Lösung vorgeschlagen, geschweige denn selber probiert.
Bin zu haben für Feldversuche!
Hands on, und nicht nur schlau daherreden, bitte wirklich mitmachen! :)
@Markus K
Lösung/Workaround: Installier die AppX-Pakete je nach Bedarf.
Per PowerShell/WMIC solltest du die installierte Hardware auslesen und die jeweils benötigten Pakete nachinstallieren können.
Imho ist das App-Zeug eine Pest – benutzerbasierte Installation von Anwendungen und damit das Benutzerprofil unnötig aufblähen.
@Markus K
Sorry ich hatte gedacht das der Beitrag von Dietmar weiter unten die Lösung ist. Das blöde an der Situation ist das das eine der wenigen Sachen ist die man nicht so gut in der VM nachvollziehen kann. Ich meine aber immernoch das eine GPO die Lösung sein könnte. Bis jetzt ist meine Lösung nicht auf die Universal Treiber zu setzen da die mir zu nervig sind. Für den Audiotreiber hätte ich auch eine ungewöhnliche Lösung. Standardtreiber von Windows, ich installiere schon seit Windows 7 nichts anderes mehr. Auch für SATA oder NVME setze ich immer auf die Standardtreiber von Windows, das erspart bei Upgrades viel Ärger. Gerade die Realtek Audio Treiber haben sich in der Vergangenheit oft als Quelle für sporadische BSOD erwiesen. Unter Windows 10 wird das leider aber auch zunehmend schwerer.
Die letzten 14 Tage aufgrund dieses Artikels das Update der "Intel-Kontrollraum-App" im Store unterbunden – alles gut.
Heute hat der Store Online einen Reset durchgeführt. Alle Standard-Apps wurden neu installiert/initialisiert mit meist lokalen Paketen und die "Intel-Kontrollraum-App" wurde leider unbemerkt mit einer neuen Version aktualisiert!
Die App ist zwar noch da aber nichts lässt sich mehr einstellen!
Multimediales Gerät, toll – und nun?
De/Re-Installation der neuesten Intel-Treiber, zwangsläufig die Aktualisierung der App(nicht im Treiberpaket) – und wieder funktioniert keine Einstellung mehr.
Ist das jetzt die Tour 1909 User auf 20H2 zu zwingen…
Windows 8-10… ist und bleibt der letzte Scheiß!
Gut das ich das alles bis W7 Ende privat komplett ignoriert habe.
—————————————————————————
ASUS Laptop (UEFI, SATA-HD, W10 Home OEM)
Intel® Celeron® N4000/UHD 600 (Gemini Lake, ID "706A1")
Und wenn man nun den Store nicht will so wie wir, dann hat man ein Problem.
Um das Problem nachzustellen brauch man lediglich ein Windows 10 Enterprise 1909 installieren und am besten eine Intel CPU haben.
Wird das Teil der Domäne hinzugefügt ist noch solange alles in Ordnung solange sich niemand lokal anmeldet. Lokaler Admin wird nie benötigt.
Sobald sich ein Benutzer anmeldet entfernt das System selbst die apps die vorher eigentlich korrekt mit dem Treiber mitinstalliert wurden.
Kein Store Zugriff, keine App und im worst case eine schöne Fehlermeldung oder ein nicht funktionales device für Benutzer.
Erstmal danke für die Ausführung. Genau so hätte ich mir das in den Tweets auch gewünscht, so kann man das nachstellen und viel wichtiger vielleicht auch was dabei lernen. Ich finde das Verhalten aber bei gesperrtem Store Zugriff sogar fast logisch. Vielleicht kann man das Verhalten mit einer GPO beinflussen. Auch Apps können Fehler und Sicherheitslücken enthalten, diese nicht zu aktualisieren kommt daher für mich eigentlich nicht in Frage. Gerade mit der Enterprise Version kann ich doch einen eigenen Store betreiben und dort dann auch Apps freigeben und somit App Updates verwalten. Warum nicht diesen Weg gehen? Das soll keine Kritik sein, ich würde einfach nur gerne wissen ob das einfach Mist ist oder warum das keine Option ist. Ich will das eigentlich einführen und da nich sinnlos viel Arbeit inestieren wenn es wohl doch keinen Sinn macht :)
Dafür gibt es sogar einen KB-Artikel inkl. Workaround:
https://docs.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/pre-installed-microsoft-store-app-removed-logon
Wichtig bei der Installation mittels dism ist der Parameter /Region=ALL.
HP und Dell bieten seit Ende des Sommers den Download der Appx-Dateien mit ihren Treibern an. Diese Diskussion gibt es schon länger.
Ja is klar ne :)
Selbst probiert und erfolgreich damit gewesen?
Nein?
Na ich auch nicht :)