{"id":208084,"date":"2018-08-17T17:38:53","date_gmt":"2018-08-17T15:38:53","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=208084"},"modified":"2024-10-04T21:17:38","modified_gmt":"2024-10-04T19:17:38","slug":"windows-10-v1803-probleme-welche-probleme-oh-doch","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2018\/08\/17\/windows-10-v1803-probleme-welche-probleme-oh-doch\/","title":{"rendered":"Windows 10 V1803: Probleme, welche Probleme? Oh, doch!"},"content":{"rendered":"

\"Windows[English<\/a>]Zum August 2018 Patchday hat Microsoft ja einen fetten Schwung an Sicherheitsupdates f\u00fcr 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\u00e4nzung:<\/strong> Ein known Issue ist f\u00fcr Windows 10 V1803 aufgetaucht.<\/p>\n

\"\"Hier einige Infosplitter, die mir unter die Augen gekommen sind, wobei nicht jeder Fehler direkt mit dem Patchday und Updates zusammen h\u00e4ngt. Woody Leonhard hat da einiges zusammen getragen. F\u00fcr Administratoren vielleicht lesenswert, erspart m\u00f6glicherweise einige Stunden Tests zur Fehlersuche.<\/p>\n

Windows 10 V1803 Installationsschleife?<\/h2>\n

Ich hatte einige vage Hinweise (auf reddit.com in diesem Thread<\/a>) auf eine Installationsschleife im Hinblick auf das zum Patchday f\u00fcr Windows 10 V1803 freigegebene Update gesehen. Woody Leonhard hat einen Fall von Benutzer Uroboros4<\/em> auf askwoody.com<\/a> herausgegriffen. Das Update kann nicht erfolgreich installiert werden, das System ger\u00e4t in eine Update-Schleife.<\/p>\n

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?<\/p><\/blockquote>\n

Es scheint sich aber um einen Einzelfall zu handeln, es gibt keine weiteren Meldungen. Ich hatte den Blog-Beitrag Fix: Windows 10 h\u00e4ngt in Update-Installationsschleife<\/a> als L\u00f6sungshilfe zu diesem Problem verfasst.<\/p>\n

Windows 10 V1803: Bitlocker pausiert w\u00e4hrend Updates<\/h2>\n

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

Ist dort die Festplattenverschl\u00fcsselung mit Bitlocker aktiviert, deaktiviert Windows diese w\u00e4hrend der Installation eines Updates. Der Thread-Ersteller beschreibt dies so:<\/p>\n

I have a machine with Bitlocker enabled, no TPM, Windows 10 1803.<\/p>\n

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.<\/p>\n

This is the state of the OS drive after logging in:<\/p>\n

Volume C: [System]
\n[OS Volume]<\/p>\n

Size:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 59.07 GB
\nBitLocker Version:\u00a0\u00a0\u00a0 2.0
\nConversion Status:\u00a0\u00a0\u00a0 Fully Encrypted
\nPercentage Encrypted: 100.0%
\nEncryption Method:\u00a0\u00a0\u00a0 XTS-AES 128
\nProtection Status:\u00a0\u00a0\u00a0 Protection Off (1 reboots left)\u00a0\u00a0 <——
\nLock Status:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Unlocked
\nIdentification Field: Unknown
\nKey Protectors:
\nPassword
\nNumerical Password<\/p>\n

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.<\/p><\/blockquote>\n

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. \u00fcber lange Zeit deaktiviert.<\/p>\n

Windows Server 2016: sysvol sync bug zur\u00fcck?<\/h2>\n

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

Has anyone else experienced their GPOs not syncing permissions after applying KB4338814 to Server 2016?<\/p>\n

We were getting the ACL error<\/p>\n

\"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\".<\/p>\n

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

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.<\/p>\n

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.<\/p><\/blockquote>\n

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 \u00e4hnlichen Problematik.<\/p>\n

Windows 10 V1803 Boot-Schleife 'bootres.dll ist korrupt'<\/h2>\n

Auch dies ist wohl ein von Woody Leonhard berichteter Fehler<\/a>, der unabh\u00e4ngig von den August 2018-Updates ist. Ein Benutzer beschreibt den Fehler so:<\/p>\n

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:<\/p>\n

Root cause found:
\n\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014
\nBoot critical file c:\\efi\\microsoft\\boot\\resources\\custom\\bootres.dll is corrupt.<\/p>\n

Repair action: File repair
\nResult: Failed. Error code = 0x57<\/p>\n

The odd part of this error is the \"Custom\" folder location \u2013 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).<\/p>\n

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 \u2013 thus the bootres.dll cannot be present at this location and is declared \"corrupt\" by the Startup Repair utility.<\/p>\n

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 \u2013 most likely it refers to the first partition \u2013 not the actual main C: drive \u2013 but that is a whole different can of worms)<\/p>\n

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

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) \u2013 but only occurs after further updates (as yet unidentified) and then a full restart.<\/p>\n

I am exploring BCD repair and rebuild options with some success \u2013 but have no clean fix as yet (the standard RE repair options get lost)<\/p>\n

Anyone have any experience of this problem or ideas as to what causes this error?<\/p><\/blockquote>\n

Das Ganze ist kein isolierter Fall, da ich den Fehler hier<\/a> (bootres.dll \u2013 besch\u00e4digt) vom Juni 2018, bei administrator.de<\/a>, bei MS Answers in diesem englischen Thread<\/a> (Mai 2018), oder auch hier<\/a> gefunden habe. L\u00e4uft dann wohl auf einen Clean-Install hinaus, da eine Datei im EFI-Boot-Verzeichnis besch\u00e4digt ist und die meisten Nutzer die eher nicht durch eine unbesch\u00e4digte Datei ersetzen k\u00f6nnen. Es gibt aber diesen englischsprachigen MS Answers-Forenthread<\/a>, wo ein Benutzer eine f\u00fcr ihn funktionierende L\u00f6sung beschrieben hat. Im administrator.de-Forum wird GDATA-Antivirus als Verursacher verd\u00e4chtigt. In anderen Threads ist mir Norton als AV-L\u00f6sung untergekommen, ist aber alles nur ein Verdacht und nicht wirklich belastbar.<\/p>\n

Win 10 V1803: Update KB4343909 killt Application Guard<\/h2>\n

Erg\u00e4nzung:<\/strong> Auf Facebook bekam ich die R\u00fcckmeldung von einem Consultant, dass bei ihm drei Systeme (wohl Windows 10 V1803 Enterprise) beim Einspielen des August 2018-Updates den 'Application Guard h\u00e4tten auseinanderfallen lassen'. Der Windows Defender Application Guard meldet den Fehlercode 0xC0370106 und das Fenster muss geschlossen werden.<\/p>\n

\"Windows<\/p>\n

Er hat dann best\u00e4tigt, dass es wohl das 'known issue' ist, welches Microsoft bei KB4343909<\/a> nachgetragen hat.<\/p>\n

Launching Microsoft Edge using the New Application Guard<\/strong>\u00a0Window\u00a0<\/strong>may fail; normal Microsoft Edge instances are not affected.<\/p><\/blockquote>\n

Der von Microsoft angegebene Workaround lautet, das Update KB4343909 zu deinstallieren. Anschlie\u00dfend sind die Updates KB4340917<\/a> und KB4343909 zu installieren. Microsoft will einen Fix im kommenden Release ausliefern. Auch auf askwoody.com wird dieser Fehler hier<\/a> erw\u00e4hnt.<\/p>\n

Der Fehlercode\u00a00xC0370106 ist \u00fcbrigens ein 'alter Bekannter'. Wer unter Windows 10\/Server 2016 mit Docker arbeitet, bekommt den Fehlercode ggf. angezeigt. Dieser GitHub-Beitrag<\/a> thematisiert das beispielsweise – eine Suche mit dem Fehlercode bringt aber weitere Treffer.<\/p><\/blockquote>\n

Hypervisor-Error durch\u00a0KB4343897 f\u00fcr Windows 10 V1709<\/h2>\n

F\u00e4llt 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<\/a> meldet\u00a0Tero Alhonen<\/a>\u00a0(@teroalhonen) ein Problem mit dem kumulativen August 2018 Update\u00a0<\/span>KB4343897 f\u00fcr Windows 10 V1709.<\/p>\n

\n

3rd time after August Cumulative Update KB4343897 for Windows 10 version 1709 pic.twitter.com\/swx6AstGka<\/a><\/p>\n

\u2014 Tero Alhonen (@teroalhonen) 18. August 2018<\/a><\/p><\/blockquote>\n