[English]Heute mal ein Beitrag zu einem allgemeinen Thema. Es geht um die Frage, was eine Race Condition ist. Dieser Begriff wird dem einen oder anderen Blog-Leser beim Lesen von Update-Problemen vielleicht untergekommen bzw. aufgefallen sein.
Beispielsweise wird im Blog-Beitrag Windows Server 2012 R2 und 2016: Hohe CPU-Last mit Update KB4345418 / KB4054566 dieser Terminus benutzt:
Addresses an issue that may cause some devices running network monitoring workloads to receive the 0xD1 Stop error because of a race condition after installing the July update.
Auch im Blog-Beitrag Windows 10 V1607-V1709: Updates vom 21. Juni 2018 kommt der Begriff in Verbindung mit einem Problem vor:
Addresses an issue where Windows Defender Security Center and the Firewall Pillar app stop working when opened. This is caused by a race condition that occurs if third-party antivirus software has been installed.
Im Artikel Windows 7: Update KB4088881 (Preview Rollup, 23.3.2018) betrifft es die Universal C Runtime (CRT) beim Updaten diverser Komponenten.
Addresses issue with a race condition in the Universal C Runtime (CRT) that occurs when you update the global locale. The issue corrupts the current locale reference count and triggers a double free condition.
Scheint also nicht so selten zu sein und kann faktisch in allen Windows-Versionen, aber auch unter macOS oder Linux auftreten.
Race Condition, dass steckt dahinter
Von der Übersetzung her handelt es sich um eine Bedingung beim Rennen. Die Wikipedia weiß dazu mehr:
Ein kritischer Wettlauf, auch Wettlaufsituation (englisch race condition oder race hazard) ist in der Programmierung eine Konstellation, in der das Ergebnis einer Operation vom zeitlichen Verhalten bestimmter Einzeloperationen abhängt. Der Begriff stammt von der Vorstellung, dass zwei Signale wettlaufen, um die Ausgabe als erstes zu beeinflussen. Im Allgemeinen ist die Möglichkeit zu vermeiden, dass eine Race Condition entsteht.
Unbeabsichtigte Wettlaufsituationen sind ein häufiger Grund für schwer auffindbare Programmfehler; bezeichnend für solche Situationen ist nämlich, dass bereits die veränderten Bedingungen zum Programmtest, wie zusätzliches Logging oder Debug-Modus, zu einem völligen Verschwinden der Symptome führen können. Zur Vermeidung solcher Konstellationen können bei der Programmerstellung beispielsweise Semaphore eingesetzt werden.
Es handelt sich um eine beim Programmablauf auftretende, kritische Wettlaufsituation um den Zugriff auf eine Ressource oder Operation, die von zwei Threads unternommen wird. Eine der beiden Threads gewinnt und bekommt den Zugriff. Der unterlegene Thread führt den Zugriff später aus, was aber unerwünschte Folgen haben kann. Im Wikipedia-Artikel ist ein Beispiel für den Zugriff auf eine Speichervariable mit einem Zähler genannt.
Microsoft hat den KB-Artikel 317723 Description of race conditions and deadlocks zum Thema, aber mit dem Fokus Visual Basic 2003 und VB .NET 2003, veröffentlicht. Dort geht es um den Zugriff auf eine Shared-Variable durch zwei konkurrierende Threads. Die Race Condition führt dazu, dass unvorhersagbare Ergebnisse auftreten.
Ein Beispiel von März 2018
Susan Bradley hat das Ganze im März 2018, damals aus aktuellem Anlass (KB4075150 endet mit nicht bootenden Maschinen, auf Grund einer Race Condition), bei askwoody.com angesprochen. Die Erklärung Microsofts zum Problem
This issue occurs in the unlikely event, due to a race condition, that the Windows Update servicing stack incorrectly skips installing the newer version of some critical drivers in the cumulative update and uninstalls the currently active drivers during maintenance.
Dort wurde ein Treiber erfolgreich deinstalliert (die Transaktion war also erfolgreich). Aber der neue Treiber wurde auf Grund einer Race Condition (da bleibt MS nebulös, muss man wohl als einen Bug bezeichnen) nicht installiert. Da es sich bei acip.sys um einen kritischen Treiber, der beim Booten benötigt wird, handelte, konnten die Maschinen nicht starten. Susan Bradley geht im oben verlinkten Beitrag bei askwoody.com auf die Details ein und berichtet, dass bei dism-Deinstallations-Versuchen genau nur ein ‘Schuss’ frei war, um das Treiber-Rollback anzustoßen.
Ergänzung: Im englischsprachigen Blog-Beitrag ist dieser Kommentar mit interessanten Ergänzungen und Beobachtungen von Crysta T Lacey eingetroffen. Der Kommentar legt auch offen, warum es inzwischen so wichtig ist, Servicing Stack Updates (SSUs) vor den eigentlichen Updates zu installieren.
Ähnliche Artikel:
Windows 10: Sleep Study, Infos und Probleme
Dynamische Updates für Windows, das steckt dahinter
Windows 10: Programmausführung als System/TrustedInstaller
Windows 10: Schnellstart abschalten
„Servicing Stack Updates (SSUs) vor den eigentlichen Updates zu installieren“
Wie macht man das auf seinem privaten Rechner?
Wo findet man nähere Informationen dazu, was was ist?
Auf dem privaten Windows 10-PC wird das SSU vor den CUs installiert – da sorgt Windows Update für. Bei Win 7/Win 8.1 muss man bei den Security Only Updates aus dem Microsoft Update Catalog selbst dafür sorgen, dass die Installationsreihenfolge eingehalten wird. In der Regel weise ich auf diesen Sachverhalt in meinen Blog-Beiträgen hin. Zudem dokumentiert MS das (nach meiner Beobachtung) inzwischen zuverlässig ins einen KB-Artikeln zu Updates. Oder habe ich da was falsch interpretiert?
Danke!
Bislang habe ich nur die Security only-Updates installiert und den Sachverhalt nicht beachtet, weil mir dazu keine Informationen vorlagen.