Windows 10 (Oktober Update) - stürzt in VM ab

[EWeiss]

Zitat:

Ich teile Deine Kritik zu Windows 10 voll (ohne jetzt hier wieder eine Diskussion zu Windows 10 anstoßen zu wollen - Bitte nicht !!).

Ok!

Wollte es nur mitteilen..
Siehe mein letzter Edit Win10 ist nicht registriert. (Scheint behoben trotzdem extrem ärgerlich)
Hmm... Hatte das Problem aber auch mit Win7 System angeblich nicht registriert.. (geht aber wieder)

Sorry das ich abgeschweift bin.
Thema ist erledigt keine Beschwerden mehr

gruss

[Assarbad]

Wenn Windows erst einmal läuft, versuche doch mal folgendes:

• In der Windows 10 VM aktiviere in den Computereigenschaften die Erzeugung eines (vollen) Speicherabbilds ("memory dump")
• Extrahiere den Dump nach dem nächsten Absturz (wird erst nach dem Neustart erzeugt, also bitte nicht VM ausschalten und VM-Disk mounten und wundern, daß kein Abbild da ist ...)
• Dann besorg die das neueste Windows SDK (das ist das 1809er) und installiere die Debugger daraus auf deinem Hostsystem
• Lade den Dump aus der VM auf dem Hostsystem in WinDbg und laß "!analyze -v" laufen ...
• Poste die Ausgabe hier oder schicke sie als PN

Sollte kein Dump erzeugt werden (der wird übrigens nur erzeugt wenn pagefile.sys auf dem selben Laufwerk liegt wie %SystemRoot% und solange das System die Größe der pagefile.sys verwaltet), haste ein Problem. Dann bliebe dir immernoch die Möglichkeit mal mit Memtest86 zu booten und es über die Nacht durchlaufen zu lassen. Es ist denkbar, daß die VM auf (physische) Speicherbereiche zugreift, die dein Hostsystem eher selten anfaßt.

Weiterhin würde ich sicherstellen die neueste Version des Hypervisors zu benutzen und für meine CPU(s) die Microcode-Updates einzuspielen (könnte ein BIOS/UEFI-Update sein, aber inzwischen liefert MS die wohl je nach Windowsversion auch mit aus).

[EWeiss]

Zitat:

•Dann besorg die das neueste Windows SDK (das ist das 1809er)

Und fehlerhaft.. musste da nochmal drauf hinweisen denn das ist das Oktober Update.

gruss

[GPRSNerd]

Warum arbeitest du noch mit VB-Branch 5.1 und nicht mit 5.2?

Seit heute gibt es VirtualBox 5.2.22 (released November 09 2018).
Da scheint ein Bugfix drin zu sein für aktuelle Windows 10 Hosts:
Windows hosts: fixed an incompatibility with recent versions of Windows 10 (bug #17977)

Vielleicht wäre das ein Versuch wert...

[Aviator]

Ich würde, wie GPRSNerd geschrieben hat, auch mal auf die neueste Version updaten wenn sogar ein Bugfix existiert. Ich selbst arbeite nur mit VMWare. Dort gibt es aber die VMTools. Die wird es in VB wohl auch geben. Von daher solltest du mal schauen, ob da eine neue Version vorliegt.


Das Problem mit der Windows Aktivierung hatte ich gestern auch. Mein Rechner meldete plötzlich, dass Windows nicht aktiviert sei.

Ein Versuch Windows zu aktivieren schlug fehl. Die Problembehandlung meldete auch bei mir, dass ich einen Key für Windows 10 Home eingegeben hätte. Heute hat die Aktivierung wieder problemlos funktioniert.

[Assarbad]

Und nach dem Hinweis von GPRSNerd würde ich auch nochmals empfehlen die aktuellste Version des Hypervisors zu installieren. Ich habe VirtualBox nur mal testweise benutzt und folge daher dessen Entwicklungen nicht. Aber hier scheinen sich einige damit auszukennen, hör auf sie!

Zitat von EWeiss:

Zitat:

•Dann besorg die das neueste Windows SDK (das ist das 1809er)

Und fehlerhaft.. musste da nochmal drauf hinweisen denn das ist das Oktober Update.

@EWeiss: Den Unterschied zwischen dem SDK und dem OS wirst du noch kennen, oder? ... wenn nicht, kann ich gern nochmal detailliert darauf eingehen. Nur vorweg, das SDK enthält kaum Dateien die sich auf den Installationsmedien finden. Könnte ne heiße Spur sein.

[Harry Stahl]

Zitat von GPRSNerd:

Warum arbeitest du noch mit VB-Branch 5.1 und nicht mit 5.2?

Seit heute gibt es VirtualBox 5.2.22 (released November 09 2018).
Da scheint ein Bugfix drin zu sein für aktuelle Windows 10 Hosts:
Windows hosts: fixed an incompatibility with recent versions of Windows 10 (bug #17977)

Vielleicht wäre das ein Versuch wert...

Wie gesagt, beim Übergang von 5.1 auf 5.2 auf einer anderen Maschine (allerdings war dort der Host Windows) gab es Probleme.

Die gab es aber jetzt bei Linux erfreulicherweise nicht.

Habe den Übergang gewagt (nachdem zuvor ein großes Backup von so ziemlich allem erstellt wurde).

Und: Mit Version 5.2.2. scheint es wieder zu gehen, arbeite jetzt schon ca. 2 Stunden ohne crash (sonst war es spätestens nach 10 Minuten passiert).

[jaenicke]

Zitat von Harry Stahl:

Auch wenn meine Entwicklungsdaten außerhalb der VM liegen, habe ich jetzt wenig Lust die Komponenten und Einstellungen der letzten 3 Monate wieder manuell anzupassen.

Wir hatten zwar bisher mit Windows 10 keine nennenswerten Probleme, aber um Problemen durch defekte Rechner oder Betriebssysteme zu begegnen gehen wir einen anderen Weg:
Es gibt ein einziges Buildskript, das alle Komponenten usw. kompiliert, installiert und die Einstellungen in Delphi und den CnWizards setzt. Dadurch ist die komplette Einrichtung der Entwicklungsumgebung inkl. Installation in einer halben Stunde locker gemacht (ich habe nicht auf die Uhr gesehen).

Das sind so im Grunde nur 3-4 Schritte: Delphi installieren, JEDIs installieren, ggf. Repository auschecken, Installationsskript starten...
Und schon kann man ganz normal weiter arbeiten, auch auf einem neuen Rechner.

Das ist für uns der deutlich sinnvollere Weg als in einer VM zu arbeiten. Bei anderen Umgebungen mag das natürlich anders aussehen.

[Harry Stahl]

Hört sich interessant an. Wie darf man sich denn das mit dem Skript vorstellen?

Batch-Datei, extra Programm oder wie wird so ein Skript erstellt, das gleich auf einmal alles erledigt?

Vor allem mit den Komponenten, wie soll das per scipt gehen?

[jaenicke]

Es gibt dafür verschiedene Möglichkeiten. In dem JEDI Installer sind entsprechende Units vorhanden, mit denen man auch viel prüfen kann usw., aber das braucht man eigentlich nur, wenn man eine komplett unbekannte Entwicklungsumgebung bestücken möchte.

Wir machen es aber ganz einfach. Denn jeder hat ja die gleichen Pakete usw., so dass wir genau wissen was installiert sein soll. Und die Pfade sind auch vorgegeben. Daher habe ich das bei mir zuerst ein einziges Mal manuell installiert und dann schlicht aus der Registry die verschiedenen Teile rausgeholt. Das ist dann eine Handvoll .reg Dateien für die Einstellungen, Pfade, CnWizards-Einstellungen, registrierten Design-Packages für die IDE, ... (alles einzeln, damit man es leichter anpassen kann)

Das Installationsskript importiert nun mit der reg.exe von Windows (damit braucht man keine Adminrechte und es geht silent) die Registrydaten, kompiliert dann mit msbuild die Packages (auch z.B. Overbyte ICS usw.). Wir haben viel auch in wenige Packages zusammengefasst, aber man kann die natürlich auch alle einzeln lassen. Mit dem ErrorLevel kann man den Erfolg ja auch prüfen, wenn man möchte.

Jedenfalls reicht das dann bereits. Denn über die .reg Dateien sind die .bpl Packages registriert für die IDE und damit muss man die nicht mehr manuell installieren. Und durch das Kompilieren mit msbuild liegen sie ja an der richtigen Stelle.

Die Ausgabepfade der Packages muss man natürlich ggf. anpassen. Wir lassen alle Units in ein bestimmtes Verzeichnis (mit Unterverzeichnissen für Buildkonfiguration und Plattformen) ausgeben und brauchen so auch nur diesen Pfad im Bibliothekspfad.

Das ist natürlich ein gewisser Anfangsaufwand, aber dafür hat man später deutlich weniger Aufwand. Und man kann das beim Umstieg auf andere Delphiversionen ja auch leicht anpassen, das ist normalerweise mit einer Änderung der Versionsnummer in den Skripten und .reg Dateien getan.

Der wichtigste Vorteil in einem Team ist aber vor allem, dass alle ganz einfach in der gleichen Umgebung arbeiten. Oder auch, wenn man selbst an Laptop, PC zu Hause und im Büro arbeitet usw.
Und es ist eben deutlich einfacher auf eine neue Delphiversion zu wechseln.