Patch Lady – what is a race condition?

Topic

New Reply

This topic came up the other day after the issue with the unbootable devices occurred in January.  Kristy recommended that I blog a bit more in detail
[See the full post at: Patch Lady – what is a race condition?]

Susan Bradley Patch Lady/Prudent patcher

8 users thanked author for this post.

Kirsty, Norio, MrBrian, rc primak, JohnW, woody, Great Lake Bunyip, Microfix

Reply | Quote

Replies

I know what a race condition is, but I don’t quite follow what specifically was racing, or why a race condition is even possible in this sort of situation. Are not the writes to disk sequential? Why would you ever set it up where an old version of a file can be deleted without being immediately replaced?

What’s more, why would you delete a file before copying the new version? The updater has  full control. Why not copy the new file, and then change the old file node to the new file, then delete the old file? Heck, don’t even delete the old file, but keep a backup with a particular name, and then have Windows capable of self-healing and restoring the backup for the rare case where something goes wrong.

Okay, maybe you get some fragmenting of the boot process doing it this way. But that’s (a) not a problem for SSDs (b) trivial to defragment later on HDDs, and (c) could be mitigated on all but the most full HDDs by just provisioning space for replaced boot files ahead of time.

It just sounds like Microsoft is making a simple process much more complicated than it needs to be. Replacing files is a solved problem in computing. Focus on quality control and how to do incremental updates properly. (Also generally a solved problem, but clearly one they don’t have worked out.)

Reply | Quote

Fact of the matter is that if Microsoft had just tested the process on a single machine, they would have known what will happen. However, they no longer conduct such tests and rely on telemetry and AI… Of course, even an idiot knows it doesn’t work, but not so the smart folks at Microsoft.

Reply | Quote

What you have described is basic operating system information regarding concurrent processes.

Concurrent processes are difficult to implement, but easy to test.

Failure suggests lack of software skills over the entire spectrum of coding, implementation, and testing.

 

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

Reply | Quote

Ah, but some concurrent processes are very, very complex. Race conditions abound – always attributable to bugs, but sometimes very subtle.

Reply | Quote

So, why is a Cumulative Update even messing with drivers at all?

Yet another reason I have Windows 10 set up so that driver updates do not come down the Microsoft Updates chute. Ever. Wushowhide is further insurance against unwanted driver updates. But if the driver updates are part of the CU, let’s hope Microsoft still honors the No Driver Updates setting in Windows 10.

This is also further reinforcement in my mind that Version 1709 is still not ready for deployment to production PCs.

And of course I have backup software which I use regularly, usually before the anticipated monthly release of the new CU. My bootable media is the Macrium Reflect Win PE 10 Rescue Media on a USB stick. And I test that every time Macrium Reflect has any sort of a program update.  There is also an on-disk Boot Menu option, which I reset whenever the Macrium Reflect program is updated. And I test this option, too.

All of this effort, just to deal with Microsoft Updates! (sigh)

 

-- rc primak

1 user thanked author for this post.

woody

Reply | Quote

More technical details are at KB4058258 Inaccessible boot device on Intel CPU. Also see the motivating example at Understanding Windows bundled updates.

Reply | Quote