Am 14. Juli (zweiter Dienstag im Monat, Patchday bei Microsoft) hat Microsoft kumulative Updates für die noch unterstützten Client-Betriebssystem-Versionen von Windows 10 (mit ESU-Lizenz) und Windows 11 veröffentlicht. Hier einige Details zu diesen Updates, die Schwachstellen sowie Probleme beheben sollen.
Details zu den per Updates geschlossenen Sicherheitslücken sind im Beitrag Microsoft Security Update Summary (14. Juli 2026) beschrieben.
Updates für Windows 11
Eine Liste der Windows 11 Updates lässt sich auf dieser Microsoft-Webseite abrufen. Ich habe nachfolgend die Details herausgezogen. Für die oben erwähnten Windows 11 Version stellt Microsoft nun folgende Updates bereit.
Update KB5101650 für Windows 11 24H2-25H2
Das kumulative Update KB5101650 für Windows 11 24H2-25H2 beinhaltet Qualitätsverbesserungen sowie Sicherheitspatches. Mit diesem Update werden verschiedene Sicherheitsverbesserungen an internen Betriebssystemfunktionen vorgenommen. Microsoft listet im Supportbeitrag einige Details zu Fixes, u.a. folgende, auf.
- [Secure Boot] This update includes additional high confidence device targeting data, increasing coverage of devices eligible to automatically receive new Secure Boot certificates. Certificate deployment via Windows updates continues
- [Apps (Known issue)] Fixed: This update addresses an issue that affects certain third-party apps that use OLE Automation to interact with Microsoft Office. After installing the June 2026 security update (KB5094126), these apps might fail to launch Office or open documents.
- [Input] This update changes hotkey unregister and cleanup behavior. In rare cases, some built-in Windows experiences that rely on previous hotkey lifecycle behavior might temporarily stop responding to certain keyboard shortcuts. This issue can typically be resolved by restarting the app affected. If the issue is not resolved, report it through the Feedback Hub.
- [Networking] This update introduces a security hardening change that enforces TDI transport registration requirements. As a result, applications that use sockets over unregistered third-party TDI transports might stop working after installing this update. Registered TDI transports are not affected. For more information, see Third-party TDI transports might stop working after installing Windows security updates released on or after July 14, 2026.
- [Security] This update upgrades the curl tool in Windows to version 8.21.0 and includes security improvements that help protect your device.
- [Remote Desktop (RDP) Security] Support for SHA-2 certificate thumbprints has been added for trusted RDP publishers, with SHA-1 support retained only for backward compatibility and planned for future removal. New guidance is available for managing RDP file security through Group to help organizations reduce phishing risks by controlling which .rdp files users can open. We recommend IT administrators migrate to SHA-256 thumbprints or a stronger algorithm as soon as possible to avoid disruption.
Auch die AI-Komponenten werden aktualisiert. Dieses Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog und per WSUS sowie WUfB erhältlich. Im Patch ist das Windows 11 Servicing Stack Update integriert. Vom Update ggf. verursachte Probleme sind im Support-Beitrag aufgeführt.
Update KB5099414 für Windows 11 23H2
Das kumulative Update KB5099414 für Windows 11 23H2 Enterprise und Education beinhaltet Qualitätsverbesserungen sowie Sicherheitspatches.
- [Secure Boot] This update includes additional high confidence device targeting data, increasing coverage of devices eligible to automatically receive new Secure Boot certificates. Certificate deployment via Windows updates continues across supported PCs and non-managed business devices in the coming months.
- [Apps (Known issue)] Fixed: This update addresses an issue that affects certain third-party apps that use OLE Automation to interact with Microsoft Office. After installing the June 2026 security update (KB5093998), these apps might fail to launch Office or open documents.
- [Country and Operator Settings Asset (COSA)] This update brings profiles up to date for certain mobile operators.
- [File Explorer (known issue)] Fixed: An issue where the OneDrive shortcut in File Explorer stops working when File Explorer is run with administrative mode.This issue might occur after installing the June 2026 security update (KB5093998).
- [Input] This update changes hotkey unregister and cleanup behavior. In rare cases, some built-in Windows experiences that rely on previous hotkey lifecycle behavior might temporarily stop responding to certain keyboard shortcuts. This issue can typically be resolved by restarting the app affected. If the issue is not resolved, report it through the Feedback Hub.
- [Networking] This update introduces a security hardening change that enforces TDI transport registration requirements. As a result, applications that use sockets over unregistered third-party TDI transports might stop working after installing this update. Registered TDI transports are not affected. For more information, see Third-party TDI transports might stop working after installing Windows security updates released on or after July 14, 2026.
- [Recycle Bin (known issue)] Fixed: This update addresses an issue where the confirmation dialog might display an internal Recycle Bin file name instead of the original file name when permanently deleting a file. This issue might occur after installing the June 2026 security update (KB5093998).
- [Security] This update upgrades the curl tool in Windows to version 8.21.0 and includes security improvements that help protect your device.
- [Remote Desktop (RDP) Security] Support for SHA-2 certificate thumbprints has been added for trusted RDP publishers, with SHA-1 support retained only for backward compatibility and planned for future removal. New guidance is available for managing RDP file security through Group to help organizations reduce phishing risks by controlling which .rdp files users can open. We recommend IT administrators migrate to SHA-256 thumbprints or a stronger algorithm as soon as possible to avoid disruption.
Dieses Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog und per WSUS sowie WUfB erhältlich. Im Patch ist das Windows 11 Servicing Stack Update integriert. Bekannte, vom Update ggf. verursachte Probleme werden, im Support-Beitrag aufgeführt.
Windows 11 23H2 Home und Pro sind aus dem Support gefallen und haben zum 11. November 2025 letztmalig ein Update erhalten.
Updates für Windows 10
Windows 10 22H2 ist im Oktober 2025 aus dem Support gefallen und es gibt nur noch Updates im ESU-Programm. Eine Liste der Updates lässt sich auf dieser Microsoft-Webseite abrufen. Ich habe nachfolgend die Details herausgezogen.
Update KB5099539 für Windows 10 Version 21H2 – 22H2
Das kumulative Update KB5099539 enthält diverse Sicherheitsfixes und ist für Windows 10 21H2 Enterprise LTSC sowie ESU-Maschinen mit 22H2 verfügbar. Als Fixes listet der Supportbeitrag folgendes auf:
- [OLE Automation (known issue)] Fixed: Addresses a compatibility issue in OLE Automation (oleaut32.dll) that was introduced by the June 2026 security update. Some applications that use the IDispatch::Invoke method to call COM methods with BYREF parameters that share the same underlying storage might fail. These failures can include parameter marshaling errors or automation call failures. This update corrects how parameter ownership is managed and restores expected application behavior.
- [File Explorer (known issue)] Fixed: An issue where the OneDrive shortcut in File Explorer stops working when File Explorer is run with administrative mode.
- [Recycle Bin (known issue)] Fixed: This update addresses an issue where the confirmation dialog might display an internal Recycle Bin file name instead of the original file name when permanently deleting a file.
- [Input] This update changes hotkey unregister and cleanup behavior. In rare cases, some built-in Windows experiences that rely on previous hotkey lifecycle behavior might temporarily stop responding to certain keyboard shortcuts. This issue can typically be resolved by restarting the app affected. If the issue is not resolved, report it through the Feedback Hub.
- [Secure Boot]
- This update enables dynamic status reporting for Secure Boot states in Windows Security App.
- This update includes additional high confidence device targeting data, increasing coverage of devices eligible to automatically receive new Secure Boot certificates. Certificate deployment via Windows updates continues across supported PCs and non-managed business devices in the coming months.
- [Networking] This update introduces a security hardening change that enforces TDI transport registration requirements. As a result, applications that use sockets over unregistered third-party TDI transports might stop working after installing this update. Registered TDI transports are not affected. For more information, see Third-party TDI transports might stop working after installing Windows security updates released on or after July 14, 2026.
- [Remote Desktop (RDP) Security] Support for SHA-2 certificate thumbprints has been added for trusted RDP publishers, with SHA-1 support retained only for backward compatibility and planned for future removal. New guidance is available for managing RDP file security through Group Policy to help organizations reduce phishing risks by controlling which .rdp files users can open. We recommend IT administrators migrate to SHA-256 thumbprints or a stronger algorithm as soon as possible to avoid disruption.
Microsoft weist darauf hin, dass dieses Update Qualitätsverbesserungen am Servicing Stack (ist für Microsoft Updates verantwortlich) durchführt. Dieses Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog und per WSUS sowie WUfB erhältlich. Beachtet die ggf. im Support-Beitrag beschriebene Hinweise zur Installation und zu ggf. bekannten Problemen.
Update KB5099538 für Windows 10 Enterprise 2019 LTS
Das kumulative Update KB5099538 (wird unter Windows 10 v1809 einsortiert, bezieht sich aber auf Windows 10 2019 Enterprise LTSC und IoT Enterprise LTSC) und beinhaltet Sicherheitsfixes sowie folgende Korrekturen.
- [Input] This update changes hotkey unregister and cleanup behavior. In rare cases, some built-in Windows experiences that rely on previous hotkey lifecycle behavior might temporarily stop responding to certain keyboard shortcuts. This issue can typically be resolved by restarting the app affected. If the issue is not resolved, report it through the Feedback Hub.
- [Secure Boot]
- This update enables dynamic status reporting for Secure Boot states in Windows Security App.
- This update includes additional high confidence device targeting data, increasing coverage of devices eligible to automatically receive new Secure Boot certificates. Certificate deployment via Windows updates continues across supported PCs and non-managed business devices in the coming months.
- [File Explorer (known issue)] Fixed: An issue where the OneDrive shortcut in File Explorer stops working when File Explorer is run with administrative mode.
- [Networking] This update introduces a security hardening change that enforces TDI transport registration requirements. As a result, applications that use sockets over unregistered third-party TDI transports might stop working after installing this update. Registered TDI transports are not affected. For more information, see Third-party TDI transports might stop working after installing Windows security updates released on or after July 14, 2026.
- [OLE Automation (known issue)] Fixed: Addresses a compatibility issue in OLE Automation (oleaut32.dll) that was introduced by the June 2026 security update. Some applications that use the IDispatch::Invoke method to call COM methods with BYREF parameters that share the same underlying storage might fail. These failures can include parameter marshaling errors or automation call failures. This update corrects how parameter ownership is handled and restores expected application behavior.
- [Recycle Bin (known issue)] Fixed: This update addresses an issue where the confirmation dialog might display an internal Recycle Bin file name instead of the original file name when permanently deleting a file.
- [Remote Desktop (RDP) Security] Support for SHA-2 certificate thumbprints has been added for trusted RDP publishers, with SHA-1 support retained only for backward compatibility and planned for future removal. New guidance is available for managing RDP file security through Group Policy to help organizations reduce phishing risks by controlling which .rdp files users can open. We recommend IT administrators migrate to SHA-256 thumbprints or a stronger algorithm as soon as possible to avoid disruption.
Das Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog, per WSUS und WUfB erhältlich. Microsoft hat zudem das Service Stack Update (SSU) aktualisiert. Beachtet die im Support-Beitrag beschriebene Installationsvoraussetzungen und Hinweise auf eventuell vorhandene Probleme.
Update KB5099535 für Windows 10 Version 1607
Für Windows 10 1607 Enterprise LTSC steht das Update KB5099535 zur Verfügung. Dieses Update adressiert Sicherheitsprobleme sowie die beschriebenen Korrekturen, wird automatisch von Windows Update heruntergeladen und installiert, steht aber auch im Microsoft Update Catalog als Download zur Verfügung (nach der KB-Nummer suchen lassen). Vor der manuellen Installation muss das aktuellste Servicing Stack Update (SSU) installiert werden. Details sind im jeweiligen KB-Artikel zu finden.
Für die restlichen Windows 10 Versionen gab es kein Update, da diese Versionen aus dem Support gefallen ist. Details zu obigen Updates sind im Zweifelsfall den jeweiligen Microsoft KB-Artikeln zu entnehmen.
Ähnliche Artikel:
Microsoft Security Update Summary (14. Juli 2026)
Patchday: Windows 10/11 Updates (14. Juli 2026)
Patchday: Windows Server-Updates (14. Juli 2026)
Patchday: Microsoft Office Updates (14. Juli 2026)
Exchange Server: Sicherheitsupdates 14. Juli 2026
Dell Windows 11-PCs zeigt mit Update KB5095093 Leistungsprobleme
Windows Papierkorb-Bug mit Juli 2026-Update behoben
MVP: 2013 – 2016
NET Framework Updates gab es auch:
für 21H2 LTSC:
KB5101000 – NET Framework 3.5 und 4.8.1
für 24H2:
KB5100998 – NET Framework 3.5 und 4.8.1
für 25H2:
KB5100998 – NET Framework 3.5 und 4.8.1
—
NET-Updates:
Microsoft .NET Desktop Runtime 8.0.29
Microsoft ASP.NET Core Runtime 8.0.29
*ttps://dotnet.microsoft.com/en-us/download/dotnet/8.0
Microsoft .NET Desktop Runtime 9.0.18
Microsoft ASP.NET Core Runtime 9.0.18
*ttps://dotnet.microsoft.com/en-us/download/dotnet/9.0
Microsoft .NET Desktop Runtime 10.0.10
Microsoft ASP.NET Core Runtime 10.0.10
*ttps://dotnet.microsoft.com/en-us/download/dotnet/10.0
—
Safe OS (für WinRE):
KB5099548 – Safe OS – Windows 10 Version 1607
KB5099549 – Safe OS – Windows 10 Version 1809
KB5099550 – Safe OS – Windows 10 Version 21H2
KB5099551 – Safe OS – Windows 11 Version 23H2
KB5101719 – Safe OS – Windows 11 Version 24H2
KB5101719 – Safe OS – Windows 11 Version 25H2
KB5101717 – Safe OS – Windows 11 Version 26H1
KB5099552 – Safe OS – Windows Server 21H2
KB5099546 – Safe OS – Windows Server 24H2
—
Anmerkung :
Da ich die Updates manuell mittels dism installiere, ist mir aufgefallen, dass die ASR-Features (Attack Surface Reduction) des Defender einen Fehler verursachen.
Falls das Feature c0033c00-d16d-4114-a5a0-dc9b3a7d2ceb
(= "Blockieren der Verwendung kopierter oder imitierter Systemtools") auf 1 gesetzt ist, dann zeigt dism folgenden Fehler bei der Integration des Servicing Stack Updates SSU-19041.7546-x64.cab in die WinRE:
Error: 0x80070005
Fehler 5
Zugriff verweigert
und in den Logs stehen zahlreiche Fehler:
C:\Windows\Logs\CBS\CBS.log
C:\Windows\Logs\DISM\dism.log
Wegen dieser Fehler in den logs habe ich auch einen "sfc /scannow" durchgeführt und es erschien die Meldung:
"Der Windows-Ressourcenschutz hat beschädigte Dateien gefunden und erfolgreich repariert."
Es gab also vorher schon auch versteckte Fehler bei der Installation des normalen Rollups, obwohl dism in der Konsole keine Fehler anzeigte bei KB5099539 (21H2).
Es betrifft also nicht nur das SSU und nicht nur die WinRE, aber der Fehler wurde ausdrücklich nur bei der letzteren Kombination in der Konsole angezeigt, sonst hätte ich das beim Rollup vorher gar nicht gemerkt, denn das lief "scheinbar fehlerfrei" durch, obwohl hinterher Fehler im Log drin standen.
Um den Fehler zu verhindern, muss man im Gruppenrichtlinien-Editor (gpedit.msc),
Administrative Vorlagen (Templates),
Windows-Komponenten,
Microsoft Defender Antivirus,
Microsoft Defender Exploit Guard,
Verringerung der Angriffsfläche (Attack Surface Reduction),
c0033c00-d16d-4114-a5a0-dc9b3a7d2ceb auf 0 setzen
und gpupdate in einer Konsole mit Adminrechten ausführen.
Danach läuft dism fehlerfrei durch.
Man darf die GPO "Verringerung der Angriffsfläche" allerdings nicht Deaktivieren, sondern muss sie Aktiviert lassen, sonst sind sämtliche ASR-Features komplett gelöscht!
Also man soll wirklich nur das einzelne ASR-Feature auf Null setzen, nicht die GPO.
Wenn also jemand ein korruptes System hat und mit "sfc scannow" reparieren kann, dann sollte man mal die aktivierten ASR-Features des Defender überprüfen.
Nachtrag:
In den logs stehen auch Fehler drin wie folgender
"Offline Registry: […] Hive is not mounted at"
Bei dem Update wurde also versucht, eine offline Registry zu mounten und zu patchen, was aber nicht funktionierte.
Ich bezweifle, dass "sfc scannow" diese Fehlerart überhaupt auf dem Schirm hat und reparieren kann, denn sfc kümmert sich nicht um Registry-Inhalte.
Es kann also sein, dass Einträge in der Registry auch nach der sfc-Reparatur weiterhin anders sind als von Microsoft vorgesehen war.
Und bei Windows 10 ist das .NET-Update die KB 5102203.
Und wie üblich wieder bis zum Wochenende warten, bis Microsoft eventuelle Kalauer beseitigt hat?
I can confirm the below advisory from Microsoft, as it affects the laptops we recently bought from Dell (Dell Pro Premiums and Dell Pro Plus):
The July 2026 security update for Windows 11, version 25H2 and Windows 11, version 24H2 (KB5101650) is not available for a limited number of Dell devices with Intel processors due to an incompatibility reported by Dell that can potentially cause unexpected shutdowns, poor performance, increased heat, and battery drain. We are working together with Dell to prevent the affected models from experiencing the issue and plan to release a resolution for affected devices in the coming days.
Guten Morgen,
erste Tests auf 2 Rechnern:
Rechner 1: Hat bei unserem Mail-Programm den Hostnamen vom Server verloren nach dem Reboot – Zufall? Kann ich jetzt leider nicht verifizieren. Kann auch evlt. anderen Grund gehabt haben. Der PC wird kaum genutzt und läuft i.d.R. 24/7
Rechner 2: Setup lief normal durch, beim Neustart von 0 auf 30% zwei mal gezählt, Reboot 30-100%, Reboot – alles OK. Servername vom Mailserver blieb bestehen.
Das wären jetzt mal so die aktuellsten Auffälligkeiten.
Schöne Woche
Sebastian
Hallo
Unser WSUS-Server stellt kein Windos 11 24H2 update zur Verfügung – zu erwarten wäre KB5101650, das er für 25H2 anbietet.
Beobachtet jemand das Selbe?
Gruß
Bei uns sind sowohl 24H2 wie auch 25H2 für x64 vorhanden (KB5101650). Wurden gestern Abend um 19:02 vom WSUS geladen (Sprachen en + de).
unser WSUS hat es heruntergeladen und steht zur Freigabe bereit, nur wir haben intern einen anderen Ablauf was das Patchen der Clients angeht ;-)
Auch bei unserem WSUS ist der Patch vorhanden.
Bei uns ist der Patch im WSUS auch vorhanden.
Hallo,
mein WSUS hat mir das Update in der Variante für x64 und arm64 angeboten (ich hab es mangels 2H24 Installationen dann aber abgelehnt).
Als Produkt wird "Windows 11" angebeben.
Grüße
Haben sich denn schon 24H2-Clients beim WSUS gemeldet und das Update angefordert? Das wird ja nur gezogen, wenn es jemand braucht.
"Haben sich denn schon 24H2-Clients beim WSUS gemeldet und das Update angefordert?"
–> Ja!
"Das wird ja nur gezogen, wenn es jemand braucht."
–> Schwammig formuliert!
1.) Die Info über das Update lädt der WSUS anhand der Auswahl in der Server-Option "Produkte und Klassifizierungen" herunter.
2.) Die Update-Dateien selbst lädt der WSUS erst dann herunter, wenn sie für die Installation genehmigt wurden.
3.) Der WSUS-Client bekommt das Update erst, wenn 1.) und 2.) erfüllt sind. Von den Update-Settings (Registry/GPO) mal abgesehen.
zu:
2.) Die Update-Dateien selbst lädt der WSUS erst dann herunter, wenn sie für die Installation genehmigt wurden.
Nicht ganz korrekt.
Mit jeder Synchronisation werden die Updates vom WSUS Server auch automatisch heruntergeladen.
Der Download der Updates auf dem WSUS Server ist also unabhängig von der Genehmigung.
Nur die Clients laden die Updates erst dann herunter, wenn diese über die WSUS MMC genehmigt wurden.
Nein!
Es ist schon korrekt, das der WSUS die Updates erst herunterlädt, wenn die freigegeben wurden.
Das sieht man gut auf der Übersichtsseite.
Einfach im WSUS auf den Servernamen gehen, da siehst du den Status, wenn ein Update vom WSUS heruntergeladen wird.
Gebe mal ein Update frei und gehen dann auf die o.g. Amsicht.
Dann siehst du, das er da die Updates herunterlädt.
Danke für den Hinweis, soeben überprüft, stimmt und du hast natürlich Recht.
In unserer Umgebung werden die Updates automatisch heruntergeladen, weil wir für definierte Clients (Testgruppe) einen Verteilerring eingerichtet haben, der die Updates über WSUS automatisch bezieht.
In diesem Artikel (h**ps://learn.microsoft.com/en-us/windows/release-health/status-windows-11-25h2#4906msgdesc) schreibt Microsoft:
> To mitigate this issue, the July 14, 2026, Windows security update for Windows 11, version 25H2 and Windows 11, version 24H2 (KB5101650) will not be offered to affected devices while Microsoft works with partners to resolve this issue. Microsoft plans to release a resolution for affected devices in the coming days.
Was ich mich jetzt frage ist, wie das im Rahmen einer WSUS-Umgebung aussieht.
Die kumulativen Windows-Updates werden dort von den Dell-Clients durchaus als notwendig aufgeführt.
Bedeutet das, dass unsere Dell-Clients keine Problembären sind, oder wird das seitens der Windows-Updates erst nach der WSUS-Freigabe, also während der Installation auf dem Client geprüft?
Bei Dell kann man sich den betroffenen (fehlerhaften) Treiber runterladen:
"Treiber für Intel Innovation Platform Framework"
*ttps://www.dell.com/support/home/de-de/drivers/driversdetails?driverid=965d0
Treiber extrahieren ohne zu installieren (Pfad anpassen):
Intel-Innovation-Platform-Framework-Driver_965D0_WIN64_2.2.10203.4_A02_01.EXE /s /e=d:\1\extract
Auf dem DELL-Laptop könnte man jetzt nach den Treiberdateien suchen:
ipf_acpi.sys
ipf_cpu.sys
ipf_lf.sys
ipf_smbus.sys
Falls man diese Treiberdateien auf dem Laptop findet in der identischen oder früheren Version, dann ist das Laptop betroffen und dann sollte man das Rollup dort nicht installieren, sondern erstmal abwarten, bis Microsoft nachbessert.
Eigentlich müsste Lenovo-Laptops ebenfalls betroffen sein, denn der "Intel Innovation Platform Framework" Treiber wird dort ebenfalls installiert:
*ttps://support.lenovo.com/de/de/downloads/ds564967-intel-innovation-platform-framework-processor-participant-driver-for-windows-11-version-22h2-or-later-lenovo-laptops
Ein gefixter Treiber wird wohl mindestens das Datum 15.Juli 2026 haben müssen, es sei denn, Microsoft kann selber die eigenen Funktionen in einer Art Workaround fixen, ohne den Treiber ändern zu müssen.
Alternative:
Man installiert das Rollup auf allen Laptops und schaut danach, wo es knallt.
Dann weiß man ebenfalls, ob man betroffen ist.
Eigentich müsste ein Check auf ipf_cpu.sys ausreichend sein, denn es geht laut Microsoft nur um den " Intel Innovation Platform Framework Processor Participant driver".
"Processor" = CPU = ipf_cpu.sys
In ipf_cpu.inf stehen folgende Hardware-IDs:
VEN_8086&DEV_461D
VEN_8086&DEV_3258
VEN_8086&DEV_A71D
VEN_8086&DEV_7D03
VEN_8086&DEV_AD03
VEN_8086&DEV_641D
Das sind dann also die betroffenen Modelle.
Diese Device-IDs stehen für:
461D = "Intel(R) Dynamic Tuning Technology Extension"
3258 = "Intel(R) Dynamic Tuning Technology Extension"
A71D = "Intel Dynamic Platform and Thermal Framework"
7D03 = "Intel(R) Innovation Platform Framework Processor Participant"
AD03 = "Intel(R) Innovation Platform Framework Processor Participant"
641D = "Intel PantherLake" CPU (alias "Intel Core Ultra 300", Core Ultra 5, Core Ultra 7, Core Ultra X7, Core Ultra 9, Core Ultra X9)
Wenn die Dell-Laptops also eine Intel PantherLake CPU (alias "Intel Core Ultra 300", Core Ultra 5, Core Ultra 7, Core Ultra X7, Core Ultra 9, Core Ultra X9) Prozessor haben, dann sind sie höchstwahrscheinlich betroffen von dem Fehlerbild "unexpected shutdowns, poor performance, increased heat, and battery drain", wenn man das aktuelle Rollup oder das vorhergehende Preview Update installiert.
Microsoft hätte da smit PantherLake auch mal im Klartext selbver reinschreiben können.
Die Frage ist, warum Microsoft überspezifisch nur "Dell" erwähnt, obwohl auch andere Hersteller Pantherlake-CPUs benutzen und auch den "Intel Innovation Platform Framework Processor Participant" Treiber installieren.
Hat Dell den Treiber angepasst oder war Microsoft nur schlampig bei der Erstellung der Liste der betroffenen Geräte?
Eigentlich zählt doch nur das, was im inf-Installer der Treiberdatei drin steht, und da steht nichts von "Dell".
In der Treiber-Signatur (.SYS) stehten auch nur "Intel" und "Microsoft",aber nicht Dell.
Demnach hat Dell den eigentlichen Intel-Treiber NICHT angepasst.
Die .exe des Treiber-Installers hingegen ist von Dell signiert nicht von Intel.
Den Installer hat Dell also irgendwie angepasst, vermutlich weil sie ihr Logo bei der Installation zeigen wollen.
Daraus folgt, dass eigentlich nicht nur Dell-Geräte betroffen sein können, sondern alle Geräte mit PantherLake CPU potentiell betroffen sind.
Eventuell hat aber Dell im UEFI irgendwelche zu scharfen Einstellungen vorgenommen, die die PantherLake CPUs dann überhitzen oder abstürzen lassen?
Dabei macht Dell im UEFI eher das Gegenteil, also stabil und stromsparend einstellen.
Die Erklärung von Microsoft ist meiner Meinung nach unvollständig.
Danke Bolko.
Wenn ich deine Ausführungen richtig interpretiere willst du mir damit sagen, dass diese Aussage von Microsoft
> Windows security update for Windows 11, version 25H2 and Windows 11, version 24H2 (KB5101650) will not be offered to affected devices
nur gilt, wenn Clients direkt bei MS nach Updates suchen?
Und da die Clients bei uns bei unserem WSUS nach Updates suchen, könnten sie die Updates trotzdem erhalten/installieren (wenn ich sie freigebe)?
Das korrekt, die WSUS Intelligenz ist der Benutzer der auf Aprove drückt. Dort gibt es keine weitere Intelligenz.
Also bezüglich Lenovo trifft es bei diesem Treiber dann "nur" bestimmte IDEAPAD/YOGA:
https://download.lenovo.com/pccbbs/mobiles/l2dp06rf.html
Intel Innovation Platform Framework Processor Participant
Support Models
Lenovo 100w Gen4 (Machine Type: 82VK, 82VL)
Lenovo 300w Yoga Gen4 (Machine Type: 82VM, 82VN)
Lenovo 500w Yoga Gen4 (Machine Type: 82VQ, 82VR)
Operating Systems
Windows 11 (22H2 or later)
Version
2.2.10000.20
Hab das in einem separaten Beitrag herausgezogen – siehe Links am Beitragsende.
Das Tool "O&O ShutUp10++" zeigt Änderungen nach der Installation des Rollups (21H2):
"Erfassen von Diagnosedaten deaktivieren" ist aus, Microsoft will also die Edge-Telemetrie wieder anschalten.
"Suche in der Cloud deaktivieren" ist aus, also Cloudsuche wieder eingeschaltet.
Sperren kann man diese Features, deren Status Microsoft über die Registry ändert, durch die GPOs, die durch das Update nicht verändert werden und die Registry-Einstellungen übertrumpfen:
– Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
Microsoft Edge,
"Erforderliche und optionale Diagnosedaten über die Browsernutzung senden": Deaktiviert
– Gruppenrichtlinieneditor (gpedit.msc),
Computerkonfiguration,
Administrative Templates,
Windows-Komponenten,
Suche,
"Cloudsuche zulassen": Deaktiviert
"Websuche nicht zulasen": Aktiviert
Das funktioniert aber doch nur auf Win 11 Pro und höher, oder? Benutzer von Windows Home haben, wenn ich mich recht erinnere, keinen Gruppenrichtlinieneditor bzw. lokale Gruppenrichtlinien zur Verfügung.
In der Bezahlversion erkennt ShutUp Änderungen und stellt sie über einen Dienst automatisch wieder her. Afaik auch bei Home (ohne Gewähr, ich nutze Pro).
Da deskmodder in der Blogroll steht, habe ich deren Artikel genommen:
@https://www.deskmodder.de/wiki/index.php?title=Windows_11_und_10_Home_gpedit_Gruppenrichtlinie_installieren
"Windows 11 und 10 Home gpedit Gruppenrichtlinie installieren
Die Windows 11 Home oder Windows 10 Home hat gegenüber der Windows 11 / 10 Pro und höher mehrere Komponenten, die fehlen. Unter anderem die Gruppenrichtlinien, die über gpedit.msc aufgerufen werden. Aber es gibt eine Möglichkeit ohne Drittanbieter-Tools diese Gruppenrichtlinien ganz einfach nachzuinstallieren.
Dafür wird nur eine Batchdatei benötigt, die die Komponenten aus dem Ordner C:\Windows\servicing\Packages installieren. Trotzdem erstellt vorab ein Backup vom System zur Sicherheit. Wie es geht, zeigen wir euch jetzt. …
[Update 2.03.2024]: Benny hat das Script für die neueren Windows 11 Versionen noch einmal überarbeitet und hat das Script dementsprechend angepasst. Den Downloadlink dazu findet ihr im neuen Beitrag. …" =
@https://www.deskmodder.de/blog/2024/03/02/windows-11-23h2-home-gruppenrichtlinien-gpedit-hyper-v-oder-sandbox-installieren-aktivieren-neues-skript/
-> Neuer Download: … Die zip-Datei herunterladen und alles wie beschrieben durchführen.
@Bolko
Danke für die Info!
Windows 10 ESU (22H2)
Update KB5099539 für x64-Systeme produziert Fehlerkode 0x800706be.
Zitat von Learn Microsoft: "The error code 0x800706be is a Windows error code that is shown whenever a system file is having an issue. This error can be shown by other windows compatible software and driver vendors as well. This is a general error that points to a misconfigured or corrupt system file."
Das kann ich mir nicht so richtig vorstellen, denn Laufwerk C: ist intakt und es sind dort ca. 80 GB frei. Vielleicht liegt's mal wieder an der Wiederherstellungspartition?
Nicht verwechseln "corrupt system file" und "filesystem corrupt" ;)
Die Hilfe will dir sagen, dass vielleicht eine Systemdatei beschädigt ist.
Die gängigen Hilfestellungen dazu lauten:
in der Eingabeaufforderung (Admin)
sfc /scannow
und
dism /Online /Cleanup-Image /RestoreHealth
2 x Windows 10 22H2 mit ESU, Update KB5099539 für x64-Systeme, wurden hier ohne Probleme aktualisiert. HP-Hardware ca. 15 Jahre alt. Wiederherstellungspartition auf dem einen System 864MB auf dem anderen gibt es drei!? Wiederherstellungspartitionen (300,555,452MB). Naja, Veteranen haben so ihre Falten und Furchen.
veraltete Dateien im Rollup:
curl.exe
Version 8.13.0.0 (aktuell wäre 8.21.0)
7z.dll
Version 25.1.0.0 (aktuell wäre 26.2.0.0)
curl wurde offenbar nur in Windows 11 auf die aktuelle Version erneuert (Zitat aus Blog-Artikel hier):
"[Security] This update upgrades the curl tool in Windows to version 8.21.0 "
In Windows 10 21H2 LTSC ist curl leider nur auf 8.13.0.0 mit Datum 9.7.2025.
Laut der csv Dateiliste von der Supportseite sollte es eigentlich das Datum 11.7.2026 haben (ebenfalls die veraltete Version 8.13.0).
*ttps://support.microsoft.com/help/5099539
Nicht zu vergessen OpenSSH.
Da ist es noch schlimmer!
Version in Windows:
9.5.4.1, Dateidatum vom April 2025.
Die 9.5 erschien aber schon im Oktober 2023!
Microsoft hat also 2025 eine damals schon 1,5 Jahre alte Version in Windows gepackt!
Die aktuelle Version ist die 10.4 vom 6.7.26.
Microsoft hängt bei 3rd party-Komponenten immer ewig hinterher.
wenn sie selber kompilieren kann es sein, dass sie Sicherheitspatches in alte Varianten zurückportiert haben. Das kann sinnvoll sein, wenn sich beispielsweise die API bei Versionssprüngen ändert und man dann dutzende darauf aufbauende Programme neu testen müsste. Machen die ganzen Linux-Distributionen ja auch.
Andererseits handelt es sich hier natürlich um Microsoft… ;-)
Seit Ende Juni haben sich bei mehreren Kunden die Clients nicht mehr beim WSUS gemeldet. Der Bezug der Updates schlug mit Code 0x80244007 fehl. Grund dafür waren zu niedrige Limits für maxInstalledPrerequisites und maxCachedUpdates in der web.conf des IIS. Mit dieser Anleitung konnte das Problem behoben werden: https://learn.microsoft.com/de-de/troubleshoot/mem/configmgr/update-management/error-80244007-when-wsus-client-scans-updates
Kann ich so bestätigen, die Lösung im Artikel hat den Fehler behoben. Nur um die web.config abzuändern, musste ich den IIS komplett beenden, z.B. über den IIS-Manager, Rechtsklick auf den Server und Beenden, nach dem Abspeichern der web.config hab ich dann den gesamten Server einmal neugestartet. Danach haben sich die Windows 11 Clients wieder beim WSUS gemeldet.
In dem Artikel steht nur "iisreset" und fertig, aber erst nach Neustart des WSUS-AppPools und des WSUS-Dienstes funktionierte es bei mir. Kompletter Serverneustart geht natürlich auch.
Wir hatten nur den Fehler 0x80244010 bei ein paar Clients, welche schon ewig nicht mehr online waren.
Ein paar mal "Wiederholen" anklicken hat es aber dann gelöst
Der Fehler 0x80244010 tritt auf, wenn Client ewig nicht mehr online waren oder neu dem WSUS hinzugefügt wurden. Gemäss dem Microsoft-Dokument ist dafür ein Limit von 200 Zugriffen auf den WSUS pro Suchlauf verantwortlich. Das Limit von 200 ist im Windows Update Client hardcoded. Also entweder Suche selber nochmals anstossen, warten bis das "normale" Suchintervall gemäss GPO/Registry greift oder wenn eine Geräteverwaltungssoftware vorhanden ist, per Powershell-Script mit "UsoClient StartInteractiveScan" anstossen.
WSUS clients fail with WARNING: SyncServerUpdatesInternal failed: 0x80244010
https://learn.microsoft.com/de-ch/archive/blogs/sus/wsus-clients-fail-with-warning-syncserverupdatesinternal-failed-0x80244010
Ok, danke. Den Fehler war ich gerade auch am Troubleshooten, waren auch nur nen paar PCs betroffen. Werde ich morgen mal umsetzen, danke :)
Nach dem gestrigen Patchday können Fujitsu Clients (CELSIUS W580, CELSIUS W570, ESPRIMO D958) keine Reports mehr an den WSUS Server schicken. Sie konnten noch die Patches runterladen und installieren, der anschliessende Report wird an den WSUS Server übermittelt aber er wird nicht in die DB übernommen. Im Logfile des Servers ("C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log") werden dazu Warnungen angezeigt: "WebService.ValidateEventBatch Event in batch failed to validate. Exception: MiscData entry has empty or whitespace-only value: t="
Dies betrifft nur Fujitsu Geräte. Dell, Lenovo, Asus usw. haben alle kein Problem. Die KI meint dass eine Fujitsu-spezifische SMBIOS-/BIOS-Eigenschaft fehlt oder ist leer ist.
Kann dies jemand reproduzieren der einen WSUS Server und Fujitsu Clients hat? Bis Dienstagabend vor dem Patchday hatte alles problemlos funktioniert.
Moin,
wir haben hier lauter Fujitsu Geräte – alles ohne Probleme mit den Reports
Egal ob PC (z.B. Esprimo P558 / Esprimo P5011) oder Notebook (z.B. Lifebook E559 / Lifebook U759)
teilweise haben die Reports aber ewig gebraucht … aber das ist bei Windows 11 inzwischen gefühlt normal.
Schöne Grüße
betrifft auch andere, auch z.B. ASUS. Ist also wohl eher Zufall
Kann ich verifizieren. Allerdings auch bei Intel NUC.
WSUS meint, daß der Parameter N= oder t= im Report fehlerhaft ist.
BIOS ist jeweils aktuell, es sind aber ältere Geräte.
"Exception: System.InvalidOperationException: MiscData entry has empty or whitespace-only value: t="
Die letzten Reports dieser Geräte sind von vor dem Patchday.
Ich muss nochmal kurz nachfragen, da ich gerade etwas unsicher bin.
Habe ich das richtig verstanden, dass das Dell-Problem nur dann auftritt, wenn die Clients das "Windows Preview Update (KB5095093) vom 23.06.2026" installiert haben und dann das diesmonatige "Kumulative Update KB5101650 für Windows 11 24H2-25H2" installieren?
Ich hatte das so verstanden dass der Bug sowohl mit dem Juni-Preview-Update als auch mit dem Juli-Sicherheitsupdate auftritt (also im Preview-Update kaputtgemacht wurde und im Sicherheitsupdate welches kumulativ ist und das letzte Preview-Update enthält nicht wieder gefixt wurde). Insofern ist irrelevant ob man das Previewupdate vorher installiert hatte oder nicht; wenn eines der beiden Updates installiert ist und das Modell betroffen ist, treten die Probleme (Ausrufezeichen im Geräte-Manager, Bluescreens, Batterieverbrauch) auf.
Das könnte tatsächlich so sein.
Kann das jemand verifizieren?
Habe einen Multiboot-Recher, also immer dieselbe Hardware, immer Windows 11 Pro, aber unterschiedliche Anwendungen.
Die aktuellen Updates wurden installiert.
1. W11Pro mit Bitlocker startet nach den Updates normal
2. W11Pro mit Bitlocker schreit nach dem Bitlocker-Key (angegebener Grund: Sicherheitsrichtlinie geändert)
Key nicht eingegeben, zum Test noch einmal beide gebootet
1. W11Pro mit Bitlocker startet wiederholt normal
2. W11Pro mit Bitlocker schreit nach dem Bitlocker-Key
Key eingegeben, alles gut
Die 2023er-Zertifikate waren schon vorher eingespielt, als was zum Henker hat sich nur an einem Windows geändert?
Ich hätte es ja verstanden, wenn beide Bitlocker getriggert wären.
Ich schätze da muss man ein bisschen raten, weil mir dein exaktes Setup nicht bekannt ist.
1. wie werden die Betriebssysteme gewechselt? Ein Windows-Boot-Manager mit beiden Installationen drin? 2 Bootmanager auf zwei Festplatten, Wechsel per UEFI-Menü? Umstecken von Massenspeichermedien?
2. Welche Key-Protektoren sind für die beiden Bitlocker-Installationen (ich nehme an die nutzen unterschiedliche Volume Keys) konfiguriert? "manage-bde -protectors -get c:" sollte die ausgeben. Ich vermute mal TPM PCR7+11.
Aber so oder so, wir haben hier zwei Windows-Installationen, aber nur eine Firmware (also nur ein UEFI und nur ein TPM). Und in dem Fall ist es häufig so, dass das zuerst installierte Update, wenn es etwas tut was an den TPM Measurements rumwerkelt (Secure-Boot-Zertifikate waren es wohl nicht, aber vielleicht ein Firmwareupdate oder ein Update für die DBX), den Volume Key im TPM wieder neu gegen die PCR-Werte "versiegeln". Das geschieht nur für das gerade gebootete OS, welches nachher weiterbootet. Das andere OS welches gerade nicht gebootet war als das passierte, kann aus dem TPM den Volume Key nicht mehr abrufen und fällt damit auf den Recovery Key zurück.
Kurzzusammenfassung für alle die nicht wissen wie ein TPM mit Bitlocker benutzt wird. Das TPM "misst" beim Booten bestimmte Systemzustände (z.B. welche Firmware installiert ist – PCR 0; welche zusätzliche Firmware von Grafikkarten oder RAID-Controllern geladen wurde – PCR 2; Welche Option im Bootmenü der FIrmware gewählt wurde – PCR 3; Der Inhalt des Bootmanagers – PCR 4; Ob Secure Boot aktiv ist, welche Secure-Boot-Zertifikate installiert und genutzt wurden sowie was revoket ist per DBX – PCR 7; ob der Bootmanager bereits verlassen wurde oder man sich noch im Bootmanagger befindet – PCR 11). Die Werte der PCR-Register lassen sich vom gebooteten Betriebssystem auslesen, sowie man kann auch simulieren, wie sie sich ändern, wenn z.B. ein Zertifikat getauscht, ein neuer Bootloader installiert oder eine andere Bootoption gewählt wird. Das TPM bietet nun die Möglichkeit, einen kryptographischen Schlüssel (in dem Hardware-Chip) zu hinterlegen, bzw. natürlich mehrere bei Multiboot, die der Chip nur dann wieder rausrückt wenn bestimmte PCRs bestimmte Werte haben. Ist dein Bitlocker also auf PCR 7+11 konfiguriert, gibt das TPM den Schlüssel nur her, solange an der Secure-Boot-Konfiguration verglichen mit dem letzten Start diese einen Betriebssystems nix verändert wurde und der Bootmanager noch nicht verlassen wurde. Bei PCR 4+7+11 (was ältere Windows-Versionen machten) darf zusätzlich der Bootmanager (bootmgfw.efi) nicht verändert worden sein seit dem letzten Boot.
In jeder Situation, wo sich deine Firmware ändert, aber das gerade gebootete Betriebssystem nix davon weiß dass es noch andere gibt, wird das für das andere Betriebssystem notgedrungen zu einer Bitlocker-Recovery führen. Wenn das andere Betriebssystem davon weiß, hängt es davon ab wie gut es die Situation behandelt. (Funktioniert auch mit Linux+Windows Dual Boot, dass ein fwupd unter Linux den Windows-Bitlocker in Recovery treiben kann.)
Danke für deine detaillierte Beschreibung, das erklärt es gut.
Ich wechsele per Windows-Bootmanager zwischen verschiedenen Partitionen auf einer SSD.
Ich habe folgende Fehlermeldung auf meinen Computern in der Ereignisanzeige seit dem Update:
Fehler bei der SCEP-Zertifikatregistrierung für Lokales System über https://INTC-KeyId-ea950d987bcff0df9aac1feffb8ab4803fef2ca2.microsoftaik.azure.net/templates/Aik/scep:
Gibt es weitere Betroffene?
Ja, auch bei uns tritt der Fehler auf (nach jeder Anmeldung am Client)
Auf meinem Windows 11-System auch. Was bedeutet dieser Fehler und muss ich handeln?
Antwort von einem nicht betroffenen:
Der Endpunkt /Aik/scep in der Fehlermeldung lässt einem vermuten, dass der Client sich ein (Geräte-)Zertifikat bei Microsoft über das Simple Certificate Enrollment Protocol (SCEP) bei einer Active Directory Certificate Services Instanz (AD CS) holen will. Hängt der Client in einem M365-Tenant drin oder so was ähnliches, Microsoft Intune?. Die URI enthält prod-eus-1-issuingservice-a.cacore.azure.net gemäss der Fehlermeldung im Kommentar von Volker. Was ebenfalls einen Hinweis auf einen Microsoft PKI-Service gibt welcher nicht funktioniert. Folge dieses Problems könnte sein, dass der Client dann mal nicht mehr Remote verwaltbar ist oder so was in der Richtung.
Mit M365 o.ä. habe ich nichts am Hut ;-) Aber danke für den Hinweis.
Ergänzung – die Google-KI-Suche meint zum Suchbegriff /aik/scep:
"Bei /aik/scep handelt es sich um eine Windows-Konfiguration, bei der ein Computer AIK-Zertifikate (Attestation Identity Key) über das Protokoll SCEP (Simple Certificate Enrollment Protocol) anfordert. Dies geschieht meist im Hintergrund im Unternehmen oder Heimnetzwerk, oft in Verbindung mit TPM 2.0 (Trusted Platform Module) und Microsofts Cloud-Diensten (z.B. Microsoft Intune). AIK (Attestation Identity Key): Ein spezielles, im TPM erzeugtes Sicherheitszertifikat, das dazu dient, die Hardware-Identität und Integrität des Geräts fälschungssicher nachzuweisen.SCEP (Simple Certificate Enrollment Protocol): Ein standardisiertes Protokoll, das es Netzwerkgeräten und Computern ermöglicht, vollautomatisch digitale Zertifikate bei einer Zertifizierungsstelle (PKI) anzufordern und zu installieren. Häufiger Fehler: Oft taucht dieser Vorgang in der Ereignisanzeige auf (z.B. Fehler-ID 86, Fehler bei der Initialisierung der SCEP-Zertifikatregistrierung), wenn ein Client vergeblich versucht, das Zertifikat bei einem nicht existierenden Endpunkt abzurufen (besonders häufig bei VMs mit vTPM oder Windows 11)
"
Es geht da wohl mit dem Attestation Identity Key (AIK) um das an anderer Stelle im Blog auch schon diskutierten Themas einer eindeutigen Hardware-Kennung. Das dieser Endpunkt gerade nicht funktioniert hat vermutlich nicht direkt etwas mit dem aktuellen Juli-Update zu tun sondern eher generell was mit vTPM und/oder Windows 11.
Aber wieso tritt der Fehler direkt nach Installation des Juli-Patches auf?
Muss / kann der "Normalanwender" etwas tun?
Eine interessante Aussage habe ich hier gelesen:
https://learn.microsoft.com/de-de/answers/questions/3943846/ereigniseigenschaften-ereignis-86-certificateservi
"Auf einem typischen Heimanwender-PC werden keine Zertifikate per SCEP verteilt."
Seit wann brauchen die .Net Updates eigentlich so unfassbar lange? Das ist mir die letzten Monate schon aufgefallen. Die anderen Update laufen normal durch, aber bei .Net Updates rattert sich das einen Wolf. Im Task Manager sehe ich nur den üblichen Modules Installer Worker arbeiten mit 20-30% . Aber warum braucht das so lange? Was machen die Updates da? :D
diesmal dauerten alle updates gefühlt sehr lange …
Welches OS?
Für Windows 10 21H2 und 1809 kann ich das absolut nicht bestätigen, hier in der Firma liefen die wie gewohnt durch, nur der zweifache Neustart verlängert das Warten minimal.
hat noch jemand das Phänomen, dass nach Installation von KB5101650 keinen Systray mehr hat? Also gar keinen mehr, keine Uhr, kein Ton, keine offenen Programme. Es ist aber irgendwie schon noch da, denn bei Software, die da gerne "Popups " anzeigen (zb. Procall bei neuem Chat oder neuer Email), wird das Popup noch angezeigt. Das zugehörige Programm halt nicht.
Also die Taskleiste ist rechts komplett grau (oder je nach Farbeinstellung natürlich).
Ist bisher nur auf einem Testclient aufgefallen, VM auf VMWare, Win11 25H2, sogar frisch aufgesetzt passiert das. Andere VM die bereits gepatcht sind oder PC's zeigen das Problem nicht.
Bei uns bisher nicht, auf den Pilotclients ist noch alles da, wo es sein soll. Die restlichen Clients bekommen die Updates erst noch.
Was ein Zufall. Gestern hier gelesen: https://www.computerbase.de/forum/threads/windows-11-taskleisten-symbole-autostart-sind-weg.2275116/
Klingt irgendwie wie bei dir.
wow – krass ist ja wie er das Problem gelöst hat:
„… Update: Ok das ist echt wild:
Herunterfahren –> Steckdosen Hauptschalter aus –> Einschaltknopf gedrückt um die Restspannung los zu werden –> Hauptschalter ein –> Hochfahren –> Die Leiste mit den Miniaturprogrammen ist wieder da…."
Möglicherweise spukt da der Windows Schnellstart in die Suppe und ein (einmaliger) Neustart ohne Schnellstart hilft vielleicht auch:
„Um den Schnellstart unter Windows 11 zu umgehen, halten Sie beim Klicken auf „Neu starten" im Startmenü einfach die Umschalttaste (Shift) gedrückt. Für eine dauerhafte Deaktivierung rufen Sie die Systemsteuerung auf, navigieren zu Energieoptionen und deaktivieren die Funktion."
Kann es nicht selber testen, da mir der Fehler "fehlt" :D
Danke für die Hinweise. Habe ich versucht zu testen…
– Schnellstart ist bereits deaktiviert. Trotzdem Neustart mit SHIFT gemacht, keine Änderung. Auch ausschalten und wieder starten ändert nichts.
– Es ist eine VM…da wird "vom Strom trennen und Reststrom rauslassen" etwas schwierig ;)
– Bisher habe ich nur in der Konsole oder Remote mit 1 Monitor geprüft. Heute mal mit mehreren Monitoren RDP gemacht. Es scheint NUR den Hauptmonitor zu betreffen. Die Uhr wird auf Monitor 2 und 3 angezeigt.
– Die Taskleistensymbole sind alle eingeschaltet, angezeigt wird trotzdem keins.
– Andere VM's auf demselben Host zeigen das Verhalten nicht
Deinstallation des Juli-Updates bleibt bisher die einzige Lösung…
Ich habe mittlerweile mehrere Grundsätzlich verschiedene Systeme bei meinen Kunden gefunden, die auch ein merkwürdiges Verhalten einige Tage nach dem Update an den Tag legen. Meist so 2-4 Tage nach dem Update starten die Systeme deutlich langsamer (die moderne Eieruhr beim booten ist länger sichbar). Wenn man sich dann anmeldet, dann bleibt der Bildschirm komplett schwarz. Mauszeiger ist zusehen. Die HDD Leuchte zeigt deutliche Aktivität. Die üblichen Problemlösungen für "Black Screen" nach anmelden funktionieren so nicht. Also über den Taskmanager den Explorer abschießen, anderer User usw.). Der Bildschirm bleibt schwarz. Ruft man den Dienste Manager auf, dann sieht man, dass auch einige der Dienste erst lange nach dem anmelden gestartet werden. Langes warten (je nach Leistung des Systems zwischen 5 und 15 Minuten), bringt dann den Desktop doch hervor. Ist man erst einmal so weit, dann gibt es wiederrum auch zwei Arten von Systemen. Die einen booten ab dann völlig normal, die anderen zeigen das Verhalten dann immer wieder. Hier hilft es tatsächlich einmal ohne Schnellstart den Rechner neu zu starten. Und es betrifft wirklich Geräte aller Hersteller. HP, Lenovo, Microsoft, Dell usw.
Auch alle Prozessoren scheinen betroffen zu sein. Intel in einem Microsoft Notebook, AMD Ryzen in Lenovo und HP.
Aber: der PC direkt daneben vom gleichen Hersteller, sogar zum gleichen Zeitpunkt gekauft, läuft ohne Probleme. Das dumme ist halt, dass die Systeme erst Tage nach dem Update das Verhalten zeigen.
Nun, ich schalte den Schnellstart grundsätzlich aus. Es gab / gibt auch genügend Informationen im Internet, welche von Problemen mit dem Schnellstart berichten.
Das Problem mit dem Schnellstart ist halt, dass das System nicht richtig heruntergefahren wird, sieht man auch schön an der Laufzeit, die startet nämlich nicht wieder bei 0. Und auf SSDs ist der Geschwindigkeitsgewinn durch den Schnellstart doch sehr zu vernachlässigen. Zu HDD Zeiten mag die Funktion noch nützlich gewesen sein, heute überwiegen meiner Meinung nach die Nachteile, daher ist das bei allen unseren Geräten ausgeschaltet.
Bei einem Computer der die Vorschau Updates aktiviert hat, funktioniert DirectAccess nicht mehr nach Installation der Windows Updates.
(Ich weiß ist abgekündigt).
Ein optionales (kumulatives) OOB-Update soll das Problem beheben:
2026-07 Update (KB5121767)
July 18, 2026—KB5121767 (OS Builds 26 200.8894 and 26100.8894) Out-of-band
DELL bietet übrigens auch schon eine neuere als die o. g. Version des IPF an:
Intel-Innovation-Platform-Framework-and-Provider_25MJ5_WIN64_2.3.20303.50582_A10.EXE
Notebook "LG Gram" hat Verbindungsabbrüche mit dem neuesten Intel WLAN 7 Treiber seit dem Windows Rollup von Juli.
Downgrade des Intel Treibers behebt das Problem.
siehe Kommentar dort:
*ttps://www.heise.de/forum/heise-online/Kommentare/Microsoft-verteilt-ausserplanmaessiges-Windows-Update/Der-aktuelle-wlan-Treiber-von-Intel-hat-auch-ein-Problem/posting-46446404/show/
KB5099539 für Windows 10 verursacht Probleme, wenn auf den Partitionen Installationsdateien für Mac OS gespeichert sind.
Ein eher exotisches Phänomen, das sicherlich die wenigsten betrifft, ich aber informationshalber mal erwähnen möchte.
Neben verschiedenen Windows-Versionen, kann ich meinen PC auch in Mac OS (Stichwort Hackintosh) booten. Logischerweise gesellt sich zu meiner Windows Programmsammlung auch ein Fundus für Mac-Programme, jahrelang in friedlicher Koexistenz auf einer Partition (HDD als GPT, FS ist NTFS).
Nach dem Juli Update springt beim Booten von Windows plötzlich checkdisk an und startet eine Reparatur dieser Partition. Eine Kontrolle in Windows ergibt keine Fehler, aber das dirty-bit dieser Partition bleibt gesetzt und wird nach der Prüfung nicht gelöscht. Dasselbe tritt auch bei einer externen HDD auf, auf die ich den Fundus kopiert habe.
Getestet auf verschiedenen PCs und in einer VM.
Nach Deinstallation des Updates ist alles wieder OK.
Windows 11 stört sich komischerweise mal nicht daran. und setzt auch das dirty-bit der Partitionen brav wieder zurück.
Inzwischen vermute ich, dass es die .pkg Installationspakete sind, die eine lange Pfadtiefe besitzen. Windows betrachtet diese Dateien wie Verzeichnisse und wuselt darin rum. dmg Images interessieren Windows hingegen nicht.