Earlier this week, users of Legacy Update started reporting errors when checking for updates on Windows 7.
The most common variant of this is error 80728015 when checking for updates. That error code is documented with the message:
An operation did not complete because the registration of the service has expired.
Interesting - “registration” of “services” usually relates to Microsoft Update, which extends Windows Update (the naming is terrible, I know) with the ability to receive updates beyond just Windows itself, including updates for Microsoft Office, Visual Studio, and SQL Server, as well as free software offers such as Windows Search, Microsoft Security Essentials, and Microsoft Edge.
Rather than an error code, some users instead got a very misleading error dialog:
Windows Update cannot currently check for updates, because the service is not running. You may need to restart your computer.
However, the service is in fact running, and a system restart has no effect.
As spotted by Douglas Reno, who works alongside me on the Legacy Update project, when we peek at the “authorization” XML file used to specify how Microsoft Update should be configured, it lists an expiry date of 2025-07-01, at midnight UTC.
Here is the file, reformatted for brevity:
<ProviderAuthorizationInfo>
<ServiceID>7971f918-a847-4430-9279-4a52d1efe18d</ServiceID>
<CabVersion>8110</CabVersion>
<IssuedDate>2017-12-01T00:00:00.0000000-00:00</IssuedDate>
<ExpiryDate>2025-07-01T00:00:00.0000000-00:00</ExpiryDate>
<RedirectUrl>http://ds.download.windowsupdate.com/v11/2/microsoftupdate/redir/v6-muredir.cab</RedirectUrl>
<RedirectUrl>http://fe2.update.microsoft.com/v11/2/microsoftupdate/redir/v6-muredir.cab</RedirectUrl>
<OffersWindowsPatches>true</OffersWindowsPatches>
<UIPluginCLSID>3809920F-B9D4-42DA-92E0-E26265E0FB89</UIPluginCLSID>
<IsManaged>false</IsManaged>
<CanRegisterWithAU>true</CanRegisterWithAU>
<ServiceUrl>https://fe2.update.microsoft.com/v6/</ServiceUrl>
<SetupPrefix>mu</SetupPrefix>
<LocalizedProperties>
<Language>en</Language>
<Name>Microsoft Update</Name>
</LocalizedProperties>
</ProviderAuthorizationInfo>
This XML file is found inside a cabinet file named v6-muauth.cab. The cabinet is used to attach a digital signature to the file, preventing a man-in-the-middle attack where the XML is modified to hijack users’ devices to use a malicious Microsoft Update server, while still allowing businesses and ISPs to run an HTTP mirror of download.windowsupdate.com to increase download speeds and save on bandwidth.
As you can see from <ExpiryDate>, it definitely stopped working because the expiry date lapsed. As seems to happen too often in our industry, apparently nobody set a reminder to make sure it would be updated in advance of the date.
You might notice that it has an <IssuedDate> of 2017-12-01. That’s fairly recent! After digging further, we learned that this already happened once! On the 4th of that month, Bleeping Computer covered an error Windows 7 users were receiving when checking for updates. That error is 80248015 - pretty familiar, right? Microsoft allowed this file to expire, not on the 1st but rather on the 4th (more specifically, 35 seconds before midnight in US Pacific time, or 8:00 PM UTC), and did not manage to upload a new file until the 6th at 10:02 AM Pacific (6:02 PM UTC). This left Microsoft Update broken for 3 days.
<IssuedDate>2013-12-03T11:59:25.5067616-08:00</IssuedDate>
<ExpiryDate>2017-12-03T11:59:25.5067616-08:00</ExpiryDate>
The fix
…is to just bump the expiry date again. Indeed, yesterday at 7:32 PM Pacific (2:32 AM UTC), 2 days late, that’s exactly what Microsoft did. The file now looks like this:
<IssuedDate>2025-07-01T15:00:08.7715059-07:00</IssuedDate>
<ExpiryDate>2033-07-01T15:00:08.7715059-07:00</ExpiryDate>
Curiously, the timestamps are once again in Pacific time, as a precise number down to the microsecond. This matches how the 2013 version of the file is written.
The 2013 version of muauth.cab lasted 4 years. The 2017 version lasted 7 years and 7 months. The 2025 version will last 8 years. Interestingly, prior versions of the file I can find were issued on 2007-05-02, and are set to expire on 2027-05-02. (These do not appear to still be in use.)
Why does this file expire?
It’s not clear to me why this file needs to expire. In fact, Microsoft agrees. In Windows 8.1, the way Microsoft Update is registered changed, introducing a new component named SLS, which we believe means Service Locator Service. It allows Microsoft to provide different versions of the configuration depending on the Windows version, build number, architecture (x86 vs x64 vs ARM, etc.), language, Windows Update agent version, and other details that can be particularly relevant to your device. By contrast, the same v6-muauth.cab file is shared by all versions from Windows 2000 to Windows 8, which could be running wildly different versions of the Windows Update agent.
Here is how the SLS manifest for Microsoft Update looks for Windows 8.1:
<!-- PRODUCTION MU v6 LIVE -->
<ServiceEnvironment
ServiceID="7971f918-a847-4430-9279-4a52d1efe18d"
ID="MUv6LiveProduction"
Revision="1">
<WUClientData>
<Protocol
clientServerUrl="https://fe2.update.microsoft.com/v6/"
clientServerUrlCR="https://fe2cr.update.microsoft.com/v6/"
reportingServerUrl="http://statsfe2.update.microsoft.com/"
elementVersion="1" />
<SelfUpdate
selfUpdateUrl="https://fe2.update.microsoft.com/v10/3/microsoftupdate"
elementVersion="1" />
<ServiceID>7971f918-a847-4430-9279-4a52d1efe18d</ServiceID>
<OffersWindowsPatches>true</OffersWindowsPatches>
<UIPluginCLSID>3809920F-B9D4-42DA-92E0-E26265E0FB89</UIPluginCLSID>
<IsManaged>false</IsManaged>
<CanRegisterWithAU>true</CanRegisterWithAU>
<ServiceUrl>https://fe2.update.microsoft.com/v6/</ServiceUrl>
<SetupPrefix>mu</SetupPrefix>
<LocalizedProperties>
<Language>en</Language>
<Name>Microsoft Update</Name>
</LocalizedProperties>
</WUClientData>
<StoreClientData />
</ServiceEnvironment>
There are no dates in this file! It appears it never expires. In fact, the cabinet is signed by two certificates that expired in 2019, so there is no concern that it might use expiry dates from the certificate chain (we’ll leave that type of behavior up to Apple…).
The exact path this cabinet file can be found at is much more complicated. I split it across multiple lines for clarity:
https://sls.update.microsoft.com
/SLS
/{7971F918-A847-4430-9279-4A52D1EFE18D}
/x64
/6.3.9600.0
/0
?CH=424
&L=en-US
&P=
&PT=0x59
&WUA=7.9.9600.17092
As you might have gathered by now, {7971f918-a847-4430-9279-4a52d1efe18d} is the unique identifier for the Microsoft Update service. Microsoft loves to use GUIDs for everything.
What to do if you’re affected by this
This section is no longer necessary, but I already wrote it and took nice screenshots, so…
To avoid this for now, disable Microsoft Update.
You can do so by going to Start → Control Panel → Windows Update → Change settings, and unticking “Give me updates for Microsoft products and check for new optional Microsoft software when I update Windows” (Windows 7) or “Give me updates for other Microsoft products when I update Windows” (Windows 8).
If you use Legacy Update, we detect the error and display a useful explanation of the issue, and offer to disable Microsoft Update for you.
If you already disabled Microsoft Update to work around this issue, you can install Legacy Update again to re-enable it.
As I’ve now learned that SLS was introduced in Windows 8.1, not Windows 8 as I previously assumed,1 we’ve tweaked the upcoming Legacy Update 1.11.1 release to offer a checkbox to enable Microsoft Update on Windows 8 and 8.1, in addition to Windows 7 as we already did. It doesn’t hurt to have the option anyway - the method of registering for Microsoft Update is the same on every version of Windows from 2000 SP3, to 11 25H2.
Post-mortem
When the issue first showed up, we brainstormed a number of ways to work around this issue, in case Microsoft decided to forego fixing this. Fortunately, we didn’t need to use any of those options.
Windows 7 and later, at least for now, continue to be fully supported by the official fe2.update.microsoft.com service (ignoring bugs that prevent Windows 7 and 8 from completing update checks out-of-box). Legacy Update hosts a proxy service to connect to this server, which we use on Windows 2000, XP, and Vista. Due to the way Microsoft Update is designed, configuring a custom server in the registry also inherently allows it to receive Microsoft Update updates. It also means the expiry doesn’t apply, because the authorization file is no longer relevant. This is the workaround we most likely would have used.
By the time we reach July 2033, I expect that standards of secure TLS versions and ciphers will have already increased, locking Windows 7 out from Windows Update. This would require Legacy Update to configure its proxy server to fix Windows Update access on Windows 7 devices. We’ll just need to wait and see what the next 8 years are like.
-
Introducing SLS with Windows 8 made sense in my mind, since this is the version of Windows that launched the Windows Store, which is built on Windows Update. Windows 8.1 somewhat acted as a prototype of the “Windows as a Service” model, so I can see this rather being an early stage of the major changes Windows 10 would make to servicing. ↩