nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

Warning - Windows 10 Update KB5007186

devnull

Don't install this update if you can possibly avoid it.

I've seen three previously stable machines of different configurations all fail to boot following it. Even start-up repair doesn't work neither does uninstall recent system updates, as it says there is a pending update action.

Only way I could restore my machine and other machines was by doing a system restore to before the update was turned on. No matter what else I did I couldn't manage to fix the issue.

There appear to be a lot of issues with various things since this update which was rolled out starting last week.

Find more posts tagged with

Quick Links

Comments

AllForIt

Is it this one?

Feature update to Windows 10, version 21H1

That's all I see in the Update Settings. I don't see a K code.

Anyway, I'll do a system backup first.

devnull

https://www.boards.ie/discussion/comment/118191883#Comment_118191883

No, it wasn't a feature update, just a patch which caused my issues.

AllForIt

https://www.boards.ie/discussion/comment/118191894#Comment_118191894

Oh yeah, I see in my update history I already have the KB5007186 patch.

Dinarius

Not sure if it's connected to my blue screen problems today, but that update was installed on 12/11/2021. It's listed in Update History.

[Deleted User]

I've had that installed since the 15th with no issues, it's also been rolled out within the organisation for about a week or so with no issues either. You've a different problem I'd say.

devnull

So today was the day when I couldn't postpone the update anymore as the 'pause limit has been reached'

So I just installed this update, and yep, again I have exactly the same problem as when I installed it in November where it stops Windows 10 from booting correctly with all repair options not doing a thing.

As per last time, a system restore to before the update fixes the problem and allows me to boot normally into Windows with no problem whatsoever. Clearly something about this update doesn't play right with my system.

Now we've good the ridiculous situation where I can't stop an update that bricks the machine, from installing, so keep having to do a system restore every time it installs it.

Does anyone know how I can stop Windows update from trying to install the update, even when the front-end won't allow me to?

Irish Steve

In theory, which is always an unknown where Microsoft are concerned, they should offer free support to determine what's going on, and try to find a resolution, but that may not provide the solution you're looking for, as one of their options may be a clean install of Windows, which may then mean a reinstall of all the other software packages that are running on the machine. A good while back I had a similar scenario, which Microsoft were able to resolve, but it took a while with them operating on line on the machine, and it turned out to be an obscure registry setting that was not as expected, once that was corrected, normal service was restored. They never did let on what was wrong, or why, it was just a case of "it's fixed, sorry for the inconvenience" and every body moved on.

Two other thoughts. Is the BIOS up to date, with no updates pending, and have you run something like Driver Easy to make sure that all the hardware drivers are up to date, Windows update is not exactly stellar in terms of manufacturer driver updates, and an out of date device driver can cause all sorts of strange issues, and it's been made worse recently by AMD killing support for a wide range of their graphics chip sets, a few days before Win 11 was released, clearly they are determined to kill off a range of processors even sooner than 2025, when Win 10 will be going off support.

Other than that, I don't have any other suggestions, the fact that it doesn't boot would make me suspicious of BIOS issues, or a core item like the disk drive drivers, or as a complete outlier, the drive boot information has an out of date piece of information that the new update hasn't been set up to recognise.

Microsoft may have a way to suspend the update for a longer period, but I'm not sure about the "how" they can do that. In theory, they can flag certain hardware devices to prevent Windows Update from offering specific updates, that happend a while back with a specific AMD configuration, and it took about 4 months before we got one update, but again, that's under their control.

Not sure what else to suggest

Good luck

[Deleted User]

1300 installations approx. in the organisation, no issues. The only results I can see regarding computers failing to boot after installing this SSU on a Google search are this thread.

magicbastarder

So today was the day when I couldn't postpone the update anymore as the 'pause limit has been reached'

was it this or the december CU you were offered? the update in the thread title has been superseded.

we installed this on 100k systems where i work, whatever your issue is i suspect it's local rather than an issue with the CU itself.

devnull

https://www.boards.ie/discussion/comment/118380481#Comment_118380481

I was offered the December CU a few days ago, which causes the same issue.

Managed to hack Windows Update in the registry to stop it from trying to update for the moment so it doesn't try and install it on restart, but obviously it's not a permanent fix.

I've been unable to identify what the issue is causing it and all my drivers are up to date and all the SSDs have the latest firmware and have had health checks and the motherboard has the latest BIOS etc so it is very strange.

System is exceptionally stable since built, had one blue screen in the lifetime of it and that was caused by a bad driver update about 7 months ago that was quickly corrected by the vendor.

My system config: Gigabyte B450 Gaming X, Ryzen 5 3600 (cooled by Be Quiet Pure Rock Slim 2) 16GB DDR4 RAM, 1x Samsung 970 EVO 2TB NVME, 2x Samsung 860 EVO 1TB SATA, MSI Geforce RTX2060 OC Edition, Cooler Master MWE Gold 650W.

I built a similar system for a friend, like this, without the issue: Gigabyte B450M Gaming, Ryzen 5 3600X (cooled by Be Quiet Pure Rock), 16GB DDR4 RAM, 1x Samsung 970 EVO 1TB NVME, 1x Samsung 860 EVO 1TB SATA, Palit Geforce RTX2060, Cooler Master MWE Gold 600W.

The following I built for a relative also has the problem I have: Gigabyte B450M Gaming, Ryzen 5 3500 (stock cooler), 16GB DDR4 RAM, 1x Crucial 512GB NVME SSD, 1x Samsung 860 EVO 1 TB SATA SSD, 1x Samsung 870 SATA SSD, Gigabyte Geforce RTX2060 (single fan), Cooler Master MWE Gold 600W.

I've done every diagnostic test under the sun with my machine and the relatives machine and cannot seem to figure out what is causing it. The system I built for a friend I configured in exactly the same way and has not suffered any problems.

All three machines are stable in daily use and show no problems at all. The relatives machine runs a little hotter than the other two thanks to a poor cooling solution on the graphics card, but alas with the graphics card market being as it is, beggars cannot be choosers.

Irish Steve

I will throw one thought into the pot, the laptop here is nothing like that spec, but it's an AMD processor and is now running 10 Home 21H2, which got installed in September, I'm wondering why a more recent CPU has not been offered the most recent update, as it seems that the upgrade item that's giving you grief is 21H1.

I'm also aware that when the most recent upgrade was rolled out, there was a period of time when Windows update got well confused between the H1 and H2 updates, and tried installing H1 updates on a machine with H2 installed, albeit that the install didn't take long, as I am guessing that it found the confusion when checking file dates and the like. It went on like that for several days on several system before resolving the conflicts.

magicbastarder

have you tried running sfc /scannow and associated checks?

devnull

Yes, I've tried that on both machines and it makes no difference and finds no issues.

devnull

https://www.boards.ie/discussion/comment/118380862#Comment_118380862

Well, I did a reinstall from scratch on both machines last week, and guess what?

Yep, same problem still exists. All that effort and still no improvement!

Now the issue I see with installing the update is a little different though, instead of starting to install the update, getting to about 30% and then telling me it's restarting, it doesn't even tell me it's restarting, the machine just hard restarts without warning after 30% of the update.

Other than that, everything remains the same, even on a fresh install of windows, using all of the drivers from the relevant vendors rather than using the built in windows ones.

I have also swapped the boot drive out on both machines to be fairly cheap Crucial SSDs on a second attempt of a fresh install and it still happens, so it's clearly not a SSD issue.

Anybody have any new ideas?

smuggler.ie

https://www.boards.ie/discussion/comment/118554263#Comment_118554263

Weird, does not seem to be widely reported. But let me ask if you use customized or original, latest ISO from MS ?

devnull

https://www.boards.ie/discussion/comment/118554784#Comment_118554784

I have tried various different media types and the same happens.

devnull

The strange thing is that something Windows update does is very odd when installing that update.

Before installing the ill-fated update the last time around after the fresh install that never had any attempts of that update to be installed previously (to rule out anything the update itself does the first time it fails) I did a meticulous audit of various things in the BIOS and also the Windows 10 boot/recovery mode that you can access to see what changed, and I came across a couple of interesting things.

Firstly, boot devices in the BIOS

Before trying to install the update, it lists 2 drives in the BIOS as well as an entry for Windows Boot Manager and the primary drive name, like I would expect
After installing the update, it lists the 2 drives in the BIOS, as well as an entry for Windows Boot Manager and the primary drive name, like I would expect and ANOTHER entry for Windows Boot manager on the secondary drive, that seems to have been created by the Windows update process.

I had an a-ha moment here and the deliberately went and changed the BIOS to remove every hint of the secondary drive from the boot order/sequence and gave it options of Windows Boot Manager and the actual boot drive for every priority.

Sadly, this did not make any difference!

Secondly, the update seems to make the recovery mode / automatic repair functionality get confused

Before running the update, If I go to command prompt in the recovery mode, and navigate to C:\ and do a dir/p, it clearly shows my C drive, as it appears in WIndows, as being allocated the drive letter C, and the secondary drive allocated to D
After running the update, If I go to command prompt in the recovery mode, and navigate to C:\, for some reason it recognised what was previously as drive C as drive D, and what was previously as drive D:\ as drive C:\

However, what is more strange, is that if I do a system restore, it recognises the CORRECT drive as Drive C:\ which allows me to recover the machine from before the update, despite the fact that every single other part of recovery mode gets the drives mixed up.

So what seems to be happening is

When the update runs, for whatever reason Windows Boot Manager somehow gets onto the secondary drive.
This clearly causes some confusion, which prevents Windows from booting correctly, even when I force the machine to boot from the primary drive.
The recovery mode then for some reason swaps the drive letters, so it thinks that what is drive C:\, is actually drive D:\ and what is drive D:\ is actually Drive C:\
This seems fatal, but for some reason, system restore in recovery mode, is able to distinguish the drives the right way around post update, despite the fact , that neither the boot process nor the rest of recovery mode can.

Thanks heavens that system restore is able to prevent being confused, because otherwise it would be far worse and the whole install could be trashed, but it's still pretty odd that system restore doesn't get confused post update but everything else does.

I'm still none the wiser of how to actually fix this, but the above seems to shed light on actually what is happening. It's for sure related to certain updates though, as on a fresh install I had huge amounts of updates install without issue.

It's for sure related to having more than one drive installed as well, because if I do a fresh install on the same machine with only a single drive, the problem doesn't occur.

smuggler.ie

Had your secondary drive at some point in time served as main drive (C:\)? Perhaps still sitting on same SATA port? Seams like it and if so...

I have seen where fresh Windows install on the new drive reuse partitions from secondary drive(instead creating its own) IF it had/have windows on it(common in disk upgrade scenarios).

You will be able to see partitions on both disks in DISKPART and clean where required(caution! deleting wrong partition(s) will cause more headache).

If avail, to avoid messing with partitions, move secondary out to enclosure, copy data out, diskpart -> clean, use for data(or whatever) thereafter.

See if it helps

devnull

https://www.boards.ie/discussion/comment/118555715#Comment_118555715

When I did a reinstall, both drives were fully formatted. In fact, I even used a brand new drive

I looked at them in Diskpart and saw this

Disk 0 (secondary drive) - SATA

Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Reserved             15 MB   17 KB
  Partition 2    Primary             193 GB   16 MB

Disk 1 (Primary drive) - NVME

Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    System             100 MB  1024 KB
  Partition 2    Reserved            16 MB   101 MB
  Partition 3    Primary            465 GB   117 MB
  Partition 4    Recovery           507 MB   465 GB

Disk 1 (C:\) is a brand new Crucial P2 drive (crap drive, but just for testing), and Disk 0 is currently a 1TB SSD that has never ever served as a boot drive previously. The only time it's ever had anything boot related on it is when Windows update for some reason seemed to copy Windows Boot Manager onto it as referenced above.

Tonight for what it's worth I've reformatted the crucial drive again, reinstalled Windows, and paired it with a different secondary drive, this time a brand new256GB Samsung 860 Evo that I've never used as it was too small. I've used a different copy of Windows 10 to install it and I've seen barely any difference.

Once again I was able to install a load of updates with a load of restarts without any problem whatsoever, then it got to KB5009596 which appears to be an update that superseded the December version that gave me the problem which also superseded the November one that also gave me the problem.

And of course, with this reinstall tonight, again I had the same thing with Windows Recovery mode getting confused between drives after installing that update (but saw them the right way around first time) and also my BIOS picked up Windows Boot Manager on both drives after the update, but before the update it only seems it on the correct drive.

For some odd reason there is something to do with that update that seems to really make Windows get confused with what drive is what, hence recovery mixing them up and the sudden appearance of Windows Boot Manager on the secondary drive.

smuggler.ie

format (in windows, during install or even in diskpart) is not the same as diskpart ->clean (or clean all).

Always do diskpart ->clean if you want "blank disk".

During install, at any point before you hit INSTALL , Shift+F10 brings up CMD.

clean [all]

Removes any and all partition or volume formatting from the disk with focus. On master boot record (MBR) disks, only the MBR partitioning information and hidden sector information are overwritten. On GUID partition table (GPT) disks, the GPT partitioning information, including the Protective MBR, is overwritten; there is no hidden sector information.

all

Specifies that each and every sector on the disk is zeroed, which completely deletes all data contained on the disk.

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc766465(v=ws.10)?redirectedfrom=MSDN

devnull

https://www.boards.ie/discussion/comment/118556211#Comment_118556211

Yes - I'm aware of that, but I've also done in the diskpart way as well as through disk management and the same behaviour has happened and as I said, the secondary drive that I tried using today was a brand new SSD, yet Windows Update still managed to find a way to install Windows Boot Manager on it during the update process.

Anyway, I decided to disconnect the second drive and tried installing the update again on the primary drive and everything worked and I updated to 21H2 version of Windows 10 and then plugged in the second hard drive again and everything seemed to work fine. At bloody last is what I thought,.

I shouldn't have been so naïve.

I then got handed some more updates by Windows Update, after reconnecting the second drive, which had been diskpart cleaned, the machine installed them and restarted and I got a familar problem.

I then got sent some more updates from Windows Update, and guess what? Yep, the very first update that I installed caused a very similar problem to what I have with installing an update for 21H1

21H2 behaviour

Install Updates -> Restart -> Preparing Automatic Repair -> Diagnosing your PC -> Attempting Repairs -> We couldn't install the updates -> We removed some recently installed updates to recover your device from a startup failure -> Blacklists update for 30 days.

On the positive side, it seems that 21H2 is a bit less thick than 21H1 in that when the update stops the machine from booting, the recovery system is able to get the drives the right way around and diagnose the problem at hand and repair it automatically (unlike 21H1 which had no clue of what to do) by rolling back without any user interaction required.

Whilst it seems that MS have improved the recovery system so it is now able to diagnose and fix these things automatically by identifying the update that caused the issue itself and rolling it back without any user interaction, it seems that the root cause still hasn't been resolved.

smuggler.ie

I guess i should sense that you familiar with clean.

Are Win partitions recreated on secondary drive after clean?

Odd that Win treat your secondary as master.

BIOS latest ?

Manual install of KB in question instead updates?

Change SATA port for secondary?

devnull

https://www.boards.ie/discussion/comment/118556637#Comment_118556637

1) Windows always refers to my SATA SSD (secondary) as Disk 0 and refers to primary as Disk 1.

2) I recreated the partitions on the second drive, the only partitions showing up after Windows Reinstall are a system partition and the date on the secondary drive.

3) BIOS is latest, checked both the Gigabyte update software and also manually on their website

4) Tried manually installing the update from https://www.catalog.update.microsoft.com/ and same results.

5) Haven't tried that but will be next thing I try when I have time to troubleshoot further.

Windows getting confused doesn't seem so bad in 21H2 because it's able to fix itself, unlike 21H1, and even if I deliberately invoke the recovery menu after I install the update, 21H2 does manage to get C:\ and D:\ the right way around (unlike 21H1) which is probably why recovery works in 21H2 and not in 21H1).

In summary, what we have here is as follows:

In 21H1 the confusion between drives is so bad that it for some reason installs Windows Boot Manager on the secondary drive, none of the recovery options work because they get the driver letters the wrong way around. However for some reason system restore IS able to get them right way around.
In 21H2, the confusion still installs Windows Boot Manager to the secondary drive, but the recovery options work perfectly, because the recovery system gets the driver letter the right way around (which

Now the change in the above behaviour between two Windows versions looks suspiciously like there was some flawed logic or bug in the 21H1 recovery process that MS fixed in the later version which means recovery now works. However the install of Windows Boot Manager on the secondary drive, seems to suggest whilst the recovery system no longer gets the drives mixed up when recovering, something in the update process still seems to be getting confused.

Honestly the secondary drive being assigned as Disk 0 could well be related here I would imagine.

[Deleted User]

Swap around the two drives SATA ports.

devnull

https://www.boards.ie/discussion/comment/118556907#Comment_118556907

One is NVME (Primary, C:\, which always is assigned disk 1) and the other is SATA (Secondary, D:\ which is always assigned disk 0)

I'm going to try the SATA drive in a different port next weekend most likely, spent too much time on it today so going to leave it be until next weekend now I know that update is disabled for 30 days.

Capt'n Midnight

Disconnect second drive temporarily while installing OS, patch ?

devnull

https://www.boards.ie/discussion/comment/118558858#Comment_118558858

See above - I did that for the problematic update in question, but then the next time it tried to install an update after that one, I also got a very similar problem, the only difference being in 21H2, the recovery program is more smart and can roll itself back automatically.

smuggler.ie

It seam like SATA in your case is prioritized over your PCIe, or PCIe is "late to the show"

Fast boot enabled in BIOS ? Disable, let POST to confirm "all good and ready" before Win boot.

Good old CMOS reset ?

One change at the time if you looking to get to the bottom .

Capt'n Midnight

https://www.boards.ie/discussion/comment/118560441#Comment_118560441

Stupid stuff :

For the duration , disable anything you can with autoruns or similar / set default browser to edge

In the old day's I would have suggested disabling cache in BIOS and / resetting to system defaults to use safer timings until installed.

Move HDD to a machine that's has updated before. Then patch and move back.

If you wanted to waste time troubleshooting create a virtual machine and upgrade it, CPU should be mostly transparent but other HW like video won't.

magicbastarder

anything obvious in cbs.log?