|
Patch reliability is unclear. Unless you have an immediate, pressing need to install a specific patch, don't do it. |
And that BSOD = Black Screen of Death after updates are configured and computer needs to restart….
Error 0xc0000025
Microsoft Startup Repair (if you have another bootable device with it) reports the problem is No OS Loader, and is able to repair – but re-installing the Monthly Update will fail again and computer won’t boot.
Which patch (KB number) and 32-bit or 64-bit?
It is 64-bit windows
August Monthly Quality Rollup KB4512506
A number of other reports showing up in searches of the net affecting lots of Windows 7 machines.
@ anonymous in reply 1911216
After the update booting on the windows install dvd showed the OS drive to be E: which is why I tried the drive removal method.
Just FYI–your suggestion that the *Drive Letter E:* was the drive letter assigned to that drive by the Windows OS which was not booting successfully may not be an accurate assumption.
Whenever one boots from removable media–usually the booted software on the removable media assumes it is the OS that is up and running, and it assigns itself the drive letter *C:*, and assigns all other devices a drive letter in accordance with the rules that Microsoft has set up as the priorities of which device gets the next available drive letter to be seen in that booted media software.
So, probably the booted media assigned itself *C:*, and *D:* was assigned to whichever device was on the next controller port that met the priority list for drive letter assignment, and then your Windows OS drive was seen next, and assigned the *E* drive letter, and so forth for the other drives.
(This is strictly guessing–but it’s possible that the Update somehow effected the Windows OS registry listing of the installed drives, and whichever drive was assigned the drive letter *D:* (before the Windows OS drive which was assigned the drive letter *E:*) when you booted to the *Windows Installation DVD* was the first drive letter to be assigned the drive letter *C:* when you attempted to boot to you Windows OS. That being the *wrong* drive, you got a boot failure. It could be that when your system was put together, and possibly updated (upgraded) to new hard drive(s), the drive with your Windows OS was attached to a controller port that is not first in line for a drive letter assignment priorities, but instead in the second place–so it did not get the drive letter *C:*.)
I know–complicated!
Windows keeps the drive letter assignments in the Registry here (MountedDevices):
The highlighted items are the drive letter assignments as seen when your Windows OS has successfully booted. In theory, the tool needed to fix the problem would be something that can open a *remote registry* (one that’s on a different drive and an OS that is not currently active). But, to be honest, I’m not familiar with how to correctly identify which drive is which other than seeing the assigned drive letter that are listed. So if a different drive has the *C:* drive letter that is not the actual Windows OS drive–I would not know how to change things correctly.
I do know that if you highlight all the *DOSDevices(drive letter):* items, and delete them, that forces Window to re-assign drive letters to the attached drives–but, again, if your drives are attached to the motherboard in an order that has the wrong drive in the *first position* to get a drive letter assigned, it will still end up being *wrong*, and you will get a boot failure!
(The items above the *DOSDevices(drive letter):* items are devices that have been previously attached and seen by the OS–mostly USB thumb drives and external USB hard drives–Windows tries to remember the previous devices and tries to assign the same drive letter as before if it is re-attached–unless that drive letter is currently in use by some other device.)
You would have to look at your motherboard documentation to determine which hard drive controller port is first, then second, etc. You could re-arrange which drive is hooked up to which controller port so they are in the order that’s needed to assign the correct drive letter of *C:* to your actual Windows OS hard drive.
Your technique of disconnecting the other hard drives forced Windows to assign the drive letter *C:* to the only remaining hard drive–the correct hard drive with your Windows OS. That information was stored in the *MountedDevices* registry key and remembered. Then by adding back each hard drive one at a time, they were assigned drive letters further down the alphabet. You could use that same technique to re-arrange your hard drives to the ports of your choice, with the Windows OS hard drive being first attached to the primary first port of the motherboard–that’s where the Windows OS first looks to assign the *C:* drive letter.
Maybe all of this helps–you will have to decide for yourself if it makes sense to pursue, and confirm that my suspicions are correct about which port your Window OS hard drive is hooked up to.
KB3125574 is catalog only update, not released for the masses
KB3133977 is the last “standalone” patch that contain the last fixes for Bitlocker and UEFI boot files
Based upon my reading of the instructions contained in the SHA-2 code signing support article mentioned above in anonymous’ post number 1911404, the FAQ mentioning error code 0xc0000428, it seems to me that one can avoid having to resort to those rather geeky steps spelled out by Microsoft by just checking to see if KB3133977 has already been installed before trying to install any of this month’s Windows 7 patches. SO, is the following installation sequence correct??
1. Check for KB3133977 being installed on the machine. If it isn’t, check Windows Update to see if it’s on the list of hidden updates. If it’s been hidden, unhide it and install it by itself, rebooting after the disk activity has subsided. Alternatively, one could try getting it from the MS update catalog and manually installing it that way, rebooting afterwards in the same fashion as if it had been obtained through Windows Update.
2. Install the revised KB4474419 (released August 13th) by itself and reboot after the disk activity has subsided.
3. Install KB4512506 (monthly rollup) or KB4512486 (security only), your choice depending on if you’re Group A or Group B patching. Reboot after disk activity has subsided.
4. Install any other patches of your choosing.
MVP’s please feel free to add any clarification/correct the sequence as needed!
However, I have a question of my own for the MVP’s here, especially @abbodi86 and @PKCano:
After reading the aforementioned KB articles from MS, they mention the error of Windows being unable to verify the digital signature of the file \Windows\system32\winload.efi as part of the IA64/x64 known boot issue with this month’s security only and rollup patches. I have that file already on my computer, dated the day I installed the July rollup patches. The wording of the IA64/x64 issue from MS is “IA64 devices (in any configuration) and x64 devices using EFI boot that were provisioned after the July 9th updates and/or skipped the recommended update (KB3133977) may fail to start with the following error (Windows can’t verify the signature of the file I just mentioned just above)”. (I added the emphasis to the previous sentence). I hid KB3133977 back in 2017 when it came out, because I didn’t need it, as I don’t use bit locker and neither one of my computers is attached to a domain. With all of that in mind, am I good to go by NOT installing KB3133977 and just taking the plunge once we reach DEFCON 3 or above, or is it better for me to follow the sequence I described above in this post, and install KB3133977?
Donations from Plus members keep this site going. You can identify the people who support AskWoody by the Plus badge on their avatars.
AskWoody Plus members not only get access to all of the contents of this site -- including Susan Bradley's frequently updated Patch Watch listing -- they also receive weekly AskWoody Plus Newsletters (formerly Windows Secrets Newsletter) and AskWoody Plus Alerts, emails when there are important breaking developments.
