Microsoft hat gestern bekanntgegeben, dass alle Kernel-Treiber, die vom veralteten, cross-signierten Root-Programm signiert wurden, nicht mehr zugelassen werden. Dies betrifft Windows 11 24H2, 25H2, 26H1 und Windows Server 2025. Durchgesetzt wird es ab April 2026.
Danach sind dann nur noch die Treiber zugelassen, die in einer Zulassungsliste von Microsoft aufgeführt werden. „Dieses Update trägt zum Schutz unserer Kunden bei, indem es sicherstellt, dass standardmäßig nur Kernel-Treiber geladen werden können, die das Windows Hardware Compatibility Program (WHCP) bestanden haben und signiert wurden.“
„Das Cross-Signed Root-Programm wurde Anfang der 2000er Jahre eingeführt, um die Codeintegrität für Treiber von Drittanbietern auf der Windows-Plattform zu unterstützen und zu gewährleisten…Das von externen Zertifizierungsstellen verwaltete Signaturprogramm verlangte von den Treiberautoren, die privaten Schlüssel des Zertifikats zu speichern und zu schützen, was zu Missbrauch und dem Diebstahl von Anmeldedaten führte, wodurch unsere Kunden und ihre Plattformen gefährdet wurden. Das Programm wurde 2021 eingestellt, und alle Zertifikate sind seitdem abgelaufen. Das Vertrauen in diese Zertifikate hat sich jedoch in bestimmten Anwendungsfällen und Szenarien gehalten. Das ändert sich ab sofort.“
Die neuen Sicherheitsstandards tragen aber auch dazu bei, dass Treiber von Drittanbietern weiterhin als vertrauenswürdig eingestuft werden können. Hierzu hat man eine Vielzahl (Grundlage von Milliarden von Treibern und realen Nutzungsdaten aus den letzten zwei Jahren) an Daten ausgewertet.
Damit alles glatt läuft, hat man einen Bewertungsmodus eingeführt. In dem Zeitraum der Auswertung wird der Kernel-Modus die geladenen Treiber überwachen.
Wer mehr darüber wissen möchte, kann sich den Beitrag von Microsoft durchlesen.
Windows 11 Tutorials und Hilfe
- In unserem Windows 11 Wiki findet ihr sehr viele hilfreiche Tipps und Tricks.
- Falls ihr Fragen habt, dann stellt diese ganz einfach bei uns im Forum.
- Installationsmedien: Aktuelle Windows 11 ISOs findet ihr hier: 25H2 26200. Ansonsten immer in der rechten Sidebar.
- Windows 11 neu clean installieren Tipps und Tricks.
- Windows 11 auch ohne TPM und Secure Boot installieren.
- Windows 11 mit lokalem Konto auch Offline installieren.
- Windows 11 Inplace Upgrade Reparatur oder Feature Update.
- Automatisch anmelden Pin entfernen Windows 11.
- Alle Beiträge zu Windows 11 im Blog findet ihr über diese Seite. Wobei auch alle anderen Artikel interessant sein können.
Die sind inkompetent, anstatt einfach alle Kernel-Treiber in ihrer eigenen Defender-Kernel-Sandbox laufen zu lassen, werden sie zweifellos wieder Fehler einbauen, und bestimmte ältere Hardware wird zukünftig Probleme verursachen. Die verschwenden erneut viel Zeit und Geld, anstatt das Problem von Grund auf anzugehen.
Da soltes du bei den hersteller der treiber nachfragen die nicht neu signieren, und 1 treiber rausbringen und ein update noch den schluss.
Microsoft räum nur auf, was ja alle wollen entschlacken entschlacken ales raus aber wehe es trift den wo den genau den treiber hat oder die veraltete hardware , oder aus geiz ist geil ein 10 jahre altes Programm nicht mehr läuft oh den schreien sie Doofes MS.
inkomtetent öm ne nur entlich aufräumen.
„Microsoft räumt auf….“ der ist echt gut.
Wenn MS aufräumt ist man die nächsten Monate damit beschäftigt alles wieder so zum Laufen zu bringen wie man es SELBER will!
Geht meiner Meinung noch nicht weit genug, Microsoft sollte nachdem Support Ende eines OS auch gleichzeitig alle alten dazugehörigen Treiber streichen.
Damit Leute mit modernen Systemen nicht auf die Rücksicht nehmen müssen die ihren alten Windows Krücken mit Win10 und älter noch mitschleppen.
Naja Windows 10 wird noch mindestens bis 2032 supportet…..
Die Lizenz sollte keine Auswirkung auf die Treibersignatur haben.
Was für ein dummes Geschwätz. Es gibt genug Situationen, wo die Geräte noch offline betrieben werden und der Hersteller den Support für die daran angeschlossenen Systeme eingestellt hat oder nicht mehr existiert. Gerade bei größeren Institutionen und im Forschungsbereich keine Seltenheit. Aber ja, am besten gleich eine digitale Zeitbombe in das System implementieren, deren Ablaufdatum ja mit jedem Update verlängert werden kann. Warum auch nicht alle paar Jahre nicht nur das Betriebssystem, sondern auch die mehrere zehntausend oder hunderttausend € teuren Geräte ersetzen.
Wir haben am Institut auch einige solcher Geräte. Alles was Nicht Windows 11 oder Windows 10 Enterprice ist wurde von den Admins vom Internet und Exchange ausgesperrt. Erlaubt ist nur noch das Speichern auf definierten Freigaben, beispielsweise damit Auswertungen darauf abgespeichert oder eingelesen werden können.
Die Geräte können doch offline Betrieben werden davon redet doch keiner, nur die Uralt Treiber müssen nicht noch über Jahrhunderte in Windows update herumgammeln. Alles was nicht mehr im Support ist weg damit und den Nutzer / Unternehmen die Verantwortung darüber geben das er weiterhin passende Treiber aufbewart hat. Verstehe die Aufregung nicht finde die Aussage von Alex in der Hinsicht sehr richtig.
Wenn ich mir die Datenbank von Windows update und die darin gespeicherten Treiber etc. anschaue wird mir schlecht von Win95 und Win98 angefangen bis zu uralt Office der Mist gehört einfach durchgewischt.
Bin ich nicht dafür. Ich hab zwar einen Kompatiblen PC mit 9900X3D und 9070XT aber ich finds auch ganz Nett dass auf meinem Alten i5 480M Laptop mit ATI HD 6000 Serie Grafik und ohne TPM (16 Jahre Alt mittlerweile) die neuste 26H1 auch noch Perfekt läuft ohne Einschränkungen.
Kostet es Dich Geld, dass MS Treiberdownloads bereithält? Nö.
Herrlich. So wie ich das verstehe werden damit ältere Geräte die offiziell nicht mehr unter Windows 10 / 11 funktionieren, aber es halt trotzdem noch tun, weil die Treiber funktionieren nicht mehr funktionieren, wenn der Hersteller keinen entsprechenden Treiber nachreicht. Sei es, weil Gerät EOL oder der es den Hersteller inzwischen gar nicht mehr gibt.
Wiedermal geplante Obsoleszenz, genau wie es Microsoft mit Windows 11 begonnen hat, sich dann aber Green IT schimpfen wollen.
Ich habe hier einen älteren Desktop-PC, Baujahr ca. 2013, auf dem ich Windows 11 trotz Inkompatibilität der CPU und fehlendem TPM 2.0 installiert habe, und, da hat es bereits bei der Windows-Sicherheit Probleme gegeben, und ein Realtek-Treiber würde blockiert, wegen der Microsoft-Sperrliste. Hab das dann abgeschaltet, aber, die Aussicht, dass es in Zukunft noch mehr solcher Probleme geben wird, ist natürlich weniger als erquickend.
Microsoft fährt wohl seit einiger Zeit den Apple-Weg. Es soll immer mehr Kontroller über die verwendete Hardware ausgeübt werden, was natürlich im Umkehrschluss die oft gelobte (und von mir so gemochte) „Abwärtskompatibilität“ aufhebt, und ältere Hardware schlichtweg obsolet für das Betriebssystem machen. Schade, genau das war, was Windows für mich immer ausgemacht hat: Ein System, welches ich sogar noch auf jedem XP-Rechnern installieren konnte.
Same here! i7-4790K seit der 24H2 auf W11. Lass mich raten der Treiber der geblockt wurde, ist der Realtek HD-Audio Treiber R2.83? Das Teil ist wirklich schon alt und bekam schon ewig kein Update mehr.
Mich würde ja interessieren ob Realtek da nochmal nachlegt unter dem Zwang, oder ob Audio dann ab April wirklich RIP ist. Noch gehts ja mit der Sperrliste zu deaktivieren. Der Ethernet Treiber wird ja aktuell gehalten.
Echt ungeil wieder mal! Betrifft dann sicherlich auch die Intel HD 4600 dann… ?
Hab nochmal nachgeschaut. Es war doch kein Realtek-Treiber, sondern der Treiber „AsIO.sys“. Das Teil stammt von ASUS. Wie der allerdings genau auf das System gekommen ist, weiß ich nicht. Eigentlich hatte ich keine dafür in Frage kommende Software von ASUS (Armoury Crate oder die AI Suite) installiert.
Naja, sei’s drum. Dadurch, dass die Sperrliste deaktiviert ist, ist das Problem ja gelöst. Was in Zukunft ist, müssen wir abwarten.
Der wird durch WU geladen. Ja der stammt von ASUS selbst allerdings (Stand 2015)
Der steuert den Chipsatz, sollte als AsIOx32 und x64 vorliegen. Zu finden unter:
C:-PROGRAMME-ASUS <- (mag kein Backslash setzen hier)
Den zieht sich Windows direkt aus dem WU, den gibts nicht herunter zu laden bei Asus selbst.
In meinem Falle steuert der bei ASUS Z87-C <- Lynxpoint den Chipsatz. Ansonsten tauche immer ein nicht identifizierbares Objekt im Gerätemanager auf (bereits seit W10 so). Das läßt sich aber via Driverstore extraction <- auch manuell forcieren, wenn 1x installiert wurde.
Schön das der auch geblockt wird. Das hat er am 04.10.2024 hier noch nicht gemacht.
Danke dir für die Info. Hab das ASUS Z87-K in dem Rechner.
Schon bizarr, dass Windows einen Treiber blockiert, der direkt aus Windows Update stammt. 😉 Wobei der noch aus Windows 10 stammen dürfte. Hab 10 auf Windows 11 auf dem Rechner upgegradet.
Trotzdem… ganz toll. Wenn der Treiber mal weg ist, kannst du auf dem frei gewordenen Platz mindestens drei Filme speichern…
Hat der Treiber irgendwas gestört? Ich meine, ausser den Interessen vom Microsoft?
Ja und das ist auch endlich mal notwendig!! Weg mit dem alten Treiber Schrott
Ich hab auch noch so ein Prob. mit einem Treiber für meine Soundkarte (Creative SB X-Fi) da gibts leider keine Treiber mehr für Windows 11 und vom Hersteller leider auch keine Unterstützung. Die Soundkarte funzt sehr gut und hat einen Guten Klang warum also entsorgen.
Wir sollen also wieder Müll Produzieren nur weil die Leute das von MS so wollen. Ohje sag ich da nur!
mfg amsel
Die Karte ist mehr als 15 Jahre alt also sich nach der Zeit über mangelnden Treiber Support aufzuregen finde ich schon fast frech.. Wie lange soll Creative den Treiber stellen dafür? Solange bis die restlichen 2 auf der Welt vielleicht irgendwann mal sich dazu bewegen ihre veraltete Hardware zu tauschen.
Und wer sich vor dem Kauf mal informieren würde, wüsste auch das gerade Creative seinen Treiber support sehr kurz hält meist sogar nur für 2 Jahre.
Ich glaube eher, dass gemeint ist, dass es keine expliziten Treiber mehr für Windows 11 gibt, aber die alten Treiber bislang trotzdem noch unter Windows 11 funktionieren, nach der Sperre aber vermutlich nicht mehr und er deswegen die Karte dann wegwerfen muss. Ist genau das, was ich weiter oben ( 27. März 2026 um 11:43 Uhr) schon geschrieben habe.
Also was Realtek betrifft:
Den originalen Treiber auf meinem Board (ALC1150) installiere ich schon als Windows 10 recht „frisch“ auf dem Markt war, weil es da bei benutzen von Multimediaanwendungen ( MP3 – Video – TV- Karten ) immer zu Hardwareabstürzen kam.
Ähnlich ging es mir mit einert separat erworbenen Sounblaster-Karte
Seit ich die Microsoft-eigenen Treiber benutze läuft ALLES einwandfrei, und das bei einem System von ~ 2015 (Anschaffungsdatum)
Asus Sabertooth 990FX R3.0
OctalCore AMD FX-8350, 4200 MHz (21 x 200)
32 GB RAM
EDIT:
Aktuelles BS Windows 11 Pro 25H2
Was mich hauptsächlich interessiert:
Was ist mit Druckern, TV-Karten und oder Scannern?
Man kann zwar im Moment noch über die Registry die Treiber-Sperrliste für die Kernisolierung abschalten.
Aber für wie lange noch?
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/CI/Config]
„VulnerableDriverBlocklistEnable“=dword:00000000
Das ist, soweit ich weiß, was anderes. Hier werden die Treiber direkt in eine Liste eingetragen und gesperrt. Bei der ganzen Geschichte hier geht es nur um Treiber mit einem „cross-singed certificate“. Treiber mit WHCD Zertifikat fallen nicht darunter, aber diese können durchaus auf der Sperrliste landen, wenn Microsoft da ein Problem mit einem spezifischen Treiber hat.
Aber mal abwarten, was passiert, wenn das passende Update kommt. Ich bin mir selber noch nicht einmal sicher, ob ich Treiber mit einem „cross-singed certificate“ habe.
Sehe ich auch so.
Man muss erst mal abwarten.
Tolles Beispiel:
Ich habe einen Uralt-Scanner:
HP 5300 C über USB angeschlossen
Mit dem Treiber von HAMRICK-Software läuft die Büchse immer noch und
die ist schon ein Vierteljahrhundert alt!
Wenn alle Stricke reissen habe ich noch eine VM mit Windows XP und dem Scanner drin…
klingt mir eher wieder nach Pflichtzwang, ein neuer Schritt von Microsoft auf Zwang zu sagen, gebt Geld aus und kauft euch neuere Hardware und schmeißt die alte Hardware in den Müll, quasi ein Dikatat seitens Microsoft um wieder mehr Consumer- und Buisinesskunden zu verprellen
Auf dieser Windows Support Seite wird auch genau beschrieben wie man diesen Mist wieder los wird wenn man betroffen sein sollte. Hoffen wir mal das es dann auch wirklich funktioniert.
https://support.microsoft.com/en-us/windows/the-windows-driver-policy-ecd2a78c-750c-415d-93f2-e37302ce0443
Danke uwelino für den Tipp!
Stellt sich halt nur die Frage, wenn man im BIOS kein Secure-Boot eingeschaltet hat bzw.
diese Option gar nicht erst vorhanden ist, was dann passiert.
Aber da können wir nur auf das Patch Mitte April warten.
Vorsorglich habe ich bei mir laut der Anleitung von MS schon mal die entsprechenden Dateien gelöscht.
Gucken was passiert…
Hallo Jürgen, du konntest solche Dateien bereits löschen wie in der Anleitung beschrieben? Leider gelingt mir das nicht. Die in die PowerShell reinkopierten Befehle von der Microsoft Beschreibung geben mir immer nur Fehlermeldungen zurück. Habe alles so genau gemacht wie dort beschrieben. Ich hatte nun den Verdacht das diese Dateien auf dem Laufwerk erst nach der Installation des April Patches aktiviert werden und deshalb diese Befehle noch nicht funktionieren. Wenn es bei Dir aber bereits geht mache ich wohl was falsch. Hast Du einen Tip für mich ?
Das eine Richtlinie (784C4414…) sollte existieren, sofern SecureBoot aktiviert ist. Die andere Richtlinie (8F9CB695…) wird erst noch aktiviert. Wenn die jetzt schon aktiv wäre, dann würde die Sperre für die Treiber jetzt schon greifen.
Aber was mich wundert, ist der Zusammenhang mit SecureBoot. Wenn SecureBoot deaktiviert ist, greift das alles dann nicht mehr? Das wäre ja dann auch wieder nur halb durchdacht.
Es sei denn, es gibt bald keine Windows-Hardware mehr, auf der ein Windows ohne Secure Boot lauffähig ist. (ヾ(´･ω･｀)
Günter fasst das ziemlich gut zusammen, inwiefern das mit Secure Boot agiert. Vielleicht hilft das weiter?
https://borncity.com/blog/2026/03/28/windows-11-server-2025-blocken-ab-april-2026-cross-signierte-kerneltreiber/
Ja uwelino ich konnte zumindest die Datei ‚{784C4414-79F4-4C32-A6A5-F0FB42A51D0D}.cip‘ löschen.
Man muss in Anführungszeichen nur sich mit takeown und icalcs Zugriffrechte auf die Dateien und Verzeichnisse
verschaffen und dann
(ich habe mir eine Batch-Datei dazu gebastelt, die mit administrativen Rechten ausgeführt werden muss)
lassen sich die Dateien löschen. Der Trusted Installer sperrt sonst den Zugriff.
Vorsicht die Pfadbackslashes fehlen, diese habe ich durch Schrägstriche ersetzt.
@echo off
color f0
cls
echo.
echo Dieses Programm funktioniert auf Computern mit und ohne EFI-Partition.
echo.
echo Bei Computern mit EFI-Partition muss erst das Laufwerk gemountet werden.
echo.
echo.
echo.
echo Wenn Sie bereit sind, dann
echo.
pause
echo Erst wird, wenn vorhanden, eine EFI-Partition als Laufwerk Q: gemountet.
echo Achten Sie darauf, dass der Laufwerkbuchstabe nicht in Verwendung ist.
echo Ist keine EFI-Partition vorhanden, kann die Fehlermeldung dazu ignoriert werden.
echo Dann geht man zum letzten Abschnitt auf Laufwerk C: und bereinigt dort die Dateien.
echo.
echo Wenn Sie bereit sind, dann
echo.
pause
mountvol Q: /S
del /F /Q Q:/EFI/Microsoft/Boot/CiPolicies/Active/{784C4414-79F4-4C32-A6A5-F0FB42A51D0D}.cip
del /F /Q Q:/EFI/Microsoft/Boot/CiPolicies/Active/{8F9CB695-5D48-48D6-A329-7202B44607E3}.cip
mountvol Q: /D
cls
echo.
echo Jetzt geht es in den letzten Abschnitt des Programms.
echo.
echo Wenn Sie bereit sind, dann
echo.
pause
start /min /wait TAKEOWN /F %SYSTEMDRIVE%/Windows/System32/CodeIntegrity /R /D:J /A
start /min /wait TAKEOWN /F %SYSTEMDRIVE%/Windows/System32/CodeIntegrity/CIPolicies /R /D:J /A
start /min /wait TAKEOWN /F %SYSTEMDRIVE%/Windows/System32/CodeIntegrity/CIPolicies/Active /R /D:J /A
start /min /wait TAKEOWN /F %SYSTEMDRIVE%/Windows/System32/CodeIntegrity/CIPolicies/Reserved /R /D:J /A
start /min /wait ICACLS %SYSTEMDRIVE%/Windows/System32/CodeIntegrity /grant Administratoren:f /T /C /Q
start /min /wait ICACLS %SYSTEMDRIVE%/Windows/System32/CodeIntegrity/CIPolicies /grant Administratoren:f /T /C /Q
start /min /wait ICACLS %SYSTEMDRIVE%/Windows/System32/CodeIntegrity/CIPolicies/Active /grant Administratoren:f /T /C /Q
start /min /wait ICACLS %SYSTEMDRIVE%/Windows\System32/CodeIntegrity/CIPolicies/Reserved /grant Administratoren:f /T /C /Q
del /F /Q %SYSTEMDRIVE%/Windows/System32/CodeIntegrity/CIPolicies/Reserved/{784C4414-79F4-4C32-A6A5-F0FB42A51D0D}.cip
del /F /Q %SYSTEMDRIVE%/Windows/System32/CodeIntegrity/CIPolicies/Active/{784C4414-79F4-4C32-A6A5-F0FB42A51D0D}.cip
del /F /Q %SYSTEMDRIVE%/Windows/System32/CodeIntegrity/CIPolicies/Reserved/{8F9CB695-5D48-48D6-A329-7202B44607E3}.cip
del /F /Q %SYSTEMDRIVE%/Windows/System32/CodeIntegrity/CIPolicies/Active/{8F9CB695-5D48-48D6-A329-7202B44607E3}.cip
cls
echo.
echo Auf Laufwerk C: bekommen Sie den Inhalt des Ordners ‚%SYSTEMDRIVE%/Windows/System32/CodeIntegrity/CIPolicies/Active‘ angezeigt.
echo.
echo Die Dateien ‚{784C4414-79F4-4C32-A6A5-F0FB42A51D0D}.cip‘ und
echo.
echo ‚{8F9CB695-5D48-48D6-A329-7202B44607E3}.cip‘ sollten nicht mehr vohanden sein.
echo.
echo Wenn Sie bereit sind, dann
echo.
pause
start Explorer.exe %SYSTEMDRIVE%/Windows/System32/CodeIntegrity/CIPolicies/Active
exit
und zu DK2000
Ja da gebe ich Dir recht… es könnte sein dass bei fehlendem Secure-Boot oder abgeschaltetem Secure-Boot
die ganze Geschichte ad absurdum geführt wurde…
Also…… ich habe in eine kleine ZIP-Datei alles reingepackt, was ich bisher an Informationen
zur geplanten Kernel-Treiber Veränderung seitens MS finden konnte.
Die ZIP-Datei beinhaltet auch einen Registry-Eintrag um diese Geschichte hier abzuschalten:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Config]
„VulnerableDriverBlocklistEnable“=dword:00000000
Des Weiteren ist die Batch-Datei ‚Hilfsdatei_Policy_Kernisolierung_beenden.bat‘ mit drin.
Der Link bei MagentaCloud dazu lautet:
https://magentacloud.de/s/McDi7J6xjsr8Y4P
Um aber auch hier den Forenregeln ein wenig genüge zu tun, extra ein Hinweis:
Fehlerhafte Registry-Einträge können das Betriebssystem unbrauchbar machen.
Des Weiteren sind die Batch-Dateien nur mit administrativen Rechten ausführbar.
Die Nutzung der Dateien geschieht auf eigene Gefahr!
Hallo Jürgen,
danke für deine Mühe. Habe die Dateien ausprobiert und dabei ein Problem festgestellt. Der von Microsoft auf der Support Seite selbst angegebene zum löschen vorgesehene Pfad del S:\EFI\Microsoft\Boot\CiPolicies\Active\{784C4414-79F4-4C32-A6A5-F0FB42A51D0D}.cip löst wenn er erfolgreich entfernt wurde unter Windows Update / Apps Probleme aus. Danach lassen sich bei den Apps keine Sprachpakete mehr installieren. Alle Update Versuche enden immer mit einem Fehlercode. Das Diensprogramm sfc /scannow findet beim scan exakt diesen Pfadfehler und stellt ihn wieder erfolgreich her. In der Log.Datei wird es genau so protokoliert. Danach funktioniert sofort das Update wieder. Habe dies jetzt zwei mal gemacht. Ergebnis ist immer gleich. Ich denke da gibt einem Microsoft wieder Empfehlungen die sie selbst noch nicht richtig getestet haben.
@ uwelino
Tut mir echt leid das zu hören, aber ich habe auch nur die Anweisungen von Microsoft
erst mal ‚händisch‘ befolgt.
Danach habe ich dann das Batch-Skript dazu verfasst!
Aber das ist natürlich Berufsrisiko.
Du hast recht …. Microsoft hat das Ganze wohl wirklich noch nicht voll ausgetestet…
Frage: Hast Du eigentlich mal rumprobiert was mit der Secure-Boot Geschichte im BIOS ist?
Ach, ich warte jetzt einfach mal ab, was passieren wird. Keine Ahnung, ob ich auf dem Tablet irgendwas cross-signiert ist. Sieht aber alles nach WHDC aus. Also scheine ich da gute Karten zu haben, dass das Teil weiter läuft.
Hallo Jürgen, habe 2 Rechner mit Windows 11. Habe nun auch auf dem zweiten Rechner den Batch-Skript laufen lassen. Auch den Reg.Eintrag habe ich hinzugefügt. Auch auf dem anderen Rechner kommt es zum selben Problem wie oben bereits beschrieben. Danach kommt es im App Bereich zu Updateproblemen. Wir danach mittels sfc /scannow der Fehler gefunden und wiederhergestellt (S:\EFI\Microsoft\Boot\CiPolicies\Active\{784C4414-79F4-4C32-A6A5-F0FB42A51D0D}.cip) ist alles wieder OK. Der fehlende andere Pfad löst keine Probleme aus und wird danach auch nicht als Fehler erkannt. Secure-Boot ist bei meinen Rechnern standardmäßig deaktiviert und ich habe auch nicht vor das zu ändern. Es sind ja schon erste Secure-Boot Updateprobleme durch Microsoft in letzter Zeit bekannt geworden. Ich lasse beide Rechner jetzt mal auf dem Stand mit Hilfe deines Batch-Skriptes (und der dnach erfogten Wiederherstellung des einen Pfades) und warte ab was Microsoft im April verzapfen wird.
Nochmal Danke für Deine freundliche Arbeit.
@uwelino
Immer wieder gerne.
Zur Info … Ich war mal bis 09.2025 bei drwindows.de 16 Jahre mit drin,
hatte aber dann keinen Bock mehr.
Ich mache auch schon seit meinen 13. Lebensjahr (1979) EDV (Microschrott)…….
Also ich habe mittlerweile 3 unsignierte bzw. Cross Signed Driver bei mir gefunden.
1. Soundkarte ASUS Xonar D1
2. HP Scanjet 5300 C
3. Eine Uralt Intel Management Engine Software und deren Treiber. I7 CPU 1. Generation…
Des Weiteren hätte ich doch gerne von uwelino gewusst um welche Apps, bzw. Sprachpaketdateien
es sich dabei gehandelt hat. Ich mache bei mir auf den Testgestell-PCs
die Updates eh immer nur manuell.
Hauptsächlich geht es mir dabei um die von MS bzw. Deskmodder bereitgestellten Sicherheitspatches
KB__BLA_BLA_BLA……
Apps z.B. aus dem MS Store nutze ich gar nicht!!!
Generell alle Apps aus dem Microsoft Store wobei die Updates alle direkt über den Microsoft Store eingespielt werden. Habe dann sofort nach dem eingeblendeten Fehlercode gegoogelt. Laut Google entsprach dieser Fehlercode Error code: 0x80073D01 Fehlern beim Update von Sprachpaketen der jeweiligen App kommt. Google gibt diese Erklärung dazu ab: Der Windows Update-Fehler 0x80073D01 (oft verbunden mit App-Installationen oder Sprachpaketen) bedeutet meist ERROR_DEPLOYMENT_BLOCKED_BY_POLICY, d.h. eine Richtlinie blockiert die Installation, oder der Speicherort ist falsch. Kam zum Beispiel vor bei allen Spiele Apps aus der Candy Crush Serie.
Wie schon oben erwähnt sobald der Pfad S:\EFI\Microsoft\Boot\CiPolicies\Active\{784C4414-79F4-4C32-A6A5-F0FB42A51D0D}.cip) wiederhergestellt wurde ist wieder alle fehlerfrei.
Diese Datei 784C4414-79F4-4C32-A6A5-F0FB42A51D0D}.cip in der EFI-Partition
überwacht nur dir Treibersignierung
und übernimmt auch andere Funktionen. So viel weiss ich jetzt mittlerweile.
Deshalb muss die Datei wohl stehen bleiben.
Was aber passiert, wenn man die Datei drin lässt und nur unter dem c:/Windows/….-Pfad löscht,
das hattest Du, uwelino ja bereits herausgefunden.
bleibt nur zu hoffen, dass der Rest von Microsoft´s Angaben stimmt!
Es bleibt also nur abzuwarten.
MS erklärt die Datei 784C4414-79F4-4C32-A6A5-F0FB42A51D0D}.cip als Evaluation Mode Datei.
Die andere Datei {8F9CB695-5D48-48D6-A329-7202B44607E3}.cip‘
dient als enforcement, sprich als tatsächlicher Blockierer von
nicht signierten bzw. ‚Cross signed‘ Treibern.
Ich werde mal versuchen das Skript so abzuändern,
dass die Datei 784C4414-79F4-4C32-A6A5-F0FB42A51D0D}.cip in der EFI-Partition stehen bleibt.
Was für Auswirkungen das hat, da kann man echt nur den 14.04.2026 abwarten.
Der Link ist der selbe https://magentacloud.de/s/McDi7J6xjsr8Y4P
Eine signierte CIPolicy einfach löschen??? Geht es dir noch ganz gut???
Selbst ohne Bitlocker wird das System danach nicht mehr booten. Lese doch einfach mal die Dokumentation, dann wüsstest du, dass man eine signierte Policy niemals löschen, sondern nur durch eine andere ersetzen kann, die vom gleichen Herausgeber signiert wurde. (und in der neuen Policy kann man dann das unerwünschte Verhalten abschalten)
Ja, uns geht es gut. Hat Microsoft so beschrieben. Einfach löschen und gut. Vorher aber SecureBoot deaktivieren und im Anschluss wieder aktivieren.
Was soll denn die Behauptung, dass das BS danach nicht mehr bootet…
Ich habe es auf einer Büchse die im BIOS (schon immer) ein abgeschaltetes Secure-Boot hat,
ausprobiert und die Datei
{784C4414-79F4-4C32-A6A5-F0FB42A51D0D}.cip in der EFI-Partition und auf LW C:
im entpsrechenden Windows Ordner
gelöscht
und der Computer bootet immer noch ganz brav.
Klar
wie schon von uwelino beschrieben, was passiert wenn man die Datei in der EFI-Partition löscht.
Dann funktionieren Updates von MS-Store Apps Sprachpaketen nicht mehr.
Aber das ist ein anderes Thema… Booten tut die Büchse dan trotzdem noch.
Was die 100 Stunden-Sache anbetrifft, da weiss ich auch noch nix…
#estanio
*lol* und wie soll sonst ein BIOS-Reset funktionieren?
Klar, ist das alles ohne Probleme löschbar.
Ja, uns geht es absolut gut. Diese Vorgehensweise wird exakt so von Microsoft auf deren Support Seite beschrieben. Das kommt hochoffiziell so von Microsoft. Einfach noch mal selber auf deren Seite https://support.microsoft.com/en-us/windows/the-windows-driver-policy-ecd2a78c-750c-415d-93f2-e37302ce0443 unter „Wie deaktiviere ich die Windows-Treiberrichtlinie „.
Witzig finde ich, dass das gemountete Laufwerk, ich meine die EFI-Partition,
(immerhin mit dem Bootsatz ausgestattet) keinerlei rechtliche Einschränkungen beim Dateizugriff aufweist.
Aber DK2000, du hast schon wieder recht, vor Mitte April reden wir hier über ungelegte Eier.
Wir müssen abwarten, was das neue Sicherheitspatch wirklich an Einschränkungen mit sich bringt.
Die Batch-Datei und Registry-Einträge sind halt nur eine Lebensversicherung für mich.
Der kluge Mann baut vor!
Du weisst doch: Ich traue den Mitarbeitern von Microsoft so weit ich sie werfen kann
und meine Schulter ist ziemlich ausgekugelt…
Ganz großes Augenzwinkern….LOL
Die EFI-Partition hat da keine großen Einschränkungen, was den Zugriff angeht. Die verwendet ja FAT32.
Wie kann man rausfinden welcher Treiber unter Win 11 cross-signiert ist? Mir macht vor allem meine Creative SB-X Fi Sorge. Diese tolle Soundkarte will ich auf keinen Fall ersetzen müssen.
Schönen Sonntag allen hier.
Ich weiß nicht ob es funktioniert, aber, du kannst das hier mal versuchen: https://techcommunity.microsoft.com/blog/windows-itpro-blog/advancing-windows-driver-security-removing-trust-for-the-cross-signed-driver-pro/4504818/replies/4506421
Oder das hier: https://techcommunity.microsoft.com/blog/windows-itpro-blog/advancing-windows-driver-security-removing-trust-for-the-cross-signed-driver-pro/4504818/replies/4506362
HAMRICK Software (für USB-Scanner) hat mir gerade zurückgemailt,
dass man wohl keinen Plan habe, wie man denn weiter vorgeht.
Man werde wohl den Support für Windows einstellen und nur noch macOS und Linux supporten!
Zitat Ed Hamrick:
I don’t have a plan. I guess we’ll stop supporting Windows and will only support macOS and Linux.
Hat schon jemand herausgefunden, wie man den Evaluierungszeitraum vorzeitig beendet? (z.B Registry-Eintrag mit bisheriger Laufzeit)
Die 100 Stunden für ein Test-System lasse ich mir ja noch gefallen, aber bei einem frisch installierten Produktivsystem will doch niemand 100 Stunden zusätzlich warten, bevor es „sicher“ wird.
Eine Sache steht für mich schon von vorne herein fest.
Ich werde beide .CIP Dateien
{784C4414-79F4-4C32-A6A5-F0FB42A51D0D}.cip
{8F9CB695-5D48-48D6-A329-7202B44607E3}.cip
oder wie auch immer diese in Zukunft heissen werden,
von meinen Computern aus allen Verzeichnissen und Partitionen löschen. Rigoros!
Die Sprachpakete für irgendwelche Apps aus dem MS-Store interessieren mich dabei herzlich wenig.
Die Nutzung der inzwischen doch 4 gefundenen Geräte, die alle nur `Cross signed` Treiber haben,
ist mir wichtiger als alles andere.
Wenn irgend ein Update doch mal scheitern sollte, gibt es immer noch den Befehl dism und sfc /scannow.
Damit kann man aus dem Komponentenspeicher C:/Windows/WinSxS die 2 o. g. Dateien wiederherstellen.
Ende vom Song!!!
Und
BÄÄÄÄÄÄÄÄÄÄÄÄÄÄHM!!!
btw: Die Sprachpakete für irgendwelche Apps aus dem MS-Store interessieren mich dabei herzlich wenig..
Nicht nur für Apps! – und einfach wird das sicher nicht werden.
https://apps.microsoft.com/detail/9P6CT0SLW589?hl=de-de&gl=DE&ocid=pdpshare
Meine Windows Installationen sind grundsätzlich keine ‚von der Stange‘.
Ich nutze von uupdump die CustomAppsList.txt und schmeiße nahezu alles raus.
Microsoft.WindowsCalculator_8wekyb3d8bbwe
Microsoft.WindowsTerminal_8wekyb3d8bbwe
MicrosoftWindows.Client.WebExperience_cw5n1h2txyewy
Microsoft.WindowsCamera_8wekyb3d8bbwe
Microsoft.SecHealthUI_8wekyb3d8bbwe und der MS Defender
Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
bleiben drin.
Der Rest geht in die Tonne. So habe ich ein nahezu nacktes
und sehr wohl
ein sehr gut funktionierendes Betriebssystem ohne den ganzen Schnickschnack.
Das Local Experience-Pack (deutsch) habe ich noch nie vermisst!
Die Grundfunktionen sind auch weiterhin gegeben!
Eigentlich ist die ganze Aufregung um das Thema umsonst, denn laut Günter Born sieht es wie folgt aus.
Übergang zur Blockierung unsignierter ‚Cross Signed‘ Treiber ab dem 14.04.2026.
Um diesen Übergang so reibungslos wie möglich zu gestalten, wird die neue Kernel-Vertrauensrichtlinie
ab dem 14. April 2026 allerdings nur im Evaluierungsmodus für Windows 11 24H2, 25H2, 26H1
und Windows Server 2025 eingeführt. Im Evaluierungsmodus überwacht und überprüft
der Windows-Kernel alle geladenen Treiber.
Ziel ist es, festzustellen, ob die neue Vertrauensrichtlinie sicher aktiviert werden kann,
ohne Kompatibilitätsprobleme durch die Blockierung kritischer, cross-signed Treiber zu verursachen.
Ein System verbleibt so lange im Evaluierungsmodus, bis alle nachfolgenden Evaluierungskriterien erfüllt sind:
Durch die Festlegung von zwei unterschiedlichen Bewertungskriterien will Microsoft sicherstellen,
dass eine vielfältige Auswahl an Treibern in Start- und Laufzeitszenarien geprüft
und korrekt bewertet wird, bevor die Funktion aktiviert wird.
Sobald alle Bewertungskriterien erfüllt sind, entscheidet die Funktion anhand
der im Bewertungsmodus geladenen Treiber, ob das System die Richtlinie aktivieren soll:
Wurden alle während des Bewertungszeitraums geladenen Treiber von der Kernel-Richtlinie
als vertrauenswürdig eingestuft, aktiviert das System die neue Kernel-Vertrauensrichtlinie
und setzt sie durch.
Systeme mit durchgesetzter Kernel-Vertrauensrichtlinie sind nun vor nicht
vertrauenswürdigen Treibern aus dem Cross-Signed-Programm geschützt,
wenn sie nicht mehr der Kernel-Vertrauensrichtlinie entsprechen.
Diese Treiber werden auf Systemen mit durchgesetzter Kernel-Vertrauensrichtlinie
an der Ausführung gehindert.
Da hier ist der entscheidende Abschnitt:
________________________________________________________________________________
Wird während des Testzeitraums ein Cross-Signed-Treiber geprüft und es wird festgestellt,
dass dieser Cross-Signed-Treiber die neue Kernel-Vertrauensrichtlinie nicht erfüllt,
aktiviert Windows die Richtlinie nicht. (Gemeint ist die Blockier-Richtlinie)!
Die Prüfung verbleibt im Evaluierungsmodus (Testmodus) und der als Kriterium
erwähnte Testzeitraum (100 Std.) wird zurückgesetzt. Das System bleibt im Testmodus,
bis die Treiber, die die Aktivierung blockieren, nicht mehr bei der Prüfung gefunden werden.
__________________________________________________________________________
Der Evaluierungsmodus stellt sicher, dass Systeme, die nicht vertrauenswürdige,
cross-signed Treiber für legitime, seltener auftretende Szenarien verwenden,
nicht von einer systemweit durchgesetzten Richtlinie betroffen sind.
Gleichzeitig wird die Richtlinie auf Systemen, bei denen die Treiberkompatibilität
von der Richtlinie nicht beeinträchtigt wird, durchgesetzt,
um die Angriffsfläche des Kernels zu verringern und die Sicherheit zu verbessern.