Patching is critical. Patching is routine. Nothing should go wrong with applying properly QA tested official patches from a main release channel, right?
"I got a bad feeling about this. Chewy..."
Sometimes a patch contains a whole collection of modifications for a variety of things, this is a 'rollup'. Sometimes updates contain modifications to drivers or micro-code. Sometimes both these things are the case, and sometimes this doesn't go very well.
This is the second time in as many months this has happened to me, at least this time around it wasn't a domain controller (so grateful for that failover clustering of AD & DNS).
I decided this issues must be common enough to warrant sharing resolution steps with other steemians in case it may be of use to them should they find themselves afflicted with the unexpected and unfortunate circumstance.
ℹ️ Although these anecdotes and steps originated from resolving the issue on Windows Server 2016 the principles and tools (and faults) are relevant to and compatible with Server 2012 and Windows 10.
If you update regularly (and you should) then you can be pretty sure an update is the culprit if it has been the only system modification that has happened today/this week and immediately prior to the boot failure.
⚠️ You should always employ the proper steps in root cause problem identification and isolation to determine to your satisfaction the correct course of action.
Removing Patches By Commandline Using DISM
Boot the system from Windows Installation disc/ISO, or if you have an intact boot partition press F8 after BIOS to invoke the Windows boot menu then select Select Repair Your Computer.
- Select Troubleshoot
- Select Advanced options
- Select Command Prompt
You can open notepad so you have a means of temporarily storing multiple long update package names, just call it by name from the command prompt then switch back to the command prompt:
notepad
Confirm the drive letter for the Windows image, in normal circumstances it's C: but tends to mount on a different letter in the Recovery Console, usually D:. The easiest method of determining this is to check if you recognise the file/directory output using "dir" and the letter to check:
dir D:
Once the Windows image drive letter has been determined, run the following DISM command to output a list of installed packages including installation dates, substitute X with your drive letter:
Dism /Image:X:\ /Get-Packages
Check the output for package(s) with State : Installed and a date correlating with the last change/failed reboot.
Package names are long & can be mistyped easily (if you haven't seen one before, here's an example: Microsoft-Windows-ServerCore-SKU-Foundation-Package~31bf3856ad364e35~amd64~~10.0.14393.0) so take advantage of console editing with the mouse:
- Click & drag to select text
- Enter to copy
- Right-click to insert at current cursor position
- Don't forget that you can use notepad to temporarily store these package names if addressing multiple packages
Run the following DISM command against each package to be removed, substitute X for your drive letter and PACKAGENAME with the actual package name:
dism.exe /image:X:\ /remove-package /packagename:PACKAGENAME-GOES-HERE
Example:
dism.exe /image:X:\ /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~amd64~~10.0.1.0
⚠️ NOTA BENE: When done, reboot the computer using this command:
wpeutil reboot
Good luck, and never tell me the odds.
As always, STEEM ON!
^vote, resteem, and comment below. Considerable effort has gone into researching, testing, and formatting for this article.