Sorry Dave, I’m afraid I can’t do that! PCs refuse to shut down after Microsoft patch We're not saying Copilot has become sentient and decided it doesn't want to lose consciousness. But if it did, it would create Microsoft's January Patch Tuesday update, which has made it so that some PCs flat-out refuse to shut down or hibernate, no matter how many times you try. In a notice on its Windows release health …
I had something similar happen whilst installing DOS6.
In that case though it was the on/off rocker switch on the PC chassis that had chosen THAT EXACT moment to weld it's contacts shut (it was switching the PC itself and an EGA CRT monitor on the auxiliary mains output from the chassis. I guess it didn't like the monitors degaussing coil.
I had that happen on an ancient 286-8Mhz machine, except the switch welded itself in the off position. Shortly after I bought it I realized I needed to update the bios to play a game, I found out the company had changed their name. The phone number I had for them didn't work. I finally tracked them down by their new name, Dell. After pricing a new power AT supply, I tossed it and bought a Pentium.
"I had that happen on an ancient 286-8Mhz machine...and bought a Pentium."
So, you missed out on all the joys of owning 386 and 486 generation machines...and jumping from a 1982-spec 8 MHz 286 to (at the earliest) a 1993 60 MHz P5 (aka 586) - that was taking a huge leap forward !!
And just in time to benefit from Windows for Workgroups 3.11 (or Windows NT 3.1, if you were in a corporate environment !!!)
I only ever bought one desktop machine. A shop built 386, that evolved over the years into a Pentium. Via several motherboards, hard disks, memory. CD drive, DVD drive, several Windows versions, one case, and one PSU. Oh and a replacement floppy disk drive. I kept the mains lead for continuity.
> Dell. After pricing a new power AT supply, I tossed it and bought a Pentium.
Was that the one with the Dell proprietary PSU and Motherboard connectors? We had a job lot of Dell Pentium (200MHz if I remember correctly) desktops for work in a deal, come a couple of years later a combination of windows NT 4 and not a lot of ram (minimum spec as the bean counters got involved in the purchase) even had office 97 running like a dog.
Looked at upgrading and quickly shut the lid as just about everything was Dell proprietary stuff.
"About a year ago, I was called out to do field service. When I got to the lady's house and was let in, the first thing I noticed was the smell of gunpowder. The second, the double barreled 12-gauge shotgun lying on the couch. Third, the big gaping hole in the side of her computer."
www.rinkworks.com/stupid/cs_abuse.shtml
I suggest the downvote was because holding the power button will force a power cut, rather than a graceful shutdown, leaving windows in a state where at worst, it won't boot up because of some corrupted files, or at best take longer to start up as it has to rebuild a lot of the system state. Or it may detect the failed shutdown and restart in safe mode, which is fine because you can simply restart from safe mode and ... oh, err.
Windows refusing to shut down was a feature introduced in Windows 98. Actuallly it may have been present in Windows 95, but since W95 without a huge raft of patches could generally be counted on to crash before the user was really finished, it wasn't so noticable there. Anyway, back then on W98 one could generally check the disk activity light. If nothing was going on, it was almost always safe to amputate the power -- except that Windows would chide you on the next boot about your carelessness in not shutting down properly and run a (slow) scandisk before booting. There were, incidentally, dozens of documented issues that could cause Windows 98 to refuse to shut down.
So, it appears that what's old is now new again. It is sort of pleasant (for us non-windows users) to see tradition being respected
Back in the Windows NT days I pretty much always just powered off the PC. WindowsNT, unlike Windows9x, didn't do any soft power-off, so a shutdown ended with a message saying the PC could now be powered off. Didn't want to wait for so instead of performing a shutdown + power-off I just powered off the PC. Might have just been lucky but I never had any data loss or filesystem issues.
There was a patch for that. Forgotten if it was a registry hack, or involved replacing a DLL now. But basically as I went around abusing^Whelping users, I installed the appropriate fix.Was not something obvious-
Might have even been something that need to have SP 3+ installed for it to work.
Windows 2000 could power off all by itself! Which is why (among other reasons) it is peak Microsoft operating system. Everything since then has been 1 step forward, 2 steps back.
I used to do the same thing! I had desktop shortcuts for reboot, shutdown now, and shutdown in 30 min.
Whatever I was using at the time for remote access didn't allow the remote user to power off the remote PC. Might have been Windows Remote Desktop or maybe Radmin, can't recall.
I always used to yank the power cord out of the PSU, curse Windows (yet again) then plug the cord back in and start again. That said, whilst this is just a case of Windows being Windowy, i.e. just not fucking working properly at all, I think it's a bit harsh to take it out on the hardware which has no say in the matter. When the OS doesn't OS like it should do, it's time to consider a different OS. And with certain hardware prices now being insane, you definitely want to avoid an unwarranted PC purchase right now.
"I'm curious if any other reg readers have a creative way to persuade a stubborn Windows system to shut down, other than the command mentioned in the article."
You could follow in the footsteps of Dr David Bowman, and just take off the cover of the PC and start disconnecting/removing components...start with network cable, non-booting SATA drives, usb components (mouse/keyboard (BUT not speakers) then disconnect the case fan power cable(s), the CPU fan power cable.
That should be enough for the PC to start singing "Daisy Bell"...and to know it was going to be TERMINATED (if you are American!) or EXTERMINATED (if you are British !)
Windows refusing to shut down is nothing new. I have experienced this issue many times over the years. I had a work machine once that habitually refused to shut down. In the end, I just didn’t bother - I just switched it off at the end of the day. I wouldn’t do that with my own PC but that will never have windows running on it either
"Just be happy Microsoft don't do planes, cars or trains. There would be dead bodies everywhere."
For planes, just substitute Microsoft with Boeing...
For cars, substitute Microsoft with Tesla...
For trains....well USA doesn't have much of a rail network, so for now, you just might be safe. And usually when a train has a problem, it's usually not the fault of the train itself, but its more likely to be the the driver, the signaling system or some external influence, like a landslide, a truck stuck on a level crossing or a crane crashing onto it (RIP those affected in Thailand)
Microsoft in fact are somewhat responsible for a plane falling out of the sky thanks to their quality software (the hardware needed to run an in-flight entertainment system that used windows NT 4.0 for a few seats needed large amounts of power); https://en.wikipedia.org/wiki/Swissair_Flight_111?useskin=monobook#In-flight_entertainment_network
Microsoft is also at least partially responsible for many other deaths - the dead bodies everywhere are simply covered up.
For a while (circa RHEL/CentOS 7) it sort of did, albeit accidentally (we assume).
I'm referencing the stall (long countdown, at least) systemd occasionally did back then, where you'd issue a reboot/shutdown, and systemd would pause at some point with a timer while it tried sorting out something it couldn't grok from its dependency tree(?) or thereabouts. As I recall it lasted for ~90-120sec or so, couldn't interrupt it, aside from the mains plug or the switch/button.
I haven't seen it in a while, so maybe it got fixed (accidentally?) eventually. More likely because I'm running more BSD systems, and fewer systemd Linux these days.
Systemd did this to me in 2016. It was the first boot of a Dell XPS 13 that came with Ubuntu pre-installed. And it was worse than this Windows case: resorting to the command line to issue a shutdown command didn't work (it just produced a message from systemd saying the action would be "destructive" IIRC).
After holding down the power button to turn it off, the next thing I did was install Debian with sysvinit (which was usable back then; these days I run Devuan).
Agent P caused this on machines that did *not* use systemd. After they usurped udev, they changed the shutdown event sequence to suit systemd. Machines with a LUKS encrypted boot partition hung on shutdown because the trigger to close down the encryption arrived too late.
The legends of the fsck-ups just grow longer. I remember we had an issue where the PC would shut down, but would then immediately start up again. No. It was not Wake On Lan, There was no WOL activity on the network and traffic analysis revealed there were no WOL packets being received by the machines that re-awakened. Of course they didn't wake when the LAN cable was unplugged. This unwanted restart was being caused by a lack of the manufacturers (Intel) device driver. In the driver configuration settings, there was a tick box for Wake on Pattern Match that had to be disabled. That option was not provided with the Micros~1 driver. A simple solution until a Windows update re-installs the Micros~1 driver in favour of the manufacturers driver and your back to square one.
It gets worse. I can recall we had a classroom where we needed the machines to dual boot. One install of the OS booted into the domain and the users were just users. The other OS on the same drive booted to allow the users to be administrators on these machines and were therefore not on the domain. Additionally, the two OS's booted to different vlans. The Intel NIC had a utility that allowed a preferred vlan to be set according to one OS or the other. Windows updates repeatedly re-installed the Micros~1 driver in spite of it being older than the Intel one. Cue revisiting every machine and reinstating the latest Intel driver. Only for Micros~1 to replace it at the next update. Then Intel removed the utility and the vlan setting had to be done using PowerShell. Of course Micros~1 blamed Intel and Intel blamed Micros~1. We had to give up and find another solution but that's another story.
I "fondly" remember having a laptop running Windows 10 home that used to do just that. I could be anywhere (overseas, at work, etc) and it would randomly power on and promptly flatten its battery.
I remember being at college during Windows XP's heyday and the desktops in the computer lab often doing the same thing, either getting stuck when trying to reboot or just refusing to shut down altogether. Nice to see the inclusion of AI has fixed all of that. /s
I had a laptop that was running Windows, and it had "wake on activity" enabled that I couldn't disable. So part of the shutdown process was to physically unplug the mouse dongle or explicitly switch off the mouse, within a few seconds of shutting down, or the slightest movement would wake up the laptop again, leaving it with a flat battery of course the next time I wanted to use it. Lifting the lid to check if the shutdown had worked indicated that yes it had, because it was now booting up again thanks to the lid movement!
I replaced windows with Linux and that laptop has been fine ever since.
> "wake on activity"
powercfg.exe /lastwake
eventvwr.exe : Import this xml.
You may end up discovering some "WindowsUpdate orchestrator" waking you your box at night like I did, at least if it is Windows 10 or 11. Quite annoying, but can be fixed.
<ViewerConfig><QueryConfig><QueryParams><Simple><Channel>System</Channel><RelativeTimeInfo>0</RelativeTimeInfo><Source>Power,Microsoft-Windows-Power-CAD,Microsoft-Windows-PowerCfg,Microsoft-Windows-PowerCpl,Microsoft-Windows-Power-Meter-Polling,Microsoft-Windows-Power-Troubleshooter</Source><Level>1,2,3,4,0,5</Level><BySource>False</BySource></Simple></QueryParams><QueryNode><Name>Power</Name><QueryList><Query Id="0" Path="System"><Select Path="System">*[System[Provider[@Name='Power' or @Name='Microsoft-Windows-Power-CAD' or @Name='Microsoft-Windows-PowerCfg' or @Name='Microsoft-Windows-PowerCpl' or @Name='Microsoft-Windows-Power-Meter-Polling' or @Name='Microsoft-Windows-Power-Troubleshooter'] and (Level=1 or Level=2 or Level=3 or Level=4 or Level=0 or Level=5)]]</Select></Query></QueryList></QueryNode></QueryConfig><ResultsConfig><Columns><Column Name="Ebene" Type="System.String" Path="Event/System/Level" Visible="">145</Column><Column Name="Schlüsselwörter" Type="System.String" Path="Event/System/Keywords">70</Column><Column Name="Datum und Uhrzeit" Type="System.DateTime" Path="Event/System/TimeCreated/@SystemTime" Visible="">195</Column><Column Name="Quelle" Type="System.String" Path="Event/System/Provider/@Name" Visible="">105</Column><Column Name="Ereignis-ID" Type="System.UInt32" Path="Event/System/EventID" Visible="">105</Column><Column Name="Aufgabenkategorie" Type="System.String" Path="Event/System/Task" Visible="">106</Column><Column Name="Benutzer" Type="System.String" Path="Event/System/Security/@UserID">50</Column><Column Name="Vorgangscode" Type="System.String" Path="Event/System/Opcode">110</Column><Column Name="Protokoll" Type="System.String" Path="Event/System/Channel">80</Column><Column Name="Computer" Type="System.String" Path="Event/System/Computer">170</Column><Column Name="Prozess-ID" Type="System.UInt32" Path="Event/System/Execution/@ProcessID">70</Column><Column Name="Thread-ID" Type="System.UInt32" Path="Event/System/Execution/@ThreadID">70</Column><Column Name="Prozessor-ID" Type="System.UInt32" Path="Event/System/Execution/@ProcessorID">90</Column><Column Name="Sitzungs-ID" Type="System.UInt32" Path="Event/System/Execution/@SessionID">70</Column><Column Name="Kernel-Zeit" Type="System.UInt32" Path="Event/System/Execution/@KernelTime">80</Column><Column Name="Benutzerzeit" Type="System.UInt32" Path="Event/System/Execution/@UserTime">70</Column><Column Name="Prozessor-Zeit" Type="System.UInt32" Path="Event/System/Execution/@ProcessorTime">100</Column><Column Name="Korrelations-ID" Type="System.Guid" Path="Event/System/Correlation/@ActivityID">85</Column><Column Name="Relative Korrelations-ID" Type="System.Guid" Path="Event/System/Correlation/@RelatedActivityID">140</Column><Column Name="Ereignisquellname" Type="System.String" Path="Event/System/Provider/@EventSourceName">140</Column></Columns></ResultsConfig></ViewerConfig>
Its almost like it was meant to be that way, to keep the machines on. So many possibilities MS can do with these machines now. I found an AI removal script here https://github.com/zoicware/RemoveWindowsAI?tab=readme-ov-file
If they are going to hold your machine hostage, might as well reduce your power bill by running less programs, especially programs you don't want that everyone else except you will profit from lol. Thats how they are doing it, sticking the bill to everyone for something they didn't ask for.
That Microsoft can have a big screwup in EVERY SINGLE Windows 11 patch cycle? Sure they had problems occasionally in Windows 10 and previous versions, but nothing like the rate of fuck ups we've seen connected with Windows 11! Is it cursed? Is "11" an unlucky number in some culture, and if so which because I want to know what other superstitions they may have gotten right?
have faint recollection of Windoze lore that every uneven release is rubbish, only even numbered releases were stable enough to use. How many decades of OS production has M$ done ? How many for the IT industry, yes, you, IBM over there in 1964 with IBM360. So in 62 years commercial OS quality has gone backwards. How long could VMS stay up and do data center moves without shutdown ? Unices doing 1000 days plus uptime not unusual. QNX being able to do patching and not need reboot 2 decades? ago
"every uneven release is rubbish"
I can see that odd doesn't cover it — everything Microsoft is decidedly odd. But then even the best of Microsoft† is extremely uneven ressembling the terrain of Death Valley one imagines.
† probably an undefinable concept as anything Microsoft offers is worse than everything else it offers.
I think that the record for a VMS Cluster is around 15 years. Right from day 1, VAXClustering allowed rolling updates. Do one node at a time when you want and not when (At the time DEC/Compaq/HP wanted).
Then it had a clusterwide filesystem.... Then Dave Cutler went to MS and the rest is history... (visions of Eddy The Eagle trying to ski-jump)
I spent 20 years at DEC/Compaq for my sins.
After working on VMS (single VAX 11/780, pre cluster) I went to work at an IBM mainframe site that ran 3 machines in an MVS/JES3 complex, IBM speak for a cluster.
We used to take each machine down once a month for upgrades and fixes, and while each one was down limited work could carry on on the other processors as they all could see and access the storage, tape drives etc.
Another place I worked at had Solaris systems that had uptime measured in years.
Windows 10 wasn't really any better. So many updates broke basic shit, so unsurprisingly that tradition is continuing on Windows 11. In fact, this situation started with Windows 10 and Nadella becoming the CEO. After all, it was also Nadella who thought quality control could be moved from department of engineers to end users.
Windows not shutting down when ordered to is nothing new. For a very long time, starting in Windows 10 and continueing in Windows 11, when WIndows wanted to install updates and the user selected 'install & shutdown' then, following the updates and a reboot, Windows did no such thing but sat there at the login screen, and when the user logged in then it executed the shutdown.
Which meant users selected 'install & shutdown' at the end of their working day and went home, only to come back in the morning with their PC powered on and sitting at the login screen. When they then logged on the PC shut down.
Apparently, this was because some updates had to be installed in a Windows user context, so Microsoft's developer thought let's just wait for any user to login instead using one of Windows' system context or some built-in mechanism.
At the workplace we have a large fleet of HP Elitebooks / Probooks, all of varying ages. Mine until recently was a very pre-loved 2018 model with an increasingly weak battery, to the extent it couldn't last an hour on battery just at idle. Naturally Windows Update decides while away from my workbench that this is a good time to reboot and tried to apply a BIOS patch without warning, I stopped it from bricking by borrowing a charger to keep it alive.
IT have a cupboard with a fair number of bricked laptops that did exactly the same as mine but had users who didn't understand what was going on.......
A plastic prying tool is also needed to get Horrible Products laptops open with a minimum amount of damage (for example, after the board dies not long after purchase and its sent off for in-warranty board replacement for "expert" handling, where it comes back without the Wi-Fi antenna's plugged in, meaning it needs to be opened back up and the antenna's plugged back in for Wi-Fi to work more than 30cm from the AP).
The battery ballooning (which seems to happen at an alarming rate) may also make it hard to open the laptop up.
Battery wasn't glued in and actually fairly easy to replace given they were internal, only three or four screws once you removed the bottom cover iirc. Sadly there were no spares available. This was in 2021 or so, with PC parts and indeed new PC's being in incredibly short supply, I seem to recall at one point HP were quoting lead times of seven months for new laptop purchases.
The past month of suffering the insufferable Windows 11 on corporate workstations and laptops has told me all I need to know about M$ quality control in patches and updates. The quality and user experience harkens back to the '90s and even then the UI worked better and more consistently. I can't wait to be done with this shop and their full convergence on M$ including phones.
"We will update the topic as we understand the issue better." Let me help: The issue is spending all your time jamming AI into literally everything (Notepad!), focus your diminishing number of developers on quality and reliability - attributes of Windows that have been at an all-time low on Windows 11 since, erm, always. Oh, and fire Nadella. Does that help your understanding the issue?
I wouldn't quibble with your characterisation of (many) Vauxhalls, but running-on could happen with any make back then. Carburettors being purely mechanical devices, switching off the electricity stopped the spark plugs doing their thing, but the carbs kept on sucking in fuel as long as the crank kept turning. Which it did if the cylinder heads and.or pistons had developed sufficient carbon build up to glow red-hot and ignite the incoming charge. Which is why we used to periodically perform the ritual of decoking.
-A.
Running-on, or dieselling because diesel engines just require some fuel, air and the crankshaft turning to carry-on running. Diesels that had an electronic fuel valve that shut off the diesel flow were more immune to it.
Never saw it happen myself but heard horror stories of old diesel engines turned off, but enough piston ring wear meant hot oil vapours blowing by the rings and into the cylinder, igniting due to the compression and then just running faster and faster until either the oil sump vapours ran out or something else went bang. Remedy was to hope you spot it in time and use the clutch and gearbox to stall it.
This post has been deleted by its author
In short, Windows 11 is 5 years old, and it still messes up its updates.
I will have to stick with Win 10, until I die, or until I find someone who can explain LINUX,
and explain how to run sadly essential Windows software on LINUX, because no one from the LINUX tree-house
has been able to program software that works on LINUX,
and hardly any software company makes software for LINUX.
It's really a stupid conundrum!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2026
