Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Windows NT4 auf VMWare Player/Workstation bootet nicht
Windows NT4 auf VMWare Player/Workstation bootet nicht
Ich habe einen Rechner auf dem noch Windows NT4 SP6 läuft und bin dabei diesen per VMWare auf einem neuen Win7 Professional-Rechner zu virtualisieren.
Das alte Betriebssystem wurde per VMWare Converter boot CD in .vmdk konvertiert und sollte dann auf dem Hostrechner mit VMWare Player, bzw. Workstation zum Laufen gebracht werden.
Der OS-Loader des Gastsystems wird gestartet. man kann NT4 beim Bootvorgang auswählen, dann bleibt der Bootvorgang immer an der gleichen Stelle hängen:
http://i.imgur.com/SGFcsrE.jpg
Einmal das Log:
https://www.dropbox.com/s/18sjdhuernw1m99/vmware.log
Es wäre genial wenn mich jemand in die richtige Richtung weisen, bzw. mir einen Lösungsansatz geben könnte.
Danke
Das alte Betriebssystem wurde per VMWare Converter boot CD in .vmdk konvertiert und sollte dann auf dem Hostrechner mit VMWare Player, bzw. Workstation zum Laufen gebracht werden.
Der OS-Loader des Gastsystems wird gestartet. man kann NT4 beim Bootvorgang auswählen, dann bleibt der Bootvorgang immer an der gleichen Stelle hängen:
http://i.imgur.com/SGFcsrE.jpg
Einmal das Log:
https://www.dropbox.com/s/18sjdhuernw1m99/vmware.log
Es wäre genial wenn mich jemand in die richtige Richtung weisen, bzw. mir einen Lösungsansatz geben könnte.
Danke
Beim Booten kommt er schon ziemlich weit, das Filesystem scheint in Ordnung. Den Bootloader und das Windows-Verzeichnis hat er gefunden.
Vermutlich ist es ein Treiberproblem.
Bitte folgende Optionen in der boot.ini aktivieren:
(dafür temporär die vmdk in ein anderen Windows-System einbinden)
/BASEVIDEO /SOS
Das deaktiviert den Grafiktreiber und zeigt die Treiber an, so wie sie geladen werden. Vielleicht kann man dann feststellen, welcher Treiber Ärger macht. Den kann man dann in der Registry deaktivieren.
Vermutlich ist es ein Treiberproblem.
Bitte folgende Optionen in der boot.ini aktivieren:
(dafür temporär die vmdk in ein anderen Windows-System einbinden)
/BASEVIDEO /SOS
Das deaktiviert den Grafiktreiber und zeigt die Treiber an, so wie sie geladen werden. Vielleicht kann man dann feststellen, welcher Treiber Ärger macht. Den kann man dann in der Registry deaktivieren.
Hallo und vielen Dank schonmal für die schnelle Antwort
- die vHW ist vers. 7
- auf das Filesystem der vmdk hab ich Zugriff
- der inhalt der boot.ini auf dem gastsystem ist wie folgt:
Gruß und schönes Wochenende

- die vHW ist vers. 7
- auf das Filesystem der vmdk hab ich Zugriff
- der inhalt der boot.ini auf dem gastsystem ist wie folgt:
Code: Alles auswählen
[boot loader]
timeout=5
default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Workstation, Version 4.0"
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Workstation, Version 4.0 [VGA-Modus]" /basevideo /sos
Gruß und schönes Wochenende
leo hat geschrieben:Was passiert, wenn du den 2. Eintrag aus der boot.ini auswählst?
"Windows NT Workstation, Version 4.0 [VGA-Modus]"
Nach Auswahl des VGA-Modus lädt das OS nach und nach Treiber ( http://i.imgur.com/GXW6EsQ.jpg ) und wechselt danach auf die blaue Anzeige aus dem ersten Screenshot. Bis dahin verhält sich die Vm identisch mit den originalen NT4-System auf dem Ursprungsrechner.
-
- King of the Hill
- Beiträge: 13637
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Keine Ahnung ob es damit zusammenhängt, aber der Vollständigkeit halber sei dir gesagt, daß du keine vHW-Version 7 hast.2014-07-25T12:25:37.806+02:00| vmx| I120: DICT virtualHW.version = "6"
Die Einbindung eines Host-Laufwerks ist immer mit zusätzlichen Wartezeiten verbunden und kann unter Umständen auch zu einer unwilligen VM führen.2014-07-25T12:24:29.229+02:00| vmx| I120: DICT ide0:0.present = "TRUE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT ide0:0.autodetect = "FALSE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT ide0:0.filename = "D:"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT ide0:0.deviceType = "atapi-cdrom"
...
2014-07-25T12:25:37.806+02:00| vmx| I120: DICT usb.present = "TRUE"
NT4 mag ja vielleicht noch USB1.1 unterstützen, aber USB2.0 wage ich zu bezweifeln. Ich würde daher den USB-Controller deaktivieren (rauswerfen macht keinen Sinn, da dann wieder unbekannte Voreinstellungen gelten) und dadurch hoffentlich auch die Bluetooth-Meldungen ersparen:
2014-07-25T12:24:31.272+02:00| vmx| I120: USB: Found device [name:Virtual\ Bluetooth\ Adapter vid:0e0f pid:0008 speed:full family:wireless,bluetooth deviceType:virtual-bluetooth version:2]
Er bleibt beim Booten am class2.sys hängen, nachdem er versucht hat, den buslogic-Treiber zu laden.
Setze mal folgende Zeile in die .vmx-Datei der VM:
Setze mal folgende Zeile in die .vmx-Datei der VM:
Code: Alles auswählen
scsi0.virtualDev = "buslogic"
-
- King of the Hill
- Beiträge: 13637
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
@leo
Das ist bereits eingestellt und wurde im Eröffnungspost verlinkten "vmware.log" auch wie folgt gelistet:
Das ist bereits eingestellt und wurde im Eröffnungspost verlinkten "vmware.log" auch wie folgt gelistet:
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT scsi0.present = "TRUE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT scsi0.virtualDev = "buslogic"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT buslogic.noDriver = "FALSE"
leo hat geschrieben:Er bleibt beim Booten am class2.sys hängen
Könnte es an soetwas liegen:
"Der Fehler beim Booten kommt daher, da du versuchst, eine NT-Version für Single-Prozessoren auf einer Multiprozessormaschine laufen zu lassen. Das wird so nicht funktionieren, da es bei den beiden Versionen Unterschiede in der HAL.dll und dem Kernel gibt. Entweder musst du diese gegen die richtigen Austauschen oder neu installieren. "
Grüße
Christoph
-
- King of the Hill
- Beiträge: 13637
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Der Tipp mit dem falschen HAL könnte passen. Die Frage ist jetzt natürlich, über wieviel CPUs das NT4-SP6 vorher geherrscht hatte.
Unabhängig davon ist das die aus dem "vmware.log" kopierte VM-Config:
Keine Ahnung wieviel Plattenplatz ein NT4 mit SP6 braucht, aber bei 256MB konfiguriertem vRAM legt NT4 sicherlich eine mindestens gleichgrosse Auslagerungsdatei an und somit würden nur noch 563MB frei sein.
Unabhängig davon ist das die aus dem "vmware.log" kopierte VM-Config:
Code: Alles auswählen
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT --- CONFIGURATION C:\Users\STSAdmin\Desktop\NT_Rechner\NT2.vmx
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT config.version = "8"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT virtualHW.version = "6"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT memsize = "256"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT MemAllowAutoScaleDown = "FALSE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT MemTrimRate = "30"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT displayName = "NT2"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT guestOS = "winnt"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT annotation = ""
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT floppy0.present = "TRUE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT floppy0.fileName = "A:"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT floppy0.startConnected = "FALSE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT usb.present = "TRUE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT scsi0:0.present = "TRUE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT scsi0:0.fileName = "NT2.vmdk"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT pciBridge0.present = "TRUE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT tools.upgrade.policy = "useGlobal"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT ehci.present = "TRUE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT ide0:0.present = "TRUE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT ide0:0.autodetect = "FALSE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT ide0:0.filename = "D:"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT ide0:0.deviceType = "atapi-cdrom"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT scsi0.present = "TRUE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT scsi0.virtualDev = "buslogic"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT buslogic.noDriver = "FALSE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT extendedConfigFile = "NT2.vmxf"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT virtualHW.productCompatibility = "hosted"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT scsi0:0.mode = "independent-persistent"
Wieviel freien Platz hast du eigentlich noch auf dem NT4-Datenträger von 819MB?2014-07-25T12:24:30.227+02:00| Worker#0| I120: DISKLIB-LINK : Opened 'C:\Users\STSAdmin\Desktop\NT_Rechner\NT2.vmdk' (0xa): monolithicSparse, 1677312 sectors / 819 MB.
Keine Ahnung wieviel Plattenplatz ein NT4 mit SP6 braucht, aber bei 256MB konfiguriertem vRAM legt NT4 sicherlich eine mindestens gleichgrosse Auslagerungsdatei an und somit würden nur noch 563MB frei sein.
Die hal.dll kann man an der Dateigröße feststellen:
halm....dll sind Multiprozessor, ohne m sind es Uniprozessor-Versionen.
Code: Alles auswählen
19.11.99 14:06 52.352 hal.dll
19.11.99 14:06 48.736 hal486c.dll
19.11.99 14:06 66.880 halapic.dll
19.11.99 14:06 46.112 halast.dll
19.11.99 14:06 82.624 halcbus.dll
19.11.99 14:06 80.672 halcbusm.dll
19.11.99 14:06 46.784 halmca.dll
19.11.99 14:06 68.960 halmps.dll
19.11.99 14:06 68.000 halmpsm.dll
19.11.99 14:06 79.424 halncr.dll
19.11.99 14:06 40.224 haloli.dll
19.11.99 14:06 56.960 halsp.dll
19.11.99 14:06 40.736 halwyse7.dll
halm....dll sind Multiprozessor, ohne m sind es Uniprozessor-Versionen.
Wenn man die MPS-HAL auf einer single-CPU-VM fährt, sollte das erscheinen:
https://forums.virtualbox.org/download/file.php?id=7500&sid=5d78127f86a22f9770ba421724dd6d31
https://forums.virtualbox.org/download/file.php?id=7500&sid=5d78127f86a22f9770ba421724dd6d31
Hallo und schonmal vielen Dank für die zahlreichen Antworten.
Sollte sowas nicht auch durch die Einstellungen in der Workstation, bzw. dem Player behoben werden? Die Einstellungen sind bei beiden auf 1 Prozessor, 1 Kern eingestellt. Das Gastsystem ist in der Tat ein alter single-core AMD-Sempron, auf dem Host-System ein i3.
Die Größe der original-NT4-Installation plus die darauf installierte Software beträgt in etwa 210 MB (identisch mit der Größe der vmdk-Datei). In vorherigen Versuchen hab ich auch schon sowohl den Speicher auf 1024 MB als auch den Festplattenplatz auf mehrere GB angehoben, mit dem gleichen "Erfolg".
Wenn man die Anzahl der Prozessoren im Player auf "2" hochstellt bekommt man folgendes log:
https://www.dropbox.com/s/k5wp84k13ewi0e6/vmware3.log
der Fehler, bzw. das Resultat ist identisch mit dem aus dem Ursprungspost.

"Der Fehler beim Booten kommt daher, da du versuchst, eine NT-Version für Single-Prozessoren auf einer Multiprozessormaschine laufen zu lassen. Das wird so nicht funktionieren, da es bei den beiden Versionen Unterschiede in der HAL.dll und dem Kernel gibt. Entweder musst du diese gegen die richtigen Austauschen oder neu installieren. "
Der Tipp mit dem falschen HAL könnte passen. Die Frage ist jetzt natürlich, über wieviel CPUs das NT4-SP6 vorher geherrscht hatte.
Sollte sowas nicht auch durch die Einstellungen in der Workstation, bzw. dem Player behoben werden? Die Einstellungen sind bei beiden auf 1 Prozessor, 1 Kern eingestellt. Das Gastsystem ist in der Tat ein alter single-core AMD-Sempron, auf dem Host-System ein i3.
Wieviel freien Platz hast du eigentlich noch auf dem NT4-Datenträger von 819MB?
Keine Ahnung wieviel Plattenplatz ein NT4 mit SP6 braucht, aber bei 256MB konfiguriertem vRAM legt NT4 sicherlich eine mindestens gleichgrosse Auslagerungsdatei an und somit würden nur noch 563MB frei sein.
Die Größe der original-NT4-Installation plus die darauf installierte Software beträgt in etwa 210 MB (identisch mit der Größe der vmdk-Datei). In vorherigen Versuchen hab ich auch schon sowohl den Speicher auf 1024 MB als auch den Festplattenplatz auf mehrere GB angehoben, mit dem gleichen "Erfolg".
Ah.. also muesste man ueber die Groesse heraus bekommen was es genau fuer eine ist oder halt mal der VM 2 vCPUs geben um zugucken obs wirklich daran liegt.
Wenn man die Anzahl der Prozessoren im Player auf "2" hochstellt bekommt man folgendes log:
https://www.dropbox.com/s/k5wp84k13ewi0e6/vmware3.log
der Fehler, bzw. das Resultat ist identisch mit dem aus dem Ursprungspost.
Zurück zu „VMware Player und VMware Workstation Player“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast