[German]After the Microsoft patchday disaster of July 2018, August updates seems to be mostly flawless. But there are some minor issues with Windows 10 V1803 (independent from August patchday). Here is an overview about some (minor) issues in Windows 10 V1803 (and minor patchday issues in V1709/V1803).
Advertising
Thanks to Woody Leonhard, who has collected most stuff at askwoody.com. Perhaps it's worth reading for administrators, it may save a few hours of troubleshooting.
Windows 10 V1803 installation loop?
I've had seen some vague references (on reddit.com) about an installation loop regarding the patchday update for Windows 10 V1803. Woody Leonhard has picked a case of user Uroboros4 on askwoody.com. The update cannot be installed successfully, the system enters an update loop.
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?
But it seems to be an isolated case, I found no further reports. I had written the blog post Fix: Windows 10 hangs in the update installation loop as a solution to this issue.
Windows 10 V1803: Bitlocker pauses during update
Patch Diva Susan Bradley spottet a specific issue in Windows 10 version 1803. This is described in a Technet forum thread and applies to machines with Windows 10 version 1803 that do not have a TPM module. If the hard disk encryption with Bitlocker is activated on such a machine, Windows deactivates bitlocker during the installation of an update. The thread creator describes this as follows:
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 PasswordNow, 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.
If the machine is restarted, Bitlocker is activated again. It only occurs on Windows 10 V1803 machines without a TMP chip. If people install updates and only send the machine into sleep mode, Bitlocker may remain disabled for a long time.
Advertising
Windows Server 2016: sysvol sync bug back?
It is more a question Woody Leonhard asks in this article. A user asked whether a GPO synchronization problem from July 2018 still exists. Here is his error description:
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.
He has blocked the July 2018 update KB4338814 in the WSUS, but is now confronted with the problem again in August 2018. This is not an isolated case, because Technet forum has the thread KB4284833 Group Policy Sync issue with a similar issue.
Windows 10 V1803 Boot loop 'bootres.dll is corrupt'
This too is an error reported by Woody Leonhard, which is independent of the August 2018 updates. A user describes the error as follows:
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 = 0x57The 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?
This is not an isolated case, because I found the bug description in several German forums (here, here). At MS Answers forum there is this english thread (May 2018), or also here is another case. The solution will be a clean install in most cases, since a file in the EFI boot directory is corrupted. And most users cannot replace it with an undamaged file. However, there is this English-language MS Answers forum thread, where a user has described a solution that works for him. GDATA antivirus is suspected of being the cause in the German administrator.de forum. In other threads I found Norton AV solution be suspected as a root cause, but everything is only a suspicion.
Win 10 V1803: Update KB4343909 kills Application Guard
On Facebook I got the feedback from a German consultant that three of his systems (probably Windows 10 V1803 Enterprise) had a broken 'Windows Defender Application Guard' (WDAG) after installing the August 2018 update. The Windows Defender Application Guard reports the error code 0xC0370106 and the window need to be closed.
He then confirmed that it is probably the 'known issue' that Microsoft has added to KBb4343909.
Launching Microsoft Edge using the New Application Guard Window may fail; normal Microsoft Edge instances are not affected.
The workaround specified by Microsoft is to uninstall the KB4343909 update. Then install updates KB4340917 and KB4343909. Microsoft intends to deliver a fix in the next release. This error is also mentioned here on askwoody.com.
By the way, error code 0xC0370106 is an 'old friend'. If you work under Windows 10/Server 2016 with Docker, the error code may be displayed. This GitHub article discusses this for example – a search with the error code, however, brings further hits.
Hypervisor Error from KB4343897 for Windows 10 V1709?
It's a bit out of line, since it does not refer to Windows 10 V1803 – and it is only one case I'm aware. On Twitter Tero Alhonen (@teroalhonen) reports a problem with the cumulative August 2018 update KB4343897 for 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
After the cumulative update KB4343897 he had his third Blue Screen 'HYPERVISOR ERROR'. The BSOD stop code 0x00020001 is documented here from Microsoft.
Similar articles:
Windows 10 WikiWindows streikt mit Fehler 0xC000007F
Windows 10 V1803: Update KB4458166 fixes TLS 1.2 issue
Windows 10 V1803 rollout stopped due to TLS 1.2 issues
TLS 1.2: Windows Error Reporting Service drops an error
Windows error 0xC000007F
Patchday Windows 10-Updates (August 14, 2018)
Advertising
