Probleme bei der Installation des WIN10 Funktionsupdate 1903

[JMLAB]

Hallo,

zuallererst möchte ich mich vor dem Verfassen meines ersten Beitrags für die Aufnahme in Eurem Forum bedanken !


Grundlegende Vorab-Informationen >

Installiertes VMware Produkt: VMware Workstation 12 Pro
Version: 12.5.9 ( Build: 7535481 ) / ( Deutsch )

Host OS Version: Windows 10 Professional 64Bit ( 1809 / Build: 17763 ) 10.0.17763 / ( Deutsch )

Gast OS : Windows 7 Professional SP1 64Bit ( Englisch US )

Gast OS : Windows XP Professional SP3 32Bit ( Deutsch )


Problembeschreibung >

Beim Windows Update von Windows 10 Professional 64Bit Version 1809 auf Version 1903 tritt ein Fehler im Zusammenhang mit VMware Workstation 12 Pro auf ( siehe die beiden nachfolgenden verlinkten Fotos ) >






Kennt wer von Euch diese Hürde ?

Was ist Eurer Meinung nach zu tun, um dieses Problem bestmöglich ( ohne Datenverluste ) und kostengünstig ( möchte wenn möglich bei VMware Workstation 12 Pro bleiben ) zu lösen ?

Mit bestem Dank im Voraus für Eure Unterstützung !

LG

[~thc]

Das "Update" auf 1903 nicht durchführen und die Installation von Funktionsupdates für 365 Tage (ist das Maximum) verzögern.
Nach dem Support-Ende von 1809 (12.05.20) muss dann eine neue Workstation her.

[JMLAB]

Hab nun die Verzögerung der Installation von Funktionsupdates wie empfohlen auf 365 Tage gesetzt, Danke für Deinen Tipp !

So wie es aussieht, kann man damit den Installations-Vorgang bzw. den Installations-Versuch des Funktionsupdate 1903 jedoch nicht mehr stoppen.

Sehr wahrscheinlich können daher auch keine monatlichen Qualitätsupdates mehr gezogen werden, solange das Funktionsupdate 1903 nicht vollständig installiert wurde.

Bei meinen nächtlichen Recherchen bin ich dann auf folgende Website gestossen >

VMware Workstation and Hyper-V – Working Together >

https://techcommunity.microsoft.com/t5/ ... a-p/825831


So wie es ausschaut, kommt MS Windows Hyper-V [ Sandbox ] in Konflikt mit dem VMware eigenen Hypervisor.

Sehe ich das richtig ?

Wisst Ihr, ob VMware bereits an einer Lösung arbeitet und wann mit einer neuen unter Windows 10 Version 1903 lauffähigen VMware Workstation Pro zu rechnen ist !?

LG

[JMLAB]

Weiss wer von Euch, ob die aktuellste VMware Workstation Pro Version 15 unter WIN10 Pro Version 1903 lauffähig ist und das im hiesigen Eingangsthread beschriebene Problem nicht auftritt !?

Wenn ja, würde ich mir das Upgrade kaufen.

Bitte um Eure Unterstützung !


PS.: Unter nachfolgenden Link berichtet das Foren Mitglied Chemiker die Lösung mit der VMware Workstation Pro Version 15 unter WIN10 Pro Version 1903 gefunden zu haben >

https://www.delphipraxis.net/201089-win ... mware.html

.

[~thc]

1. Die Verzögerung der Funktions-"Updates" hat keinen Einfluss auf die Sicherheitsupdates.
2. Früher konnte man mal Updates "ausblenden" - ob das aktuell mit Win 10 und den Funktions-"Updates" geht, weiß ich nicht.
3. Hyper-V oder Funktionen, die Virtualisierung einsetzen (Device Guard, Sandbox), vertragen sich nicht mit VMWare-Produkten.
4. Der Workstation Player 15.1.0 läuft problemlos mit 1903.

[Dayworker]

Das Problem wird sein, daß die Verzögerung zu spät kam und nun das Update bereits auf die VM herunter geladen wurde. Ob man das Update jetzt noch sauber abbrechen kann, entzieht sich meiner Kenntnis.
Aber eigentlich ist das alles kein Problem, entweder hat man ein Backup von vor der als Update getarnten, neuen Win10-Version oder einen Snapshot angelegt. In jedem Fall tut man bei Win-VMs immer gut daran, diese vor dem offiziellen M$-Patch-Tag (zweiten Dienstag im Monat) zu sichern. Das schont die Nerven.

[JMLAB]

Das Problem wird sein, daß die Verzögerung zu spät kam und nun das Update bereits auf die VM herunter geladen wurde. Ob man das Update jetzt noch sauber abbrechen kann, entzieht sich meiner Kenntnis.
Aber eigentlich ist das alles kein Problem, entweder hat man ein Backup von vor der als Update getarnten, neuen Win10-Version oder einen Snapshot angelegt. In jedem Fall tut man bei Win-VMs immer gut daran, diese vor dem offiziellen M$-Patch-Tag (zweiten Dienstag im Monat) zu sichern. Das schont die Nerven.

Vielen Dank für Deinen Beitrag und Deine Infos !

Es ist in der Tat so, dass der bereits angestossene Installationsvorgang des Funktionsupdate 1903 nicht mehr sauber abgebrochen werden kann und sich sozusagen _vor_ die Installation der monatlichen Qualitätsupdates ( MS Patch-Day ) schiebt.

Acronis True Image ist seit vielen Jahren mein Verbündeter, ein System Backup wurde noch vor der Installation des Funktionsupdate 1903 gezogen, ich werde es nach dem Ablauf der von mir angestossenen Verzögerung der Installation jeglicher WIN10 Updates von 35 Tagen restoren, sollte bis dahin nicht vielleicht doch die Firma VMware eine Lösung in ihrer Workstation Pro erarbeitet haben und zum Download bereitstellen.

Wie wahrscheinlich ist das !?

Vielen Dank im Voraus für Eure von mir sehr geschätzte Unterstützung !

LG

PS.: Bezüglich Acronis System Restore >

Ich versuche wo nur möglich bei OS Problemen Lösungen zu finden, die den Acronis System Restores zuvorkommen, anderenfalls immer wieder Probleme mit Microsoft vorprogrammiert sind, nach spätestens vier Acronis System Restores gibt es Probleme mit der Windows Aktivierung und Unannehmlichkeiten mit dem MS Support oder/und gezwungenermassen dem Kauf eines neuen WIN10 Activation-Code / Product-Key.

[Dayworker]

Ich hatte bisher mit reinen VMware-Snapshots auch keine Probleme mit dem Rücksetzen auf einen früheren Zeitpunkt, allerdings warte ich damit auch nicht so lange. Beim Rückspielen eines Acronis Images könnte eine neue OS-ID gebildet werden und die könnte dir dann die Probleme mit der Aktivierung machen.

Erste Maßnahme gegen solche unliebsamen M$-Überraschungen ist das Ändern der M$-Updates auf "nur Informieren, aber manuelles Einspielen". Letzteres haben wir auf Arbeit auch immer wieder, daß die Rechner gerne am helllichten Tag ein Update-Reboot fahren wollen. Sobald diese Meldung kam, ist an ein normales Arbeiten nicht mehr zu denken, weil der Update-Prozeß immer wieder Systemleistung abruft...

[JMLAB]

Erste Maßnahme gegen solche unliebsamen M$-Überraschungen ist das Ändern der M$-Updates auf "nur Informieren, aber manuelles Einspielen"

Das konnte man unter Windows 7 so festlegen, unter Windows 10 allerdings nicht.

Oder gibt es unter Windows 10 doch irgendwo versteckt diese Möglichkeit ( "nur Informieren, aber manuelles Einspielen" ) , die ich in den Windows 10 Update Einstellungen bisher übersehen habe ?

Vielen Dank für Deine Tipps und Unterstützung !

LG

[Dayworker]

Inzwischen leider nicht mehr, aber zumindest wenn der Rechner per WLAN verbunden ist, hat man als Ausweg noch die Möglichkeit festzulegen, daß das eine kostenpflichtige Verbindung (getaktete Verbindung) ist.
Mit der 1903 werden Updates anscheinend automatisch um 7 Tage verzögert und Funktionsupgrades setzt man halt manuell entweder auf das Maximum oder läßt sich ausreichend Zeit. Mir wurde die 1903 jedenfalls erst gestern angeboten und das Update ist gleich 7 Mal gescheitert. Mein Weg lief dann - nicht zum ersten Mal - über den Windows Update Assistent. Der scheint wesentlich pflegeleichter zu sein, jedenfalls lief dessen Online-Version problemlos durch. Notfalls kann man sich aber auch die ISO laden.

Falls du noch Lust zum Rumprobieren hast, würde ich das normale Update sein lassen und den Weg über den Assistenten probieren.

[JMLAB]

...

Da wird sich Microsoft noch viel von Apple abschauen müssen !

Für mich war / ist der Microsoft Patch-Day stets der schlimmste Tag im Monat, mehr noch als Freitag der 13-te :-l

Mit der Einführung von Funktionsupgrades ( zusätzlich zwei schlimme Tage im Jahr ) hat sich Microsoft bei mir nicht beliebter gemacht, sind dadurch - im Vergleich zu früher - wesentlich häufigere Komplikationen mit Drittanbieter Software Produkten vorprogrammiert, ohne ein Prophet sein zu müssen.

Wenn gleich ich der Firma VMware Nachlässigkeit bei ihren Vorab-Recherchen zu der inhaltlichen Herausforderung des Funktionsupgrades 1903 rechtzeitig im Vorfeld der Verteilung und einen recht sorglosen Umgang mit ihrer Kundschaft vorwerfe, sowie eine für mich nicht nachvollziehbare Verzögerung einer 1903 tauglichen VMware Workstation Pro Version, so hat wenigstens Microsoft bei seiner 1903 funktional gute Ansätze angedacht [ Device Guard, Sandbox ] , jedoch wie so oft ohne Rücksicht auf Drittanbieter Software Anwendungen umgesetzt.

Bleibt zu fragen, wann mit einer neuen Microsoft Funktionsupgrade 1903 tauglichen VMware Workstation Pro Version zu rechnen ist !?

Wisst Ihr zum Release Genaueres ?

LG

[Dayworker]

Eine Nachlässigkeit auf Seiten von VMware sehe ich nicht direkt. M$ mußte jedoch am Umfang der 1903 deutlich schrauben, um es stabil zu bekommen. Es spricht ja schon Bände, wenn M$ das Upgrade stellenweise erst jetzt zur Inst anbietet. Wobei das auch noch mit den kommunizierten, alten Supportzeiträumen zusammenhängen dürfte. Die Märzversion hatte ja nur 6 Monate und die vom September dagegen glaube 18 Monate. Unabhängig davon hat in nicht sehr wenigen Fällen sogar erst das letzte Update vor 14 Tagen für ein reibungsloseres Verhalten der 1903 geführt. Zuviele Bugs sind dennoch verblieben und werden weiterhin für mehr oder minder schwere Probleme sorgen.

Das es Apple da bedeutend einfacher hat, liegt aufgrund der überschaubaren Geräteanzahl auf der Hand.


Die Frage hinsichtlich einer neuen Produktversion kann dir höchstens VMware selbst geben und das haben sie in all den Jahren, seitdem ich mich mit VMware beschäftige, nie getan. Eine Version wird veröffentlich, wenn VMware den Zeitpunkt für passend hält. Allerdings hatte VMware in unregelmäßigen Abständen für eingeladene BETA-Tester neue Produktversionen zum Funktionstesten herausgegeben. Unser Ulli aka "continuum", der auch im VMTN als Moderator unterwegs ist, hatte auch Zugriff auf mindestens eine diese WS-Versionen.
Meiner persönlichen Meinung nach wird VMware sich mit der 1903 nur noch rudimentär beschäftigen und sich eher auf das kommende, bereits in Test befindliche Funktionsupgrade konzentrieren. Passend dazu kommt auch die unterzeichnete Absichtserklärung beider Firmen, daß VMware Zugriff auf die verbesserten Sicherheitsfeatures (Device Guard, Sandbox etc) bekommen soll.

[JMLAB]

Hallo,

zu allererst ein gutes neues Jahr !

Weiss wer von Euch, ob in der dzt. jüngsten Version von VMware Workstation Pro - der Version 15.5 - das in diesem Thread diskutierte Problem nun behoben wurde !?


Hier in wenigen Worten nochmals kurz der Sachverhalt >

WIN10 Funktionsupgrade Version 1903 >

Durch das in WIN10 Funktionsupgrade 1903 implementierte Windows Hyper-V oder Funktionen, die Virtualisierung einsetzen [ Device Guard, Sandbox ] , wird eine Inkompatibilität unter VMware Produkten hervorgerufen, da sie in Konflikt mit dem VMware eigenen Hypervisor treten !!
______________________________________


Eine umfangreiche Recherche meinerseits nach einem zeitnahen Release einer VMware Workstation Pro Version 16 hat keine Ergebnisse gebracht.

Daher gehe ich davon aus, dass in der Zwischenzeit die Firma VMware in ihrer Version 15.5 dahingehend aktiv geworden sein müsste.


Sehe ich das richtig !?


Vielen Dank im Voraus für Eure Unterstützung !

LG

[Dayworker]

Bei solchen Fällen kann ich nur auf das offizielle von VMware geführte VMTN verweisen. Darin lesen auch einige Entwickler bzw Projektverantwortliche mit, hier jedoch nicht. Aber du darfst gerne einen Link zu deinem VMTN-Thread hier ins Forum posten

[JMLAB]

Bei solchen Fällen kann ich nur auf das offizielle von VMware geführte VMTN verweisen. Darin lesen auch einige Entwickler bzw Projektverantwortliche mit, hier jedoch nicht. Aber du darfst gerne einen Link zu deinem VMTN-Thread hier ins Forum posten

Hallo,

kürzlich fündig geworden >

Supported host operating systems for Workstation Pro 12.x, 14.x and 15.x (2129859) >

Note: VMware Workstation 15.x and above is compatible with Windows 10 1903 as a host operating system

https://kb.vmware.com/s/article/2129859

.

[Dayworker]

Die Frage nach 1903 dürfte sich inzwischen eigentlich nicht mehr stellen, M$ empfiehlt da ja die 1909...

[JMLAB]

Die Frage nach 1903 dürfte sich inzwischen eigentlich nicht mehr stellen, M$ empfiehlt da ja die 1909...

Was immer im März 2020 an Windows 10 Funktionsupgrades auf meinem System eingespielt werden, wichtig ist rechtzeitig vorher bezüglich einer 1903 bzw. 1909 kompatiblen VMware Workstation Pro Version aktiv zu werden.


Frage >

Welche Erfahrungen konntest Du bisher mit Produkt _Upgrades_ ( nicht Updates ) von VMware Workstation Pro machen, wenn auf dem Host-OS bereits eine VMware Workstation Pro Vorgänger-Version installiert ist und eine oder mehrere VMs als Gast-OS darauf laufen !?

Vielen Dank im Voraus für Deine Infos !

LG R.

[Dayworker]

Wenn Winzigweich seine als Funktionsupgrade getarnte neue OS-Version rausbringt, wird VMware wie immer noch etwas Zeit zum Anpassen brauchen. Wir haben da jedoch die wage Hoffnung, daß VMware aufgrund der mit Winzigweich verkündeten Kooperation es diesmal schneller oder einfach nur fehlerfreier hinbekommt.

Da die Gäste in einem anderen Verzeichnis als Programmdateien liegen, stört diese auch kein Programmupdate. Jedoch hat es sich bewehrt, kein Inplace-Upgrade zu fahren, wenn man von nervigen Fehler verschont bleiben will:

1. WS/Player deinstallieren
2. Rebooten und im System-Log nach verbliebenden VMware-Einträgen suchen
3. WS/Player einspielen

[JMLAB]

Wenn Winzigweich seine als Funktionsupgrade getarnte neue OS-Version rausbringt, wird VMware wie immer noch etwas Zeit zum Anpassen brauchen. Wir haben da jedoch die wage Hoffnung, daß VMware aufgrund der mit Winzigweich verkündeten Kooperation es diesmal schneller oder einfach nur fehlerfreier hinbekommt.

Da die Gäste in einem anderen Verzeichnis als Programmdateien liegen, stört diese auch kein Programmupdate. Jedoch hat es sich bewehrt, kein Inplace-Upgrade zu fahren, wenn man von nervigen Fehler verschont bleiben will:

1. WS/Player deinstallieren
2. Rebooten und im System-Log nach verbliebenden VMware-Einträgen suchen
3. WS/Player einspielen

Hallo,

hab Dank für Deine Infos und bleib mir bitte noch gewogen, bis ich diesen Sachverhalt verstehe !

Heisst das, dass bei der Deinstallation einer VMware Workstation Pro die Gast-OS unangetastet bleiben, also nicht gelöscht werden !?

Wird während einer Neu-Installation einer VMware Workstation Pro die Gast-OS erkannt und wieder mit eingebunden !?

Gruss R.

[JustMe]

Heisst das, dass bei der Deinstallation einer VMware Workstation Pro die Gast-OS unangetastet bleiben, also nicht gelöscht werden !?

So ist es.
Es duerfte nur aeusserst wenige Programme geben, die bei ihrer Deinstallation Benutzerdaten (erfolgreich) loeschen.

Wird während einer Neu-Installation einer VMware Workstation Pro die Gast-OS erkannt und wieder mit eingebunden !?

Nein.
Das wirst Du bei einer manuellen Neuinstallation selbst wieder tun muessen.

Gruss

[JMLAB]

Heisst das, dass bei der Deinstallation einer VMware Workstation Pro die Gast-OS unangetastet bleiben, also nicht gelöscht werden !?

So ist es.
Es duerfte nur aeusserst wenige Programme geben, die bei ihrer Deinstallation Benutzerdaten (erfolgreich) loeschen.

Wird während einer Neu-Installation einer VMware Workstation Pro die Gast-OS erkannt und wieder mit eingebunden !?

Nein.
Das wirst Du bei einer manuellen Neuinstallation selbst wieder tun muessen.

Gruss

Auch Dir besten Dank für Deine Unterstützung !

Gruss R.

[JMLAB]

Hallo,

VMs _vor_ dem Produkt Upgrade wie in meinem speziellen Fall von VMware Workstation Pro Version 12.5.9 auf VMware Workstation Pro Version 15.5 z.B. auf eine Externe Festplatte den gesamten Verzeichnis Inhalt mit Copy / Paste sichern ( siehe Screenshot 1 und Screenshot 3 ) >

VMs _nach_ dem Produkt Upgrade wie in meinem speziellen Fall von VMware Workstation Pro Version 12.5.9 auf VMware Workstation Pro Version 15.5 von z.B. einer Externen Festplatte implementieren ( siehe Screenshot 2 und Screenshot 4 in übertragenem Sinne ) >


Screenshot 1


Screenshot 2


Screenshot 3


Screenshot 4


Gruss R.

PS.:

An die Forums Kollegen und mitlesenden Leidensgenossen >

Bitte mich inhaltlich zu korrigieren, falls ich trotz aller waltenden Umsicht und umfangreichen Recherchen etwas nicht ganz richtig verstanden habe.

Man sollte ja bei einem Software Hersteller wie VMware fast glauben, dass diese Angelegenheit komplizierter wäre, scheint sie aber nicht zu sein.

Trotzdem stehe ich - wie vielleicht andere hier Mitlesende auch - kurz vor dem Produkt Upgrade !

Ganz voran werde ich mit Acronis True Image xxxx von meinem Rechner ein System Backup / System Image machen / ziehen. Danach erfolgt die vollständige Deinstallation von VMware Workstation Pro Version 12.5.9 und einem unmittelbar danach erforderlichen Restart / Neustart meines Rechners. Gleich danach werde ich mit Autoruns für Windows mit der derzeit aktuellsten Version 13.96 ( Published: June 28, 2019 ) von Microsoft ( Mark Russinovich ) nach etwaigen Software Überresten von VMware Workstation Pro Version 12.5.9 suchen und diese meist in der Registry noch gespeicherten Einträge deaktivieren bzw. löschen.

Link zu Autoruns ( Sysinternals ) >

https://docs.microsoft.com/en-us/sysint ... s/autoruns


Erst danach erfolgt die Re-Installation der VMware Workstation Pro Version 15.5 - bei mir ein Upgrade - und nach erfolgreicher Installation die Implementierung der z.B. auf einem Externen Datenträger gesicherten VMs ( Virtual Machines ) .

.

[JMLAB]

Rebooten und im System-Log nach verbliebenden VMware-Einträgen suchen

Hallo,

mit welchem Tool entfernst Du verbliebene VMware Einträge ?

Wo findet man das System-Log ?


Danke im Voraus !

LG

[~thc]

Das (sehr nützliche) Tool "Autoruns" kümmert sich um sehr viele Orte, von denen aus in Windows Prozesse gestartet werden können. Wenn man ein Produkt deinstalliert, kommt es durchaus vor, dass Autoruns verwaiste Einträge (in gelb) findet, die man dort löschen kann.

Aber diese Orte sind nur eine Teilmenge aller Orte, an denen Reste verbleiben können. Eine Auswahl:

1. User

- C:\Users\Username\Herstellername...
- C:\Users\Username\Produktname...
- C:\Users\Username\Documents...
- C:\Users\Username\AppData\Local\Herstellername...
- C:\Users\Username\AppData\LocalLow\Herstellername...
- C:\Users\Username\AppData\Roaming\Herstellername...
- HKEY_CURRENT_USER\Software\Herstellername...

2. Alle Benutzer

- C:\ProgramData\Herstellername...
- C:\ProgramData\Produktname...

3. System

- C:\Program Files\Common Files\Herstellername...
- C:\Program Files\Herstellername...
- C:\Program Files (x86)\Common Files\Herstellername...
- C:\Program Files (x86)\Herstellername...
- C:\Windows\System32\drivers (Treiberdateien)
- C:\Windows\System32 (Dienstdateien)

- HKEY_CLASSES_ROOT (Typenregistrierung, Klassenregistrierung)
- HKEY_LOCAL_MACHINE\SOFTWARE\Herstellername...
- HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Herstellername...
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dienst- oder Treibername (Dienste)

- HKEY_USERS\.DEFAULT\Software\Herstellername... (LocalSystem)
- HKEY_USERS\S-1-5-19\Software\Herstellername... (LocalService)
- HKEY_USERS\S-1-5-20\Software\Herstellername... (NetworkService)

[JMLAB]

Das (sehr nützliche) Tool "Autoruns" kümmert sich um sehr viele Orte, von denen aus in Windows Prozesse gestartet werden können. Wenn man ein Produkt deinstalliert, kommt es durchaus vor, dass Autoruns verwaiste Einträge (in gelb) findet, die man dort löschen kann.

Aber diese Orte sind nur eine Teilmenge aller Orte, an denen Reste verbleiben können. Eine Auswahl:

1. User

- C:\Users\Username\Herstellername...
- C:\Users\Username\Produktname...
- C:\Users\Username\Documents...
- C:\Users\Username\AppData\Local\Herstellername...
- C:\Users\Username\AppData\LocalLow\Herstellername...
- C:\Users\Username\AppData\Roaming\Herstellername...
- HKEY_CURRENT_USER\Software\Herstellername...

2. Alle Benutzer

- C:\ProgramData\Herstellername...
- C:\ProgramData\Produktname...

3. System

- C:\Program Files\Common Files\Herstellername...
- C:\Program Files\Herstellername...
- C:\Program Files (x86)\Common Files\Herstellername...
- C:\Program Files (x86)\Herstellername...
- C:\Windows\System32\drivers (Treiberdateien)
- C:\Windows\System32 (Dienstdateien)

- HKEY_CLASSES_ROOT (Typenregistrierung, Klassenregistrierung)
- HKEY_LOCAL_MACHINE\SOFTWARE\Herstellername...
- HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Herstellername...
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dienst- oder Treibername (Dienste)

- HKEY_USERS\.DEFAULT\Software\Herstellername... (LocalSystem)
- HKEY_USERS\S-1-5-19\Software\Herstellername... (LocalService)
- HKEY_USERS\S-1-5-20\Software\Herstellername... (NetworkService)

Hallo,

hab vielen Dank für Deine ausführlichen Infos , ich komme später darauf zurück !


Die von mir nachfolgend angeführten Informationen beziehen sich auf ein bereits gestern subjektiv sauber deinstalliertes VMware Workstation Pro 12.5.9 aus den “Systemsteuerungen / Programme und Features“ heraus, und in weiterer Folge auf jene verwaiste VMware Programm Überreste, die ich mit verschiedene Tools heute gefunden habe oder diese Tools einfach nicht angeschlagen haben >


Autoruns x64 ( Sysinternals / Microsoft ) >

Mit Autoruns x64 hab ich einen einzigen “gelben“ VMware Eintrag gefunden, dieser wurde gelöscht.


Process Explorer x64 ( Sysinternals / Microsoft ) >

Die integrierte Such-Funktion lieferte keine Ergebnisse nach verwaisten VMware Programm Überresten.


Windows RegEditor ( regedit ) >

Die integrierte Such-Funktion lieferte sehr viele Ergebnisse nach verwaisten VMware Programm Überresten.

Alle diese Registrierungseinträge in der Registry auf verbliebene VMware Überreste hier anzuführen wäre kaum machbar und aus derzeitiger Sicht auch nicht sehr sinnvoll.

Löschungen in der Registrierungsdatenbank / Registry möchte ich zum derzeitigen Zeitpunkt ohne vorheriger Rücksprache mit Euch noch nicht vornehmen.


Jetzt ein wenig was in den Magen und danach einen kurzen Erholungsschlaf, danach erhoffe ich einen halbwegs entspannten klaren Kopf für die Verifizierung mit Deinen von Dir eingangs angeführten Informationen !

Danke nochmals !

LG