News, tips, advice, support for Windows, Office, PCs & more. Tech help. No bull. We're community supported by donations from our Plus Members, and proud of it
Home icon Home icon Home icon Email icon RSS icon
  • 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

    This topic contains 15 replies, has 9 voices, and was last updated by  abbodi86 1 month ago.

    • Author
      Posts
    • #1910739 Reply

      anonymous

      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.

    • #1910744 Reply

      geekdom
      AskWoody Plus

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

      Group G{ot backup} TestBeta
      Win7Pro · x64 · SP1 · i3-3220 · RAM 8GB · Firefox: uBlock Origin - NoScript · HDD · Canon Printer · Microsoft Security Essentials · Windows: Backup - System Image - Rescue Disk - Firewall
      • This reply was modified 1 month, 1 week ago by  geekdom.
    • #1910910 Reply

      anonymous

      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 Reply

        geekdom
        AskWoody Plus

        It’s been rather a rocky month for patches. You may want to start by reading here:

        August 2019 Security patches: It’s a biiiiiiiiig month

        Group G{ot backup} TestBeta
        Win7Pro · x64 · SP1 · i3-3220 · RAM 8GB · Firefox: uBlock Origin - NoScript · HDD · Canon Printer · Microsoft Security Essentials · Windows: Backup - System Image - Rescue Disk - Firewall
    • #1911210 Reply

      anonymous

      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 Reply

        PKCano
        Da Boss

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

        • #1911216 Reply

          anonymous

          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 Reply

            PKCano
            Da Boss

            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 Reply

        GoneToPlaid
        AskWoody Plus

        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 Reply

          Crowz
          AskWoody Lounger

          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 Reply

      NightOwl
      AskWoody Plus

      @ 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.

      NightOwl

      No question is stupid ... but, possibly the answers are 😉 !

      Attachments:
    • #1911389 Reply

      anonymous

      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 Reply

      anonymous

      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 Reply

      samak
      AskWoody Plus

      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…”

      W7 SP1 Home Premium 64-bit, Office 2010, Group B, non-techie

      • #1912793 Reply

        abbodi86
        AskWoody_MVP

        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 Reply

      Bob99
      AskWoody Plus

      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.

    Please follow the -Lounge Rules- no personal attacks, no swearing, and politics/religion are relegated to the Rants forum.

    Reply To: Caution: Windows 7 August Monthly Patch might cause BSOD

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