• Caution: Windows 7 August Monthly Patch might cause BSOD

    Home » Forums » AskWoody support » Windows » Windows 7 » Windows 7 patches » Caution: Windows 7 August Monthly Patch might cause BSOD

    Author
    Topic
    #1910739

    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.

    Viewing 7 reply threads
    Author
    Replies
    • #1910744

      Which patch (KB number) and 32-bit or 64-bit?

      On permanent hiatus {with backup and coffee}
      offline▸ Win10Pro 2004.19041.572 x64 i3-3220 RAM8GB HDD Firefox83.0b3 WindowsDefender
      offline▸ Acer TravelMate P215-52 RAM8GB Win11Pro 22H2.22621.1265 x64 i5-10210U SSD Firefox106.0 MicrosoftDefender
      online▸ Win11Pro 22H2.22621.1992 x64 i5-9400 RAM16GB HDD Firefox116.0b3 MicrosoftDefender
      • This reply was modified 5 years, 7 months ago by geekdom.
    • #1910910

      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.

      1 user thanked author for this post.
      • #1910936

        It’s been rather a rocky month for patches. You may want to start by reading here:
        https://www.askwoody.com/forums/topic/august-2019-security-patches-its-a-biiiiiiiiig-month/

        On permanent hiatus {with backup and coffee}
        offline▸ Win10Pro 2004.19041.572 x64 i3-3220 RAM8GB HDD Firefox83.0b3 WindowsDefender
        offline▸ Acer TravelMate P215-52 RAM8GB Win11Pro 22H2.22621.1265 x64 i5-10210U SSD Firefox106.0 MicrosoftDefender
        online▸ Win11Pro 22H2.22621.1992 x64 i5-9400 RAM16GB HDD Firefox116.0b3 MicrosoftDefender
    • #1911210

      I had this happen and I fixed it after 4 hours of trying every repair tool known to man (Im betting it was all the tools out there). Nothing fixed it and even booting the windows install disk wouldn’t allow rolling back the update via restore points.

      Solution? I removed all of the drives from my machine except the OS drive aka C drive and when I booted it up with the single drive it went right into windows.

      I restarted another 3 times to get the remanded of the drives back in one at a time to play its safe and it went into windows just fine with no errors. Weird. But it worked.

      This is on windows 7 pro in an alienware with :

      c drive ssd operating system drive
      e drive 4 tb data drive
      g drive ssd data drive for games
      q drive blu ray burner

      Hope this helps someone. That was a scary 4 hours.

      • #1911214

        Look in the BIOS and be sure that your C: drive is your primary boot drive.

        • #1911216

          The drive letters are not set in the bios of machine. The primary drive in the boot sequence was always the ssd that had the os on it. Also I hadnt been in the bios till AFTER the black screen of death from the windows up.

          Previous to the update c drive was the OS drive. 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. All drives removed except the ssd with the operating system on it caused it to return to being seen as C drive and the machine went into windows fine. I added the other drives back one at a time and no more problems. All I can figure is the update scrambled the drive identifiers. Having nothing but the ssd with the operating system installed straightened it out. This is after 50 reboots or more trying different repair disc I had so simply rebooting didnt work. Even the windows install disk refused to roll back the update too.

          Crowz

           

          • #1911219

            There has been reports of a similar drive letter assignment problem on some versions of Win10 also. Wonder what MS is doing with the updates?

      • #1911383

        Is your C SSD drive a NVMe SSD? I read that the August updates are causing black screens for people with NVMe drives. Maybe your drive removal thing is the solution.

        • #1911439

          The c drive ssd is a samsung 840 pro sata drive. I had read the warning on the nvme issues before installing the update and figured I was safe since my ssd’s are plain sata drives.

    • #1911386

      @ 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):

      MountedDevices-in-Registry

      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.

    • #1911389

      It looks like if you are using x64 (or IA64) with UEFI Boot and did NOT install KB3133977 this can happen.

      Under known issues:

      https://support.microsoft.com/en-us/help/4512506/windows-7-update-kb4512506

      I had a server and laptop fail to boot this AM and both are x64 w/UEFI and did not have KB3133977 installed.

    • #1911404

      Confirming that following the steps here (linked from the KB4512506 article):

      https://support.microsoft.com/en-us/help/4472027/2019-sha-2-code-signing-support-requirement-for-windows-and-wsus

      … under the last heading that refers to 0xc0000428 fixed the boot issue.

      Microsoft: checking for KB3133977 before installing KB4512506 isn’t that difficult!

    • #1911461

      I wonder why they refer to KB3133977 when it has been replaced by KB3125574.
      Also does anybody know what “were provisioned after the July 9th updates” means in the known issues section where it says “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…”

      Windows 10 Home 22H2, Acer Aspire TC-1660 desktop + LibreOffice, non-techie

      • #1912793

        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

        1 user thanked author for this post.
    • #1911473

      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?

      1 user thanked author for this post.
    Viewing 7 reply threads
    Reply To: Caution: Windows 7 August Monthly Patch might cause BSOD

    You can use BBCodes to format your content.
    Your account can't use all available BBCodes, they will be stripped before saving.

    Your information: