Did you HIDE KB3133977 at some point?
If it’s not already installed on your computer you may have the same problem.

Lol whut? Is this for real? Even if you don’t use bitlocker and have never had it on your system you still need this patch?

shakes head in disbelief

You couldn’t make this stuff up.

I successfully installed kb3133977 in May 2016. Do I have to run bcdboot.exe, which I have in two locations, system32 and winsx64\amd64, on my hard drive and do I have to run it in both locations?  Thanks.

I think it is actually worth backing up the BCD anyways. Use EasyBCD 2.3 on W7, as it is just a matter of clicking on ‘backup’ for it to make a copy. If you need the BCD at a later date, just open the GUI again and select ‘restore’.

It is freeware. I got it from NeoSmart Technologies (neosmart.net/easybcd)

Long story short, if you’re trying to install Win7 (either on bare metal, or a VM) and you:

• Are using setup to install a customized image (e.g., created by DISM)
• Are burning an image directly to the new machine, or
• Installing an image with SHA-2 support, but it won’t start with error 0xc0000428

My gobbledygook is rusty.  I have Win7 Home Premium, with updates frozen as of Dec 2017.  The last time I used a system image after a preventive hard drive replacement (4-5 yrs ago) it was successful, no hiccups or glitches.

If I understand what is being said in this article, because I have a “closed system”, and my system image backups are created by and within that closed system, I conclude this hullabaloo does not affect me.

Please advise if I am mistaken.  Thank you.

I had two different systems, one server and one laptop, fail to boot yesterday after installing this month’s cumulative update.  I traced the issue directly to not having KB3133977 installed before installing the August update.  Both systems were x64 UEFI.  The installs were several years old, not fresh installs or reinstalls.

The server… I restored to before the update.  The laptop took installing KB3133977 using the recovery console and DISM, rebooting back to the recovery console and running BCDBoot.exe.  Laptop came right back up after that.

This patch must also be installed on machines that boot from UEFI instead of BIOS and run Windows 7 64 bit (x64 and IA64) in order to successfully install this month’s security only patch (KB4512486) as well as this month’s rollup patch (KB4512506). See the entire thread “Caution: Windows 7 August Monthly Patch might cause BSOD” here on AskWoody, and my post at the end, post number 1911473 posted right here: https://www.askwoody.com/forums/topic/caution-windows-7-august-monthly-patch-might-cause-bsod/#post-1911473

This is a known issue that appears in the KB articles for BOTH of this month’s Win7 security parches, about machines not rebooting after installing the patch and giving a black screen of death.
Here’s a direct quote from KB4512506:

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:

“File: \Windows\system32\winload.efi

Status: 0xc0000428
Info: Windows cannot verify the digital signature for this file.”

I added the bolding in the quote above.

So, even for folks who haven’t installed from scratch in the last 30 days or so, the bit locker patch still plays a role in the successful installation of the two Windows 7 patches this month for some folks! Basically, if your computer boots from UEFI, you’d better get the bit locker patch (KB3133977) installed BEFORE installing any security patches for August, as illustrated by Anonymous just above this post, number 1912364.

My thanks to @abbodi86 for clarifying if I should install this patch even though I hid it on one of my machines.

Even though the motherboards in my systems are all UEFI, I still boot Windows 7 using BIOS (my boot SSDs are formatted using MBR instead of GPT).

So should I not be affected by this potential issue? I would think so, but I welcome confirmation.

To clarify for the beginners:

EFI boot means the BIOS searches the hidden EFI FAT partition to run the file “bootmgr*.efi” instead of running the code in the boot sector of the Windows partition (which in turn loads a boot loader from the disk containing that boot sector). This may or may not be unrelated to the use of MBR-style partition tables.

“Image” refers to a file tree inside a Microsoft .wim file (which may contain more than one “image”), as used almost exclusively by the Windows 6/7/8/8.1/10 installer (including what counts as “Windows PE” these days). This has very little to do with an actual disk image except in the naming of related commands.

Historically, there were all sorts of fatal bugs in the patches that upgraded Windows 6/7 Kernel Mode File signature checking from SHA-1 to SHA-2, so much that this was often a skipped update, abandoned by both Microsoft and users way back when Windows 7 was in mainstream support. Now, a few months before end of extended support, they push out a new version of these patches, and it crashes again.

Therefore, most production Windows 7 drivers (.SYS files etc.) from vendors are signed with SHA-1 signatures chaining via old commercial CA roots to ancient Microsoft cross-certificates. So it is unclear if this brings in the lock-down to require drivers to be submitted to Microsoft Windows 10 signing services (that have stopped or will soon stop accepting Windows 7 drivers) in order to load those drivers on Windows 7, thus effectively stopping hardware vendors from updating, bug-fixing or adding Windows 7 drivers. Official Microsoft rules on this were also a muddled mess.

I am getting confused. KB3133977 is not installed on most (at least 3) of my Windows 7 machines, nor have I hidden it or is it offered through Windows Update (not even as an optional update). I have 1 machine on which it is installed, apparently via Windows Update, because that is the way I update my machines. If this update is so important, how come I do not see and have never seen it? Does it mean I have to manually download it from the catalogue and install it? One of the machines on which I do not have any trace of KB3133977 is an Windows 7 x64 UEFI machine. The others all boot from MBR.

A question for the experts. Now that I have KB3133977 installed on my Win7 computers, do I simply run bcdboot.exe with no parameters from an elevated command prompt?

GoneToPlaid wrote:

A question. Were you actually using Bitlocker on these two computers? I ask since I am not using Bitlocker on my Win7 computers, and I had no issues after installing the August SO without KB3133977 being installed on any of my Win7 computers.

Hi,

Newly registered, I’m the anonymous poster above (and in the Win7 patch August BSOD thread).

No bitlocker installed.  The two affected systems were Server 2008 R2 (x64/UEFI) and Windows 7 (x64/UEFI).  Both did not have KB3133977 installed and both failed to boot after installing the August cumulative update.  The server showed the same error as the laptop.  As I said, it was faster to just restore the server with the backup from 8 hours prior.  I installed KB3133977 after it restored but have not tried to put the August update in as of yet.

Once I started working on the laptop, I found the x64/UEFI warning at the bottom of the KB4512506 page.  I was having difficulty getting KB3133977 to the laptop to use with DISM so I tried running bcdboot.exe without installing KB3133977.  On the reboot it gave me the 0xc0000428 error.  I ended up pulling the laptop drive, putting it in dock on a working system, copied KB3133977 to the drive and then followed the directions using DISM and bcdboot.exe.  The laptop came right back up after that.

Systems that were not UEFI and did not have KB3133977 installed had no trouble with the August update.

Reading everything here, just consider how much time and effort is wasted sorting out this issue with KB3133977. Also the time and effort those of those that ran into the issues because they had not installed KB3133977, including the people that do not visit AskWoody. And all of that just because MS in all of its wisdom changes to SHA2 only signing for Windows 7, just 5, I repeat: just 5 months before Windows 7 is EOL. Sigh…. Any wise (wo)man would not have bothered and thought that it just is not worthwhile for just 5 months.

I am really grateful for all of you that participate, share and respond. But would you rather not have spent that time on something more constructive? I know I would (having lost too much time this morning just trying to figure out what was going on…).

Zathras wrote:

Systems that were not UEFI and did not have KB3133977 installed had no trouble with the August update.

So confused. like others here I have multiple Windows 7 Home Premium SP1 PCs that DO NOT have KB3133977 installed NOR hidden and all three are legacy BIOS not UEFI.

Zathras’s experience quoted above leads me to think those of us in my situation should be able to install the August update(s) without problems.

Can anyone else confirm?

Can we ignore KB3133977?

Thanks!

–> Never mind. I think PKCano’s post #1912345  answers my question. <–

Another thing –

Maybe a silly question, but does this (from Woody’s Computer World article where he lays out three situation where this KB3133977 update comes into play):

• “You’re burning an image of Win7 directly to disk without running setup.”

include restoring a Windows image backup over an existing Windows installation?

Thanks!

What a mess, Win7 Pro here and i have not installed KB3133977, nor is it hidden.
According to multiple sources KB3133977 is included in KB3125574 ‘Convenience rollup update’.

Can anyone confirm for sure that you do not need to install KB3133977 if KB3125574 is installed ?

My system’s patches are up to date.  If I create an image of my Win7 computer today, and “restore” it to a brand-new hard drive tomorrow, do I need the bitlocker patch?  It’s hard to see why I would, but I’d like to have this clarified.  Thanks.

I have a few Win 7 systems, some X64 Ultimate and one x64 Home Premium.

All of them already have KB4490628 (Servicing Stack update) and KB3125574 (a roll-up that includes KB3133977).

I downloaded the latest standalone KB4474419 (SHA2 v2) update from the MS update catalog.

The 1st system to be updated is the Home Premium system.

Launched the update & it seemed to install OK initially.  But after I clicked on the post-install restart it has been stuck on the “Preparing to configure Windows” screen for almost an hour so far.  The system is a laptop with a modest CPU but fast SSD.  There’s consistent modest disk activity… but it’s taking forever.  The last time I experienced this was with the last servicing stack update.  I have my fingers crossed the update will complete…

anonymous wrote:

? says:

hi ek,

did you get any error codes? or did it get stuck before generating any? is it the march version or did you get that one to install and now you’re sticking on the august v2 version? or in my case too much more brain damage

No error codes.  Just the “Preparing to configure Windows” screen and some meager repetitive disk activity.  I gave it 2 hours and no change.  So I did a hard powerdown & then booted into safe mode, which announced the update failed and recovered to the previous state/version.

That was with 8/12/2019 version of KB4474419.

The update failed on my old Acer X64 Win 7 Home Premium laptop, which has the weird non-configurable UEFI/BIOS boot mode.  That is, it will boot UEFI if – when during OS install – I choose UEFI.  If I config a disk for good ‘ol BIOS MBR boot, the BIOS will boot that too.  And the BIOS will allow boot into UEFI mediated recovery.  But the BIOS itself has no options to control this.

My other Win 7 systems are plain ‘ol BIOS MBR boot.  No UEFI in the BIOS at all (AMD 970 boards).  I think it’s likely KB4474419 will install OK on these systems… but I’m not going to bother finding out.

On all my systems, I run Linux 99% of the time (some 100% now).  That’s been my practice for years now.  At this point I’d lose very little if I went full 100% Linux.  Man, MS missed the boat with me.

anonymous wrote:

? says:

i looked around a bit and found this one;

https://www.sevenforums.com/windows-updates-activation/418834-unable-install-kb4474419-win7-x64-ultimate.html

and:

https://www.bleepingcomputer.com/forums/t/696802/cant-install-kb4474419-it-fails-and-reverts/

don’t know if they would help? so did the March version install w\o trouble? anyway i hope you get past this glitch and then on to whatever else they throw our way…

Aha!  Thanks for the pointers.

First, I did review the update log and saw error #80070643 for my earlier attempts to install KB4474419.  I researched this and found no consistent answer on that code.  But it did seem sometimes to correlate to file permissions issues.

And, yes, the earlier March version of KB4474419 installed fine, per review of my update history.

Anyway… fix discovered:

Well, per one of the links you provided, the “fix” was to login to the Administrator account and install the standalone 8/12/2019 version of KB4474419.  Perhaps I could have just done a right-click “run as Adminstrator” on the standalone update via my normal account (which has admin privs), but I chose to just login as Administrator as others had done to get the update to install clean.

The bottom line: KB4474419 installed successfully (and relatively quickly) when running the standalone update when logged in as the Administrator user.

I did the same thing on my other Win 7 systems. No issues.  I suspect I could have done a normal install of the update on those systems as they are Win 7 Ultimate.

I have to say: it’s been a loooong time since I had to resort to installing an update this way.  I’m kicking myself for not remembering & giving it a shot initially.

Note:
On one system I had to actually make the Administrator user visible in the login screen.  To do that, I right-click selected “Run as Administrator” for CMD.EXE.  Then in the resulting CMD window, I entered:

net user administrator /active:yes

Then I logged out from my account & immediately logged in as the Administrator user.  Note that no password was set for the Administrator user yet, so I could initially login as Administrator without a password (!!!!).  Thus, immediately after login I set a password for the Administrator user. 

So if you choose to make Administrator visible on the login screen:  PLEASE make sure the Administrator user has a reasonably secure password set.