I am on the “insider build” program. Until a bit ago, I was on the “beta” channel, not the “dev” or “Pre Release” channels.
Curiously, while on the beta channel, the certificates associated with some of my needed files (specifically here, ntdll.dll) expired. That was demonstrated, for me, by not being able to run any Virtualbox Virtual Machines (VM), something I very much need to do.
Some snipped log entries, pointing out the problem:
5174.4b04: 00007ff9bc0b9000-00007ff9bc12cfff 0x0002/0x0080 0x1000000 \Device\HarddiskVolume1\Windows\System32\ntdll.dll
5174.4b04: 00007ff9bc12d000-00007ffffffeffff 0x0001/0x0000 0x0000000
5174.4b04: \Device\HarddiskVolume1\Windows\System32\ntdll.dll: VERR_CR_X509_CPV_NOT_VALID_AT_TIME for 0xf91937b2; retrying against current time: 0x5f287bfd.
5174.4b04: Error (rc=-23033):
5174.4b04: supHardenedWinVerifyProcess failed with Unknown Status -23033 (0xffffa607): Certificate is not valid (ValidTime=2020-08-03T21:05:01.000000000Z Validity=[2019-02-20T22:40:22.000000000Z...2020-07-31T22:40:22.000000000Z]): \Device\HarddiskVolume1\Windows\System32\ntdll.dll
5174.4b04: Error -23033 in supR3HardNtChildPurify! (enmWhat=5)
5174.4b04: supHardenedWinVerifyProcess failed with Unknown Status -23033 (0xffffa607): Certificate is not valid (ValidTime=2020-08-03T21:05:01.000000000Z Validity=[2019-02-20T22:40:22.000000000Z...2020-07-31T22:40:22.000000000Z]): \Device\HarddiskVolume1\Windows\System32\ntdll.dll
5174.4b04: supR3HardNtEnableThreadCreationEx:Information out there on the world wide web was hard to come by. The hint was provided here.
Essentially, I had to change my insider program channel to dev. Will the signatures for the beta channel be updated past 7/31/2020? Probably, but I can’t wait for that. So, for now, I run slightly more risk with a more aggressive build, where less testing is done before release. Notes related to this from Microsoft here.
As Kurt Vonnegut wrote, “So it goes.”
Bugs, bugs, bugs!
Related to this, after going to the dev channel update, turns out there is a bug with (at least) WSL 1 and your PATH variable. An issue known to Microsoft, referenced again here.
In short, I have a Visual Basic Script (VBS) that calls a batch file to run my preferred terminal, Terminator, over WSL 1. That stopped working after this channel change (yay!). Note that the same should be related to anything WSL (including wsl.exe).
To get around that, I changed my batch script to shorten the “normal” path from Windows:
@echo off
start /B x410.exe /wm
set path=c:\Windows\System32;c:\Users\jeffr\AppData\Local\Microsoft\WindowsApps
pengwin run if [ -z \"$(pidof terminator)\" ]; then "export DISPLAY=192.168.5.50:0.0; terminator; fi;"…and everything is fine again. For now.