Bluescreen in Hyper-V 2.0: Hotfix einspielen

Auf ein Problem mit Hyper-V 2.0 auf bestimmten Intel-CPUs macht Daniel Melanchthon jetzt in seinem Blog aufmerksam. Es führt zu sporadischen Bluescreens der Host-Maschine, was natürlich sehr ärgerlich ist. Microsoft stellt einen Hotfix dafür bereit.

Das Problem ist schon länger bekannt, und den Fix gibt es auch schon geraume Zeit. Trotzdem wissen viele Anwender von Hyper-V nicht darüber Bescheid, daher ist es sinnvoll, noch einmal darauf hinzuweisen.

Es geht um den Stop-Fehler "0x00000101 – CLOCK_WATCHDOG_TIMEOUT". Diese hat seine Ursache in einer fehlerhaften CPU-Funktion der Intel-5500-CPUs und einiger anderer Modelle (z.B. Intel Core i7-800 und Intel Core i5-700). Diese Prozessoren können eigentlich in einen speziellen Stromsparmodus schalten (Sleepstate C1E), allerdings wachen sie dabei nicht rechtzeitig auf. Windows denkt daher, die betreffende CPU sei ausgefallen und hält das System an.

Hier der Artikel mit dem Hotfix:

[Stop error message on an Intel Xeon 5500 series processor-based computer that is running Windows Server 2008 R2 and that has the Hyper-V role installed: "0x00000101 – CLOCK_WATCHDOG_TIMEOUT"]
http://support.microsoft.com/kb/975530/en-us?fr=1

Ich selbst war in einem Kundenprojekt mit diesem Fehler konfrontiert, in dem wir gemeinsam mit dem Kunden eine der ersten großen Hyper-V-Umgebungen in Deutschland aufgebaut haben (mittlerweile ein Zehn-Knoten-Cluster). Der Kunde entschied sich bereits im Sommer 2009 direkt nach dem Release von Windows Server 2008 R2, die neue Technik einzusetzen, um von den Vorteilen von Hyper-V 2.0 zu profitieren.

Nach kurzer Zeit machte sich dann der CPU-Bug bemerkbar – allerdings zunächst nicht in nachvollziehbarer Weise. Da bei dem Kunden bereits ein Cluster mit mehreren Knoten lief, stellte er erst nach einer Weile fest, dass die virtuellen Maschinen sporadisch auf anderen Clusterknoten neu booteten. Hier tat der Cluster also das, was er sollte, und sorgte dafür, dass die Hardwareprobleme keine gravierenden Schäden nach sich zogen.

Das Problem war damals noch sehr wenig bekannt, im Internet fanden sich nur wenige Hinweise darauf. Auch eine intensive Crashdump-Analyse brachte uns nicht recht weiter. Kurze Zeit später hatte Microsoft dann seinen Patch veröffentlicht. Dieser tut eigentlich nichts weiter als die Stromsparfunktionen zu deaktivieren – als Workaround kann man dies teilweise auch einfach im BIOS der betroffenen Server einstellen.

Dieses Problem (und seine Lösung) habe ich übrigens auch in meinem Vortrag zu dem Hyper-V-Projekt auf der CeBIT 2010 im iX-Forum beschrieben.

Weiteres dazu:

[Hyper-V R2 Bugcheck 0x00000101 – .: Daniel Melanchthon :. – Site Home – TechNet Blogs]
http://blogs.technet.com/b/dmelanchthon/archive/2010/08/02/hyper-v-r2-bugcheck-0x00000101.aspx

[Hyper-V Hotfix for "0x00000101 – CLOCK_WATCHDOG_TIMEOUT" on Nehalem systems – Virtual PC Guy’s WebLog – Site Home – MSDN Blogs]
http://blogs.msdn.com/b/virtual_pc_guy/archive/2009/10/16/hyper-v-hotfix-for-0x00000101-clock-watchdog-timeout-on-nehalem-systems.aspx

Hier noch ein Auszug aus dem Crashdump, der das Problem durchaus richtig identifiziert:

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 000000000000000d, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: fffff880023e8180, The PRCB address of the hung processor.
Arg4: 0000000000000006, 0.