Artificial intelligence is usually demonstrated by asking it to write an email, summarise a document or generate an image. Those uses are real enough, but they say very little about what AI can do in the hands of someone who already understands the problem in front of them.
We had a more practical example recently. Two Windows Server 2016 Remote Desktop Services (RDS) hosts failed to boot following a routine update cycle. One displayed a BAD_SYSTEM_CONFIG_INFO stop error; both ultimately halted at Windows Boot Manager reporting 0xc0000225 – A required device isn't connected or can't be accessed. These were production systems, so reinstalling Windows was a last resort rather than a first move. Both were eventually recovered without a rebuild, and the update that appeared to have caused the problem turned out not to be the whole story.
Before You Copy Any of This
Windows servicing is stateful, and two machines showing the same stop code can have entirely different underlying faults. Nothing below should be treated as a set of commands to paste into a broken server.
Take a backup or confirm you have a working recovery route before touching a production system. In a virtual environment a checkpoint is a useful short-term safety net while troubleshooting, but a Hyper-V checkpoint is not a backup and should never be relied on as one. Most importantly, do not remove an update package because a package identity appears in an article — always identify what is actually present on your own system.
First, Establish What Windows Is Actually Doing
Error 0xc0000225 normally sends administrators straight towards the BCD, the EFI System Partition or missing boot files, and that would have been a reasonable first instinct. The more useful clue was that both servers had just been through an update cycle, which raised a different possibility: that Windows servicing had been interrupted part-way through committing an update during startup.
That distinction mattered, because rebuilding the boot configuration would have targeted a different subsystem entirely, while DISM provides a supported mechanism for reversing pending servicing operations. Neither is a trivial change — /RevertPendingActions alters the servicing state of Windows — but one was aimed squarely at the evidence we had. The first objective was therefore to find out whether there were incomplete servicing actions that could be reversed.
Booting Into the Recovery Environment
Each affected VM was booted from Windows Server installation media, selecting the recovery options rather than Setup. From the recovery Command Prompt, the first job was to identify the volumes:
diskpart
list vol
exitThis step matters more than it looks. When Windows is started from installation media or the Recovery Environment, drive letters are frequently not the ones the running operating system uses — the Windows volume is often D: or later, and C: may refer to a different partition entirely. Never assume the installation is on C:. We confirmed the correct volume by checking candidates directly:
dir C:\Windows
dir D:\Windows
dir E:\WindowsIn our case the Windows volume genuinely was C:, but the next machine may not be. We also created a scratch directory on that volume and specified it explicitly on every subsequent DISM operation:
mkdir C:\ScratchDISM uses its scratch directory for temporary servicing files, and RAM-disk space in a recovery environment can be constrained. Providing adequate local scratch space removes one variable from an already awkward repair. The directory must exist before DISM is run.
Reverting Pending Servicing Actions
With the Windows volume positively identified:
dism /image:C:\ /cleanup-image /revertpendingactions /ScratchDir:C:\Scratch/RevertPendingActions is a Microsoft-supported recovery operation intended specifically for an image that will not boot where pending servicing operations may be responsible. It is not routine maintenance and should not be run against a healthy running system. DISM reported that the revert would be attempted after the reboot — which is the important nuance. Nothing had been undone at that point; DISM had prepared Windows to reverse the pending operations during the next startup.
On restart the server displayed We couldn’t complete the updates — Undoing changes, which in this situation was exactly what we wanted to see. Servicing rollbacks can sit on an apparently frozen percentage for a long time, and interrupting a machine while CBS is committing or reversing packages is an excellent way to turn a recoverable problem into an unrecoverable one. We left it alone, and it completed and booted normally.
What We Deliberately Did Not Do
Older forum advice frequently suggests deleting pending.xml or removing files by hand from C:\Windows\WinSxS. We did neither. The component store and the Component Based Servicing subsystem maintain relationships between packages, manifests, catalogues and queued operations; dismantling that by hand can convert a recoverable update problem into permanent component-store corruption. Where Windows provides a supported servicing operation, that is the route to take.
Downloaded Is Not the Same as Staged
We also renamed the Windows Update working directory while still offline, preventing Windows Update from simply reusing its existing download and working cache while we investigated:
ren C:\Windows\SoftwareDistribution SoftwareDistribution.oldRenaming rather than deleting kept the original available for later examination. But this is the point that catches people out: renaming SoftwareDistribution takes the existing Windows Update download and working area out of use. It does not reverse servicing operations already recorded in CBS, and it does not remove a package that has already been staged into the component store. That distinction became central to the rest of the investigation.
Once Windows was running again, update activity was stopped properly. Note that sc is an alias for Set-Content in Windows PowerShell, so the familiar sc config line only behaves as intended from a Command Prompt. If you want Service Control syntax from PowerShell, call sc.exe explicitly — or use the native service cmdlets, which are the better choice here anyway:
Stop-Service -Name wuauserv
Set-Service -Name wuauserv -StartupType Disabled
Stop-Service -Name bitsHow updates are ultimately controlled will depend on the environment — WSUS, Configuration Manager or an RMM platform may all have a say. The objective was simply to prevent another attempt until we understood what had happened.
Reading the Servicing State Properly
The obvious first check is Get-HotFix, and it is not sufficient. An update can exist inside the component store without ever appearing as a successfully installed hotfix. The package database tells the fuller story:
Get-WindowsPackage -OnlineThe recovered server showed the previous cumulative update as Installed, while the newer cumulative update — the one from the failed cycle — was still present in a state of Staged. Broadly, Installed means the package is in the operating system; Superseded means a newer package has replaced it; and Staged means the payload is in the component store but has not completed the transition to installed. A staged package is a very different thing from update files sitting in the Windows Update download cache, which is precisely why renaming the cache had not been enough.
The Setup event log confirmed it:
Get-WinEvent -FilterHashtable @{
LogName='Setup'
StartTime=(Get-Date).AddDays(-3)
} | Sort-Object TimeCreated -Descending |
Select-Object -First 50 TimeCreated,Id,LevelDisplayName,MessageWindows was waiting for a reboot before the cumulative package could transition to installed. Another update from the same cycle had completed normally, which identified the cumulative package whose installation had not completed.
Removing the Staged Package
Before changing anything further we discarded the original checkpoint — which now represented a broken machine — and took a fresh one representing the newly bootable state. That gave us a far more useful point to return to.
Package removal must use the identity reported by DISM on that specific machine, obtained from /Get-Packages. Do not lift a package identity from another server or from an article:
dism /online /remove-package /PackageName:<EXACT-PACKAGE-NAME> /NoRestart /ScratchDir:C:\Scratch/NoRestart was deliberate — we did not want DISM restarting a production server before we had verified the outcome. DISM also reached 100% and then sat there for some time before returning. Servicing operations can still be finalising after the progress indicator stops moving, and terminating DISM at that point would be a serious mistake. We waited for it to report completion.
Verifying the Result
“Completed successfully” was not treated as proof. We re-queried the package database and the hotfix list, and neither returned the package. We then checked the two reboot-pending indicators most relevant to servicing:
$CBS = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
$WU = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
Write-Output "CBS reboot pending: $CBS"
Write-Output "WU reboot pending: $WU"Both returned False. The server was rebooted and started normally.
PendingFileRenameOperations under HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager is a third indicator worth checking in a similar situation, though it is populated by installers generally rather than by servicing specifically and can carry entries unrelated to the fault in hand.
Why We Didn’t Blame the Update
At that point it would have been very easy to conclude that the latest cumulative update breaks Server 2016 RDS hosts. The evidence did not support it.
We run a number of comparable Server 2016 RDS hosts, and AI helped us turn the diagnostic questions into a PowerShell script we could deploy across all of them through our monitoring platform — collecting Windows build, recent hotfixes, package identities and states, servicing stack and .NET update state, and pending reboot indicators. Ten other RDS hosts showed the same cumulative update as Installed, the previous package as Superseded, no pending reboot, and no operational problems.
That reframed the investigation. The update was clearly part of the chain of events on the two failed servers, but it had not universally broken anything. The useful question became what was different about those two machines. We eliminated several plausible explanations quickly: the two failed hosts were running different endpoint security products from one another, and their Secure Boot configuration also differed, so neither factor was common to both failures.
What Still Needs Investigating
The servers are operational, but the underlying difference has not yet been proven. The comparison work continues across CBS history and CBS.log errors around the failed update, component-store health, EFI and system partition free space, boot configuration, VM generation and virtual hardware, storage controller and VHDX configuration, filter and printer drivers, older third-party kernel drivers, and whether the affected machines share a common build template.
The defensible conclusion today is that the update was associated with the failure and did not complete on those two systems — not that it caused it. That is a less satisfying headline and a considerably more honest one.
What We Shared With the AI
Because we work with SRA- and FCA-regulated firms, it is worth being explicit about this rather than leaving it as an open question.
What was shared was technical diagnostic material: console screenshots, error codes, DISM and PowerShell output, and event log extracts. Server hostnames appeared in that output, as they inevitably do in real diagnostic work. What was not shared was client business content or end-user data — no documents, mailbox content, databases, credentials or deliberately submitted personal data.
The same rules we apply to any third-party tool applied here: it is used for analysis, not as a repository, and nothing goes into it that we would not be comfortable justifying to a client’s compliance officer.
AI does not change data-handling obligations. It is simply another tool that has to sit inside them.
Where AI Helped, and Where It Needed Correcting
Most experienced Windows engineers already know DISM, DiskPart, PowerShell, the Setup log and the servicing subsystem. The value here was not any individual command; it was holding the whole incident together while it was happening. A screenshot could be supplied and interpreted in context, DISM output related back to the previous boot failure, and — when ten healthy servers contradicted the obvious theory — the contradicting evidence organised rather than explained away. When the investigation needed to widen to the rest of the estate, the diagnostic questions became a working script in minutes rather than an afternoon.
It also got things wrong. At one point it offered Command Prompt redirection syntax while we were working in a PowerShell session, which PowerShell rightly rejected, and an assumption about how our monitoring platform deployed updates had to be corrected by the engineer. That is not a flaw worth hiding — it is the whole point. The engineer knows the environment, judges whether a command is appropriate, and notices when an assumption is wrong. AI contributed speed, breadth and a persistent second pair of eyes. It cannot make a destructive command harmless, and it cannot recover data that was never backed up.
Server 2016 Is Running Out of Road
There is a larger point behind all of this. Windows Server 2016 leaves extended support on 12 January 2027. After that date there are no normal security updates. Microsoft’s paid Extended Security Updates programme can provide eligible customers with Critical and Important security updates for up to three additional years, but it is intended as a temporary bridge rather than a destination.
Two RDS hosts that could not complete a servicing operation are worth recovering properly. They are also a reminder that any organisation still running Server 2016 now has less than five months to complete or firmly plan its migration — and that a rushed cutover in December will cost considerably more than a planned one starting now.
Our View
As a managed cloud provider, the part of this we would highlight is not the AI. It is that the recovery was possible because the fundamentals were in place: checkpoints before every risky step, a known-good rollback position, an estate consistent enough to compare against, and monitoring that could push a diagnostic script to twelve servers in one operation. AI made an experienced engineer significantly faster. It did not make any of those things unnecessary.
The organisations that get value from AI in IT operations will be the ones that already have tested backups, documented recovery procedures and sensible change control — because AI amplifies the capability that is already there. If your Server 2016 estate is approaching end of support and you would rather plan that migration than discover its edge cases during an incident, we would be glad to help.
