While setting up two new Lenovo E540 notebooks that had Windows 8 on them, I came across an issue with the update to Windows 8.1 via the Microsoft Store. It would get to 50% downloaded/installed and then error with the code 0x80240031. Initially I thought there was an issue with one of the notebooks (I hadn’t tried the second one yet), the sequence I performed the upgrade or the required patches that needed to be installed before I performed the upgrade. All this included image restores to ensure there was nothing from the previous processes contaminating future testing.
After another 30GB of expensive Australian internet blown, I thought it was time to see if the issue was localised to one notebook or if the other had the issue too. The second notebook also presented the same issue. Time to ask Mr. Google as the error code 0x80240031 was not very helpful to determine a root cause but at least you can find others that are having the same issue. In fact, after solving the issue, it was pretty generic and useless. I’d hate for my parents to have to solve this if I wasn’t available.
It appears that is issue is quite common, people from all over the world have had this issue with suggestions in numerous forums and blogs to perform the following:
sfc /scannow
Dism /Online /Cleanup-Image /CheckHealth Dism /Online /Cleanup-Image /ScanHealth Dism /Online /Cleanup-Image /RestoreHealth
or
WSReset
None, of the ‘suggestions’ work or probably applicable to my situations, but I was willing to give them a go. There was one suggestion that I came across which had some merit. That along with some success stories of people using other people’s internet connections to successfully install the update lead me to believe that the issue is due to corruption in the 8.1 image that is being pulled from the Microsoft update servers which reside in the Akamai CDN.
Now the corruption isn’t a worldwide issue, though using 2 different DNS servers in Australia, while blocking outbound connections from my network to the nearest Akamai servers to me, I still got the error.
Using Google DNS servers would be useless in this case as they have Anycast servers in Australia and will resolve to an Akamai server that would have been the same one previously used.
Due to recent DNS Reflection Attacks, a lot of public DNS have been locked down to serve only users within their network. This makes it extremely difficult to use a different CDN location as the location of your lookup DNS determines which edge server you use.
However, Level3 Anycast DNS servers on 4.2.2.1 -> 4.2.2.6 (a hint I got from this page) are still available to the public and as Level3 do not have a presence in Australia, the lookup will be from a DNS server in North America.
By manually setting the DNS primary and secondary server within the network settings (and disabling the IPv6 protocol as that is active on my network), to use the Level3 DNS servers (as listed above – I used 4.2.2.1 and 4.2.2.2), rebooting and then running the update within the Microsoft Store, the update downloads, checksum matches and the installation continues past the troublesome 50% mark.
Both notebooks now have Windows 8.1 loaded on them and their owners are having a great time with their new machines. I hope this helps a few others out there that are still struggling with this issue.
On a side note, it is very interesting that there isn’t maintenance scripts that are run on the Akamai nodes to verify the checksum of files between nodes. It would ensure that their customers (and their customers) would have a uniform experience, worldwide. Maybe there are some sort of maintenance, I am only making a judgement on small, anecdotal evidence, but in this case it does appear that corrupt caching can occur and be replicated further.