Für meine Tests mit diversen Betriebssystemen setze ich auch auf Virtualisierungslösungen wie Virtualbox oder VMware. Im Rahmen eines Buchprojekts zu Windows 8 Consumer Preview habe ich mir VMware Workstation 8.x zugelegt. Aber momentan nervt mich VMware Workstation 8.0.2 mit einem fiesen Bug. Irgendwann kommt beim Start der Fehlerdialog Access Violation und die VMs lassen sich nicht mehr starten.
Anzeige
Ende Dezember 2010 hatte ich mir die Vollversion für VMware Workstation 7.x zugelegt – im Abschnitt Einkaufserlebnis VMware-Shop habe ich über dieses Abenteuer berichtet – und mir geschworen "kein weiterer VMware-Produktkauf mehr". Und knapp 14 Tage später wurde ich bestätigt: durfte ich doch feststellen, das eine M2 von Windows 8 in der Version 7.x von VMware nicht lief. Ich habe dann Oracle Virtualbox für meine Tests genutzt – und die neu gekaufte VMware Lizenz verstaubte im Regal.
Irgendwann kam VMware Workstation 8.0 heraus. Ich habe mir die 30 Tage Eval installiert und konnte nach Ablauf des Testzeitpunkts mit dem kostenlosen VMware Player 4.0 weiter arbeiten. Ärgerlich: Es gab für Käufer der Version 7.x ein Gratis-Update. Aber für ein kostenloses Update hatte ich VMware Workstation 7 genau 14 Tage zu früh gekauft.
Da will man dem Hersteller was gutes tun …
Weil ich die Möglichkeiten von VMware Workstation (Schnappschüsse etc.) verwenden und dem Hersteller etwas gutes tun wollte, habe ich mich Ende Februar 2012 doch noch für ein kostenpflichtiges Upgrade von VMware Workstation 7.x auf 8.0.2 entschieden – ich wollte eine zuverlässige Virtualisierungslösung für mein Windows 8 CP-Buchprojekt. Das Upgrade war mit 77 Euro bezahlbar. Und nun das: Das Teil stürzt mir dauern ab.
Fehlerbild: übel, und seit Jahren bekannt
Das Fehlerbild ist ziemlich schnell beschrieben. Alles läuft bestens, bis man eine VM herunterfahren oder abbrechen muss. Plötzlich lässt sich keine VM mehr starten. VMware Workstation (oder der VMware Player) liefert den Fehler Exception 0xC00000005 (access violation).
Es wird ein Dump-File angelegt und dann kommt noch der Hinweis auf eine Anweisung, die auf den Speicher 0x000000008 verweist.
Ein klassischer Speicherzugriffsfehler, der durch einen Bug in der Software hervorgerufen wird. Schließt man das Dialogfeld, meldet VMware, dass kein gültiger Peer Prozess zum Verbinden gefunden wurde.
Anzeige
Und dann ist Schicht im Schacht – mit VMware geht nix mehr. Erst nach einem Neustart des Hosts kann VMware Workstation bis zum nächsten Auftreten des Bugs benutzt werden. Kommt natürlich gut, wenn man z. B. in einem Manuskript Bootvorgänge in Windows 8 beschreiben will.
Recherchiert man im Internet nach dem Fehlercode, tauchen zahlreiche Fundstellen auf – sprich, der Fehler tritt seit Jahren auf.
Schnappschüsse löschen
Unter [a] wird geraten, die Snapshots zu löschen. Na wunderbar, genau wegen dieser Funktion hatte ich VMware Workstation ja gekauft. Also alle Schnappschüsse gelöscht, neu gebootet – und es funktionierte – leider nur bis zum nächsten Crash.
Unter [b] gab es in der Community noch den Hinweis, den folgenden Befehl net start vmx86 in der Eingabeaufforderung auszuführen. Hilft dies nicht, soll der Prozess vmware-vmx.exe beendet und dann neu gestartet werden. War bei mir aber nicht möglich.
Unter [c, e] haben die Leute das System von früheren VMware Versionen bereinigt und eine ältere Version installiert bzw. neu installiert. Der Rücksprung auf die Version 7.x schied wegen Windows 8 aus. Das Säubern des Systems samt Neuinstallation half nicht weiter.
Weiter stochern im Nebel …
Die Anleitungen der VMware KnowledgeBase [f] halfen in meinem Fall auch nicht weiter. Neuinstallation konnte ich (nachdem ich die halbe Stunde geopfert hatte) als nicht hilfreich ausschließen. Speicherfehler waren unwahrscheinlich, da das System problemlos läuft. Mein Verdacht, dass eventuell Virtualbox da reinfunkt, erhärtete sich nicht – da ich bewusst auf den Einsatz der portable Version verzichtete.
Unter [h] wurde vorgeschlagen, die Datei favorites.vmls im Benutzerprofil C:\Users\<Konto>\AppData\Roaming\VMware\ zu löschen. Die Datei wird beim nächsten VMware-Start neu angelegt. Half nicht.
Unter [i] gibt es den Tipp, in den VM-Ordnern nach *.vmss-Dateien zu suchen und diese zu löschen. Sah wiederum gut aus, obwohl ich den Host neu booten musste. Aber der nächste Absturz folgte auf den Fuß. Die Diskussion unter [k] half mir auch nicht weiter, da ich kein Nero auf meinen Systemen installiert hatte.
Ach ja, es gibt wohl noch einen VMware Support …
Nachdem ich nicht wirklich weiter kam, habe ich ein Support-Ticket an VMware abgesetzt. Zurück kam der Tipp, die Anweisungen unter [j] zu versuchen. Ich habe noch einige andere Hinweise wie löschen von .vmx-Dateien und der .nvram-Dateien probiert, ohne wirklichen Erfolg.
Zwischenzeitlich wurden x .dmp-Dateien und logs an den VMware-Support geschickt. War wenig hilfreich: Einmal wurde das Support-Ticket ganz fix geschlossen, als ich zwei Tage keine Fehler hatte. Erst eine geharnischte Mail brachte den Support dazu, das Support-Ticket wieder geöffnet zu halten. Bei den nächsten Dumps kamen dann Antworten der Art:
Please execute the instructions provided in the following VMware KB article/Community forum links, revert to me with the results.
http://kb.vmware.com/kb/1006111
http://communities.vmware.com/message/2000815
http://communities.vmware.com/message/1661147
Looking forward to hearing from you.
Meine Dumps hatte vor Ort wohl keiner ausgewertet. Vielmehr kam der Hinweis, dass man meine Logs und .dmp-Dateien nicht an die Entwickler zur Analyse weitergeben könne, weil Windows 8 unsupported sei. Dann kam der Tipp, die .vmss und inventory.xmls zu löschen:
Please execute the following instructions and revert to me with the results.
- Shutdown all the VMs.
- Exit from VMware Workstation.
- Delete the file inventory.vmls inside the Host OS folders located in "C:\Users\<User Name>\AppData\Roaming\VMware\inventory.vmls"
- Delete the file(s) with extension .vmss file from the crashing VM folder located in the Host OS.
- Restart the Host machine.
- Launch VMware Workstation & power ON the VM to check if it still crashes.
Half mir aber alles nicht weiter. Mein Versuch, die .dmp-Dateien mit einem Debugger selbst auszuwerten, verlief leider auch im Sande, hatte ich doch keine Debug-Symboldateien von VMware Workstation zum Zugriff.
Fahren wir das Ganze mal gepflegt gegen die Wand
Also doch auf den VMware Support hoffen? Dessen nächste Antwort war:
Please also note that Windows 8 Consumer preview is not yet officially supported by our product. We can expect its support in later maintenance releases. We already have a feature request open for that.
Also Standardantwort: Das Produkt, was Du testest, ist nicht supported. Cool, sagt irgendwie auch was darüber aus, was man von dem ganzen Teil halten soll. Wenn also ein Gast-Betriebsystem Amok läuft, muss ich bei einem "unsupported guest" davon ausgehen, dass mein Host die Grätsche macht oder noch schlimmeres passiert? Und da verwenden Leute VMware VMs zur Analyse von Schadsoftware …
Der zweite Vorschlag des VMware Supports: Ich möge doch die Technology Preview der VMware Workstation auf einem Windows 8 Host und auf Windows 7 64 Bit Ultimate installieren und mit bzw. ohne Windows 8 Gäste testen. Weil ich händeringend eine Lösung suchte (ich wollte mein Buchprojekt abschließen), habe ich mich darauf eingelassen. Ergebnis:
- Auf dem Windows 8 Host kollidierte die Preview mit der Hyper-V Rolle und die Gäste liefen nicht wirklich. Ich habe das Dell-System mit Windows 8 als Host zwischenzeitlich platt gemacht und den Rechner an den Hersteller zurückgegeben. Also nicht wirklich brauchbar.
- Auf dem Windows 7 64 Bit Ultimate hatte ich nach wenigen Stunden einen Crash der VM, so dass ich den Gast zwangsweise beenden musste, was einen BlueScreen des Host-Systems verursachte. War natürlich wunderbar, da dieser Reboot auch die geöffneten Word-Fenster mit den Manuskriptdateien mit in den Orkus riss.
Zudem war die neue Version langsam bis zäh im Ablauf. Als ich dann (per Wiederherstellungspunkt) auf VMware Workstation 8.0.2 zurück ging, waren die Konfigurationsdateien ungültig und ich musste die virtuellen Maschinen neu anlegen.
Außer Spesen nix gewesen …
Nach nun einem Monat Stoppelei bin ich so weit wie vorher und zur Erkenntnis gelangt, dass der Kauf der VMware Workstation Lizenzen ein "Griff ins Klo" war. Ich habe in den letzten Tagen zur Fertigstellung des Buchmanuskripts auf Oracle Virtualbox gesetzt und konnte zumindest ohne Abstürze arbeiten.
Mein Fazit: Außer Spesen nix gewesen. Wenn ich es richtig erinnere, habe ich 2001 das erste Buch zu VMware Workstation geschrieben und seit dieser Zeit diverse Versionen von VMware Workstation, Server und Player im Einsatz. Wenn es mal lief, war das Produkt ok – aber sobald man Probleme hatte, konnte man den Support vergessen.
Meist blieb nur, auf die nächste Version zu warten und dann ein kostenpflichtiges Upgrade durchzuführen oder auf eines der kostenlosen Tools wie VMware Server oder VMware Player auszuweichen.
Conclusio?
Momentan sieht es aber so aus, als ob VMware Workstation 8.0.2 nicht wirklich mit Windows 8 kompatibel ist und/oder Probleme mit 64 Bit Windows 7-Ultimate Hosts hat.
Ich werde (nach meinen diversen Erfahrungen) wohl zukünftig die Finger von VMware Workstation lassen – Oracles Virtualbox ist zwar auch nicht das Gelbe vom Ei – aber über die letzten Jahre lief es immer einen Tick smoother als bei VMware Server oder Player und machte weniger Probleme.
[Update: Der Blog-Beitrag ist vor gut einer Woche, nach Abschluss meines Windows 8 Buchprojekts, entstanden – ging aber aus internen Gründen erst am 12.4. online. Auf meinen letzten Dump (30.3.) gab es doch tatsächlich bereits am 11.4 eine Rückmeldung. Kein Hinweis, was falsch gelaufen ist, sondern nur die Frage, ob ich nicht die kommende Tech Preview von VMware Workstation testen möge. Schön, wenn man seine Kunden als Test-Vieh nutzen kann – so macht Support richtig Laune…
… aber auf Tests irgendwelcher Tech Previews von VMware Workstation 8.x habe ich jetzt echt keinen Bock mehr.]
Sollte ich noch eine Lösung finden, trage ich diese hier nach.
Links:
a: cannot find a valid peer process to connect to (2009)
b: Cannot find a valid peer process to connect to (2008)
c: Diskussion im Mac-Forum
d: Fehlerbeschreibung
e: Fehlerdiskussion in der VMware community
f: VMware Knowledge-Base-Artikel I
g: VMware Knowledge-Base-Artikel II
h: Fehlerdiskussion bei Steven Whiting
i: Diskussion in VMware community
j: Infos aus der VMware Knowledgebase
k: Diskussion des Fehlers
2015
Pingback: [BLOCKED BY STBV] Kritisches Sicherheitsupdate für VMware-Produkte « Borns IT- und Windows-Blog
Pingback: [BLOCKED BY STBV] VMware Workstation 8.0.3/Player 4.0.3 erschienen « Borns IT- und Windows-Blog
Pingback: [BLOCKED BY STBV] Frage ganz wichtig!! - Allgemeines (Windows 8)
Nachtrag: Es kristallisiert sich heraus, dass der Fehler auch in der Version 8.0.4 auftritt. Ich muss es mal beobachten – möglicherweise verkraftet VMware es nicht, wenn ein Gast oder der Host in den Ruhezustand versetzt und dann wieder aufgeweckt wird. Immer nach solchen Aktionen habe ich den Fehler.
Guten Morgen, gleiches Problem auf meinem Testsystem am Wochenende: diverse bisher problemlos funktionierende VMs stützten so ab, auch unter 8.0.4.
Danke zunächst für die hilfreiche Zusammenfassung aller Varianten! – allerdings hatte ich selbst nach dem ganzen verregneten Sonnabend ebenfalls keinen Erfolg.
Heute Morgen der Zufallstreffer (nachdem ich mir nur für die weiteren Recherchen mit SIW eine Zusammenfassung aller Ressourcen erstllen wollte): der nicht sauber laufende ATI-/AMD-Grafikkartentreiber war bei mir die Ursache. Nach Neuinstallation des aktuellen Catalyst-Paketes (12.x) laufen meine VMs alle wieder.
Viele Grüße
Volkmar Roth
CompuGROUP Medical Deutschland AG
Geschäftsbereich Arztsysteme
COMPUMED M1
56070 Koblenz
@Volkmar: Danke erst einmal für die Beobachtung – ich habe hier Nvidia-Treiber. Ich tippe hier darauf, dass es da irgend etwas damit zu tun hat, dass Host oder Gast suspendiert werden und dann eine VM nicht sauber runter fährt. Vielleicht werfe ich doch noch mal einen Debugger an und schaue mir den dump an, ob da was zu finden ist.
Update: Ich kann es nun definitiv festmachen. Der Fehler tritt hier auf, nachdem der Host in den Ruhemodus geschickt und dann aufgeweckt wurde. Dabei ist es egal, ob VMware vorher lief oder beendet war.
Lösung: Unter [1] findet sich eine ähnliche Diskussion, wo jemand den gleichen Fehler feststellt. Ursache war wohl, dass nach dem Hibernation-Mode die CPUID fehlerhaft gemeldet wird. Ich habe es mal getestet – und im BIOS die Option MaxCPUID Value Limit auf "disabled" gestellt – das Problem ist damit gelöst.
Dieses Problem mit VMware Workstation ist also passé. Auffällig ist aber, dass Virtualbox diese Probleme nicht hat. Und was mich kolossal ärgert – wie oben im Blog-Beitrag beschrieben, habe ich zig Dumps und Log-Dateien an den VMware Support übermittelt. Aber die hatten – nachdem ich die Ursache (unterschiedliche CPUID-Werte des Hosts, erkennbar in den log-Dateien) kenne, offenbar keinen Bock, sich irgendwie mit dem Thema zu befassen. Die Supporter (dem Namen nach indischer Herkunft) verfügten offenbar nicht über die Kenntnisse, sich da hinter die Ursache zu klemmen – und die VMware-Entwickler haben das alte Spielchen herangezogen "Ups, der Anwender nutzt Windows 8 Consumer Preview – ist ja kein Produkt auf dem Markt, das ist die Ursache und damit kümmern wir uns nicht drum – denn es kommt ja eine neue VMware-Workstation-Version". Noch ein Grund, VMware zukünftig den Rücken zu kehren (obwohl Workstation ein paar nette Funktionen bietet – sofern die Software es tut – denn bei Problemen musste ich mir immer selbst die Lösung auf mühsamen Wegen erarbeiten.
1: http://communities.vmware.com/thread/406562?start=15&tstart=0
Ich habe selbst ziemlich schlechte Erfahrungen mit dem VMware-Support gemacht. Anscheinend ist man dort hauptsächlich daran interessiert, die Tickets so schnell wie möglich zu schliessen, unabhängig davon, ob das Problem gelöst ist oder nicht. Es drängt sich der Eindruck auf, dass hier gnadenlos irgendeine Metrik verfolgt wird ("geschlossene Tickets pro Tag" o.ä.), nach der sich wahrscheinlich die Vergütung berechnet.
Trotzdem denke ich, muss man bei diesem speziellen Problem mildernde Umstände für VMware gelten lassen. Es ist sehr ungewöhnlich, dass heutzutage MaxCPUID im BIOS gesetzt ist. Ich weiss nicht, ob es überhaupt Mainboards gab, bei denen diese Einstellung defaultmässig gesetzt war, aber in den letzten zehn Jahren dürfte dies bei keinem Mainbard mehr der Fall gewesen sein. Ich habe diese Einstellung gelegentlich verwendet, um NT4 auf neueren PCs zu installieren.
@Uatu: Danke für das Feedback. Zu MaxCPUID lässt sich nur sagen, dass ich hier (bei einem MSI-Board in einem Medion) mit Standard BIOS-Einstellungen gefahren bin. Und der Punkt ist ein anderer: Im verlinkten Forenthread schlagen ja noch andere Nutzer mit gleicher Erfahrung auf – und ein guter Supporter hätte auf die Idee kommen können, mal die Logs für erfolgreiche und nicht erfolgreiche VM-Starts abzufragen.
Anyway, ich bin froh, dass ich den Fehler nach langer Zeit eingekreist und schließlich gelöst habe. Beim Thema "Einfrierendes System bei mehr als einer Gastmaschine" musste ich mich auch selbst zur Ursache durchkämpfen. Da frage ich mich schon, warum ich VMware mit dem Kauf von Workstation überhaupt noch unterstützen soll. Bisher habe ich einen Klops nach dem anderen mit dieser Firma erlebt (man braucht sich nur mal das Inhaltsverzeichnis hier aufzurufen und die Blogbeiträge nach VMware durchsuchen zu lassen) – selbst das Einkaufen wird bei denen zum Abenteuer – alles nicht gut.
Hi,
das "langsam" von vmware liegt übrigens nach meinem Probieren daran, dass vmware auf das "nach-haus-telefonieren" wartet, und vmware's server wohl ziemlich lahm sind. Sobald man "beim Start auf Updates prüfen" sowie "Weiterentwicklung unterstützen (anonyme Nutzungsdaten senden)" unter "Datei > Voreinstellungen" deaktiviert, funktioniert vmware bei mir ziemlich schnell.