Windows 10 V1803: Probleme, welche Probleme? Oh, doch!

[English]Zum August 2018 Patchday hat Microsoft ja einen fetten Schwung an Sicherheitsupdates für Windows, Office und weitere Produkte freigegeben. Nach dem Patchday-Desaster von Juli 2018 ist es im August 2018 zum Patchday erstaunlicherweise bis jetzt recht ruhig geblieben. Aber es haben sich einige kleinere Probleme zu Windows 10 V1803 (abseits des Patchday) angesammelt. Ergänzung: Ein known Issue ist für Windows 10 V1803 aufgetaucht.

Hier einige Infosplitter, die mir unter die Augen gekommen sind, wobei nicht jeder Fehler direkt mit dem Patchday und Updates zusammen hängt. Woody Leonhard hat da einiges zusammen getragen. Für Administratoren vielleicht lesenswert, erspart möglicherweise einige Stunden Tests zur Fehlersuche.

Windows 10 V1803 Installationsschleife?

Ich hatte einige vage Hinweise (auf reddit.com in diesem Thread) auf eine Installationsschleife im Hinblick auf das zum Patchday für Windows 10 V1803 freigegebene Update gesehen. Woody Leonhard hat einen Fall von Benutzer Uroboros4 auf askwoody.com herausgegriffen. Das Update kann nicht erfolgreich installiert werden, das System gerät in eine Update-Schleife.

I have Win10 1803 genuine. None of the cumulative updates can be applied(for example KB4343909, kb4284835, kb4103721). It reaches 100% and says " Update couldn't apply, reverting changes". I have tried a lot of stuff (pausing win update and manually installing them, scan windows for corrupted files to no avail). Anyone has the same problem?

Es scheint sich aber um einen Einzelfall zu handeln, es gibt keine weiteren Meldungen. Ich hatte den Blog-Beitrag Fix: Windows 10 hängt in Update-Installationsschleife als Lösungshilfe zu diesem Problem verfasst.

Windows 10 V1803: Bitlocker pausiert während Updates

Mehr ein kleiner Hinweis statt eines Bugs. Susan Bradley macht hier auf eine Spezifika unter Windows 10 Version 1803 aufmerksam. Diese ist im Technet-Forum beschrieben und trifft für Maschinen mit Windows 10 Version 1803 zu, die kein TPM-Modul besitzen.

Ist dort die Festplattenverschlüsselung mit Bitlocker aktiviert, deaktiviert Windows diese während der Installation eines Updates. Der Thread-Ersteller beschreibt dies so:

I have a machine with Bitlocker enabled, no TPM, Windows 10 1803.

For the last month or so, whenever a Windows system update is applied, Bitlocker is automatically suspended upon first login after the machine restarts. Case in point: the latest Windows 10 cumulative update was applied this morning, only for the machine to restart with Bitlocker suspended on the OS drive. Interestingly, there is also some dubious behaviour in terms of the initial Bitlocker password entry screen. Not having a TPM, the user must enter a password to boot. On at least 2 occasions, after applying an update, the system does not present the Bitlocker password entry screen and progresses all the way to the user login screen. However, this morning the Bitlocker password entry screen was presented correctly but after entering the correct password and then logging in to Windows, Bitlocker was suspended.

This is the state of the OS drive after logging in:

Volume C: [System]
[OS Volume]

Size:                 59.07 GB
BitLocker Version:    2.0
Conversion Status:    Fully Encrypted
Percentage Encrypted: 100.0%
Encryption Method:    XTS-AES 128
Protection Status:    Protection Off (1 reboots left)   <——
Lock Status:          Unlocked
Identification Field: Unknown
Key Protectors:
Password
Numerical Password

Now, I realise that Bitlocker is temporarily suspended – restarting the machine again will enable it without any action from the user. However, this is a security risk for the time between restarting after an update and the next restart and severely undermines our trust in Bitlocker. I would expect that Bitlocker should NEVER be suspended unless initiated by a user/admin.

Wird die Maschine nochmals neu gestartet, schaltet sich Bitlocker erneut ein. Gab dann eine Diskussion mit den 'berufenen Experten' im Thread. Aber am Ende des Tages scheint es ein Problem zu sein, was so nicht zu erwarten war. Es tritt nur auf Windows 10 V1803-Maschinen ohne TMP-Chip auf. Wenn Leute dort Updates installieren und die Maschine nur in den Ruhemodus schicken, bleibt Bitlocker u.U. über lange Zeit deaktiviert.

Windows Server 2016: sysvol sync bug zurück?

Es ist mehr eine Frage, die Woody Leonhard in diesem Beitrag stellt. Dort fragt ein Nutzer nach, ob ein GPO-Synchronisationsproblem aus dem Juli 2018 noch vorhanden sei. Hier seine Fehlerbeschreibung:

Has anyone else experienced their GPOs not syncing permissions after applying KB4338814 to Server 2016?

We were getting the ACL error

"The sysvol permissions for one or more GPOs on this domain controller are not in sync with the permissions for the GPOs on the baseline domain".

Went through an Non-authoritative SYSVOL restore, demoting and promoting a domain controller, and finally uninstalled patch KB4338814 to resolve the issue.

This problem existed on our test domain (two DCs 2012 and 2016) and our production (three DCs 1-2012 and 2-2016) The ACL sync issues only happened on one of the production 2016 DCs which was strange. Once we removed the patch we had to go to any GPOs still showing ACL errors and restore the delegation permissions to defaults in order for it to start syncing.

I have blocked patch KB4338814 from July in WSUS but the issue is now happening again in our test Active Directory after applying the August cumulative updates. I'd love to know if anyone else is seeing this issue and if Microsoft has reported it as a problem.

Er hat das Juli 2018-Update KB4338814 im WSUS blockiert, ist jetzt im August 2018 aber wieder mit dem Problem konfrontiert. Es handelt sich nicht um einen Einzelfall, denn auf Technet gibt es den Beitrag KB4284833 Group Policy Sync issue mit einer ähnlichen Problematik.

Windows 10 V1803 Boot-Schleife 'bootres.dll ist korrupt'

Auch dies ist wohl ein von Woody Leonhard berichteter Fehler, der unabhängig von den August 2018-Updates ist. Ein Benutzer beschreibt den Fehler so:

There is recurring issue reported online where Win10 gets stuck in a repair loop. The Win10 Recovery Environment (RE) option Startup Repair fails to correct the problem. The Startup Repair log c:\windows\system32\logfiles\srt\SrtTrail.txt reports a fault:

Root cause found:
—————————
Boot critical file c:\efi\microsoft\boot\resources\custom\bootres.dll is corrupt.

Repair action: File repair
Result: Failed. Error code = 0x57

The odd part of this error is the "Custom" folder location – this is not part of the normal folder structure. The bootres.dll file normally resides in the "Resources" folder with the BCD file in the folder above (Boot).

What the error is reporting is that the bootres.dll file is missing (rather than corrupted) On the systems I have checked the "Custom" folder does NOT even exist – thus the bootres.dll cannot be present at this location and is declared "corrupt" by the Startup Repair utility.

The bigger mystery is why the System thinks the file should be located in a "Custom" sub-folder in the first place. (Also I think the c: drive letter shown is an artifact – most likely it refers to the first partition – not the actual main C: drive – but that is a whole different can of worms)

I am currently working on two HP laptops with this exact problem – both went down within an hour of each other. At first I though it must be a virus or malware attack gone wrong – but could find no evidence to support this idea.

Having read multiple postings and responses across many different online forums: The evidence suggests this is a Microsoft bug that affects a limited number of Win10 systems. The problem appears to affect systems recently upgraded to version 1803 (only one case listed 1709 on a Surface device) – but only occurs after further updates (as yet unidentified) and then a full restart.

I am exploring BCD repair and rebuild options with some success – but have no clean fix as yet (the standard RE repair options get lost)

Anyone have any experience of this problem or ideas as to what causes this error?

Das Ganze ist kein isolierter Fall, da ich den Fehler hier (bootres.dll – beschädigt) vom Juni 2018, bei administrator.de, bei MS Answers in diesem englischen Thread (Mai 2018), oder auch hier gefunden habe. Läuft dann wohl auf einen Clean-Install hinaus, da eine Datei im EFI-Boot-Verzeichnis beschädigt ist und die meisten Nutzer die eher nicht durch eine unbeschädigte Datei ersetzen können. Es gibt aber diesen englischsprachigen MS Answers-Forenthread, wo ein Benutzer eine für ihn funktionierende Lösung beschrieben hat. Im administrator.de-Forum wird GDATA-Antivirus als Verursacher verdächtigt. In anderen Threads ist mir Norton als AV-Lösung untergekommen, ist aber alles nur ein Verdacht und nicht wirklich belastbar.

Win 10 V1803: Update KB4343909 killt Application Guard

Ergänzung: Auf Facebook bekam ich die Rückmeldung von einem Consultant, dass bei ihm drei Systeme (wohl Windows 10 V1803 Enterprise) beim Einspielen des August 2018-Updates den 'Application Guard hätten auseinanderfallen lassen'. Der Windows Defender Application Guard meldet den Fehlercode 0xC0370106 und das Fenster muss geschlossen werden.

Er hat dann bestätigt, dass es wohl das 'known issue' ist, welches Microsoft bei KB4343909 nachgetragen hat.

Launching Microsoft Edge using the New Application Guard Window may fail; normal Microsoft Edge instances are not affected.

Der von Microsoft angegebene Workaround lautet, das Update KB4343909 zu deinstallieren. Anschließend sind die Updates KB4340917 und KB4343909 zu installieren. Microsoft will einen Fix im kommenden Release ausliefern. Auch auf askwoody.com wird dieser Fehler hier erwähnt.

Der Fehlercode 0xC0370106 ist übrigens ein 'alter Bekannter'. Wer unter Windows 10/Server 2016 mit Docker arbeitet, bekommt den Fehlercode ggf. angezeigt. Dieser GitHub-Beitrag thematisiert das beispielsweise – eine Suche mit dem Fehlercode bringt aber weitere Treffer.

Hypervisor-Error durch KB4343897 für Windows 10 V1709

Fällt etwas aus der Reihe, da nicht auf Windows 10 V1803 bezogen – und es ist nur eine Fundstelle (die Suche nach der Nadel im Heuhaufen, wie Kommentatoren meinen). Auf Twitter meldet Tero Alhonen (@teroalhonen) ein Problem mit dem kumulativen August 2018 Update KB4343897 für Windows 10 V1709.

3rd time after August Cumulative Update KB4343897 for Windows 10 version 1709 pic.twitter.com/swx6AstGka

— Tero Alhonen (@teroalhonen) 18. August 2018

Nach dem kumulativen Update KB4343897 ist bei ihm bereits zum dritten Mal ein Blue Screen 'HYPERVISOR ERROR' aufgetreten. Der BSOD-Stop-Code 0x00020001 ist hier bei Microsoft dokumentiert.

Ähnliche Artikel:
Windows 10 Wiki/FAQ
Windows 10 V 1607 Wiki/FAQ
Windows 10 V1703 Wiki/FAQ
Windows 10 V1709 Wiki
Windows 10 V1803 Wiki
Windows streikt mit Fehler 0xC000007F