Version 1903, builds 18362 RC through 18362.113, WU and MS Store issue

Hello!

I've been testing the Version 1903 builds on about a half dozen PCs (all upgrades from 1809) over the past month or so, and am having a strange problem on only one of them. I've found something curious, and wanted to post it in case anyone has seen this happen before, or can give me any insight.

My problem PC is having two problems - it cannot connect to Windows Update, and it cannot download apps/updates from the Microsoft Store.

For Windows Update, the message is "Error encountered - We couldn't connect to the update service. We'll try again later, or you can check now. If it still doesn't work, make sure you're connected to the Internet."

For the Microsoft Store, the error code is 0x80072EFE, which is a generic "connection aborted" condition.

Initially, I researched these errors individually, trying various "fixes" for each. For the Windows Update problem, I ran the troubleshooter (which finds nothing), did some netsh reset commands/reboots, and performed another in-place upgrade, among other things. For the Microsoft Store problem, I ran the troubleshooter, performed a "wsreset," and other things which I don't remember now. The bottom line is, none of these things solved the problem.

Next, I associated the PC with a WSUS instance I administer as part of my day job, via a VPN. Pointed to that, Windows Update functions and is happy, but any checks to Microsoft "directly" result in the same failures.

Over the weekend, I decided to run a Wireshark packet capture, in an effort to determine what was happening during the WU checks and the MS Store downloads. I was able to trace what is happening, and the symptom is the same for both problems.

There is a specific Microsoft endpoint, slscr.update.microsoft.com [13.78.168.230], which the PC connects to when checking for Windows Updates or MS Store downloads. However, on my problem PC, after it sends a TLS 1.2 "Client Hello," the 13.78.168.230 endpoint immediately responds with a TCP reset, which kills the connection (basically "hangs up" on me). After many attempts (each subsequent resulting in the same TCP reset), my PC gives up, and I get the error message.

If I block outbound traffic to 13.78.168.230 with the Windows firewall, the error messages change to "check your Internet connection" messages, with the MS Store error changing to 0x00072EFD ("Check your Internet connection - We couldn't connect you to the service).

I've had a look at the other "good" PCs (one of which is on the same network as the problem one), and those communicate with 13.78.168.230 just fine after the TLS 1.2 "Client Hello," getting back a "Server Hello" and continuing on with the network conversation normally.

It is a mystery why this specific PC is getting the TCP resets from that MS endpoint. I'm also at a loss on what to try next...if anyone has any ideas, I'm all ears!

Thank you for reading!

The full history is at https://answers.microsoft.com/en-us/...c-8b3e89b1289a

I'm happy to report that this issue is now resolved.

The TL;DR version is this: Open regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002. If there is a "Functions" value there, delete it and reboot.

The long version: Since performing a "Reset PC" operation solved the problem, and I didn't want to do that on the physical computer, I wondered if the problem would still be present after upgrading to the next Insider Preview build. So on the VM, I opted it in to Insider Preview skip ahead. However, because of the problem, it could not connect to Windows Update to download a new build. So, I needed an ISO, and went to UUP dump to make one. When running the script that downloads the files, it had this error:

SSL/TLS handshake failure: Error: The message received was unexpected or badly formatted. (80090326)

So, I used a different PC to create the ISO, and then installed Build 18898.1000 on the VM. After that, the Windows Update / MS Store problem remained. Back to the drawing board (I restored the shapshot).

With all the evidence now pointing at crypto settings (I should have chased the TLS 1.2 "client hello" problem more in the beginning), I decided to use Nartac's IIS Crypto to manipulate the settings. That tool is meant for use on web servers, but can also change client settings. I applied the "Best Practices" settings on the VM, rebooted, and BAM the problem was fixed...Windows Update and MS Store downloads worked.

I did take "before and after" registry backups using the tool, to determine what exactly it changed. The registry key I listed at the beginning was the pertinent one. My bad PC had a "Functions" value with the following value data:

"Functions"="TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384,T LS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,TLS_ECDHE_RSA_WITH _AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_ P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE _RSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CB C_SHA_P256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_ SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS _RSA_WITH_3DES_EDE_CBC_SHA"

After applying the IIS Crypto "Best Practices" settings, the value data changed to:

"Functions"="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_R SA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_ 128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_E CDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384 ,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS _RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA"

I then had a look at several of the other "good" PCs to see what was at that location in the registry, and none of them had any values under that key. So, I restored the VM snapshot to get it back to the problem state, and then simply deleted that "Functions" value and rebooted, which fixed it (presumably letting Windows decide on cipher suite order or whatever is happening there).

My last thought is this: It sure would be nice if the Windows Update troubleshooter was aware of the SCHANNEL crypto settings potentially being a problem!

Okay, one more thought: If the computer is subject to domain GPOs, your sysadmin(s) might be manipulating that cipher suite order stuff, so keep that in mind.

Cheers!

Jim