My colleagues over in enterprise product support often get corporate customers who report that “Your latest update broke our system.” After studying the problem (which is usually quite laborious because they have to go back and forth with the customer to capture logs and dumps and traces), they eventually conclude that, actually, the system was broken even before the upgrade! Their prediction is that if the customer takes an affected system and rolls back the update, it will still be broken. And if they take a system that hasn’t yet taken the update, and reboot it, it will also be broken in the same way.
And the prediction is true.
What is going on is that three weeks ago, the company’s IT department updated some software or installed a new driver or deployed some new group policy that they saw in a TikTok video or something, and the new policy does some really sketchy things like changing security on registry keys or reconfiguring services or changing some undocumented configuration settings. The software updates or the new driver or the new group policy renders the machine unbootable, but they don’t notice it because they don’t reboot until Patch Tuesday.
And then Patch Tuesday comes around, the update installs, and the system reboots, and now the new software or the new driver or the sketchy configuration settings kick in to make their lives miserable.
It wasn’t the update that broke their system. It was the fact that the system rebooted.
Windows should keep the information about planned reboot which requires to complete a component update, for example, after installation of new driver. Windows Update could check this and suggest user to manually restart OS after downloading the system update but before start of applying it. After that, the possible mess with different updates will be resolved.
@Raymond Chen
I know there are such cases, but you really picked a bad time to argue how "It wasn’t the update that broke their system" after several KBs starting with November 2025 until the end of February 2026 were a patch upon a patch of what previous update has broken including NVIDIA drivers. At least it seems Pavan Davuluri is keeping his word -- he promised he will make Windows 11 more stable, there's no better way to do that than by making updates impossible to install like the March 26th KB5079391.
Disclaimer: I am aware that your posts are pushed...
So how would you phrase it so it doesn’t sound like excuse-making? “Gosh, you won’t believe what some people do! They cause a problem and blame the update!”? No wait, that sounds like it’s making excuses for bad updates. How would you phrase this so it’s not making excuses but rather pointing out “Sometimes people shoot themselves in the foot and don’t realize it”?
(replying to later comment): “Alternative and less inflammatory title could be ‘The update didn’t break the system, the reboot did’.”
I don’t think that helps any. The people who misinterpreted the original title would also misinterpret this one as “Microsoft shifts blame for bad updates to users rebooting their systems.”
> “‘How to tell between update-induced and reboot-triggered failures’ if you wanted to be more precise.
Except that the article doesn’t teach you how to tell the difference between them, so it’s not a “How to”.
@Raymon Chen
Your current title focuses on placing blame instead of on determining causation.
Alternative and less inflamatory title could be "The update didn't break the system, the reboot did" or "How to tell between update-induced and reboot-triggered failures" if you wanted to be more precise.
The excuse-making vibe in your article comes from the fact that, to a user, the distinction is academic. If a machine doesn't boot after an update, the update is the catalyst, even if it wasn't the root cause. Acknowledging current poor state of Windows servicing at the start of the article with a single paragraph before proceeding...
Wrong! My two older PC’ all update from Win 10 had no problems. My newest PC (2 months) with much less software and a relatively clean installation failed. It had restarted after the last major Winn11 update to 25H2 and had no intervening installations eexceo for security updates all of which were fine. The problem is not what Mr. Chen suggests, and the recent patch makes everything work fine. Find the real problem to avoid in the future.
Who's to blame when a system stops working completely once a specific update is installed? I've got a slightly older ARM64 tablet that works fine until about September 2025 24H2 updates; installing 25H2 or installing (IIRC) December 24H2 update causes it to spin forever at the boot screen, this happens even if I do a clean install (also happens if I try booting the installer with new enough update integrated).
I also tried installing 26H1, which works until the moment Windows Update downloads the manufacturer's driver pack, after which the tablet starts BSODing a few seconds after the login screen appears...
I think people are reading into this article more than I wrote. I wrote that problem is “often” that the system was always broken. Not “always” or even “usually”. But it happens often enough to mention.
I admit I had a visceral reaction to this post. After sitting with it, I think the scenario you’re describing is really a symptom of technical debt and poor environmental hygiene. It absolutely happens.... especially in environments without proper test rings, change control, or regular reboot cadence.
But I’d be careful not to treat this as the default explanation when a support ticket hints at a broader pattern. For example, if a deployment fails in an environment with enforced test rings and weekly mandated reboots (via SCCM/Intune), my first instinct wouldn’t be to blame the reboot for exposing a latent issue....
I didn’t say that it was “always” or “usually” the reason. Just that it is “often” the reason, meaning that it happens frequently enough to be worth mentioning.
(Replying to reply) It’s definitely not the first place to look, and it’s not usually anything you can even investigate until after you find the smoking gun. If you ask “Did you reconfigure the systems lately?” they’ll say “Of course not!” It’s only something you can say after you find the bad configuration that is causing the problem and say, “According to the timestamps, it looks like you changed the XYZ configuration about 10 days ago at 3:12pm, does that ring a bell?” And then maybe you’ll get an answer of “Oh, now that you mention it…”
Totally fair! I didn’t read your post as claiming it’s universal. My point was just that in disciplined environments, the reboot‑exposes‑latent‑issue pattern is statistically less likely than other root causes. Your scenario is real; it’s just not the first place I’d look in a well‑maintained estate, which is the goal (I would hope) in any environment.
Normally I discount anything M$ says, but if it’s coming from Raymond Chen you should take notice because he’s one of the few geniuses that MS still employs.
Set your hatred of MS aside and read what he’s saying because I guarantee there’s some truth in there.
n) The update was not actually installed/applied (for unspecified reasons), but the user thinks it was, and still blames the update.
The most fun one I've had on this line is "An update broke my CPU fan".
The computer had a BIOS that would refuse to boot if the CPU fan wasn't detected and running (and the OEM who supplied it always used 4 wire fans so that the BIOS detection of "fan not running" was accurate). It also had a CPU that was modern enough (IIRC one of the NetBurst Celerons, so a cut-price Pentium 4 derivative) to throttle instead of shutting down or dying if it overheated, and the use case wasn't one that put significant load on the CPU.
As...
Necessary conclusion:
never reboot.
alternate workaround:
never apply updates or changes to the system.
More seriously one of the joys of using windows 10 TODAY is no more updates requiring forced reboots. Feel free to mention the obvious downsides if you must, but it’s undeniable that the update train is no fun to ride.