VM mit Windows 10 startet nicht nach kopieren

[Conolus]

Hallo liebes Forum,

ich hab bereits gesucht aber nichts gefunden was mir geholfen hätte.
Mein Problem: Ich habe eine VM mit Windows 10 aufgesetzt und diese VM als Basis für diverse andere VMs verwendet. Da mein Rechner nicht unendlich viel Speicher hat, habe ich vorzu die fertigen VMs auf einen Server kopiert (ohne vbox-Tools, einfach über den Explorer > kopieren) und die jeweilige VM danach aus dem vbox-Manager gelöscht (Option "nur löschen"). Soweit so gut. Jetzt bin ich mit allen VMs fertig und wollte mir eine dieser erstellten VMs wieder auf meinen Rechner ziehen und ausführen. Dazu habe ich den ganzen Ordner wieder vom Server kopiert und im vbox-Manager hinzugefügt (über Maschine > Hinzufügen). Sobald ich jetzt die VM starten will, kommt der Bootscreen mit dem blauen Windowslogo und damit hat es sich dann aber auch schon. Booten tut da irgendwie gar nichts mehr. Auch der typische drehende Kreis kommt nicht, einfach nur das blaue Logo, sonst nichts. Auch eine Fehlermeldung wird nicht angezeigt. Im Log habe ich auch keine weiteren Hinweise gefunden - wovon ich da ganz klar zu wenig durchblicke. Die Basis-VM die immer noch auf meinem Rechner ist funktioniert nach wie vor.
Habt ihr eine Idee an was das liegen kann?

Verwendete VirtualBox: v7.0.6
Host-System: Windows 10 Pro, x64

[mpack]

Your procedure sounds fine to me: it should work.

My only question is, you say that you created a backup by copying "the VM" to your server. Can you clarify what you mean by "the VM". If you copied the entire VM folder then you should have no problem. If you only copied the VDI and had to reconstruct the VM then these problems are not unusual.

Also, what condition was the VM in while it was copied? Copying a VM that is in a "saved state" condition can cause problems, especially if VirtualBox is updated on the host in the interval before the VM is restored.

Also, please provide a VM log file for one of the restored VM execution attempts. Make sure the VM is fully shut down following the attempt, then right click it in the manager UI. Select "Show Log" and save "VBox.log" (no other file) to a zip file. Attach the zip here.

[scottgus1]

In addition to Mpack's thoughts above, here's what I found:

It appears to me that the VM started from a cold boot, not saved state.

The log shows that the VM OS did a BSOD:

00:00:13.694994 GIMHv: BugCheck 1e {ffffffffc0000096, fffff803321b38e0, 0, 0}

A quick web-search shows this to be a KMODE_EXCEPTION_NOT_HANDLED "bugcheck". There's a possibility that the host might have RAM being touched by the VM which has a problem. Run a memory check test on the host.

If the VM was working before you copied it, but is not working after you copied it, then the copy is corrupted, which can happen. An "FC" file compare is a good idea after a copy to confirm that the copy is identical to the original.

Your server copy could still be good. Try copying the files again. No need to delete and re-register the VM from Virtualbox. When the copy from the server is complete, run a file compare on the .vbox file and the .vdi file. If these file compares come back "no differences", then try the VM. If the VM does not BSOD, then you're good. If the VM does a BSOD again, then the server copy is corrupted.

[Conolus]

Your procedure sounds fine to me: it should work.

My only question is, you say that you created a backup by copying "the VM" to your server. Can you clarify what you mean by "the VM". If you copied the entire VM folder then you should have no problem. If you only copied the VDI and had to reconstruct the VM then these problems are not unusual.

Also, what condition was the VM in while it was copied? Copying a VM that is in a "saved state" condition can cause problems, especially if VirtualBox is updated on the host in the interval before the VM is restored.

Also, please provide a VM log file for one of the restored VM execution attempts. Make sure the VM is fully shut down following the attempt, then right click it in the manager UI. Select "Show Log" and save "VBox.log" (no other file) to a zip file. Attach the zip here.

I copied the entire folder, not just a single file. What do you mean by "saved state"? I shut down the VM before and only then copied it.
I now have another new insight: my statement before was wrong that my "base VM" still works. It does not work anymore either. I have now copied two VMs from my server to another computer > they both start and have no problems. So it must be a problem with my computer. I have attached the logfile again.

In addition to Mpack's thoughts above, here's what I found:

It appears to me that the VM started from a cold boot, not saved state.

The log shows that the VM OS did a BSOD:

00:00:13.694994 GIMHv: BugCheck 1e {ffffffffc0000096, fffff803321b38e0, 0, 0}

A quick web-search shows this to be a KMODE_EXCEPTION_NOT_HANDLED "bugcheck". There's a possibility that the host might have RAM being touched by the VM which has a problem. Run a memory check test on the host.

If the VM was working before you copied it, but is not working after you copied it, then the copy is corrupted, which can happen. An "FC" file compare is a good idea after a copy to confirm that the copy is identical to the original.

Your server copy could still be good. Try copying the files again. No need to delete and re-register the VM from Virtualbox. When the copy from the server is complete, run a file compare on the .vbox file and the .vdi file. If these file compares come back "no differences", then try the VM. If the VM does not BSOD, then you're good. If the VM does a BSOD again, then the server copy is corrupted.

I recopied the VM from the server and run a file compare with "fc /b FileA FileB". Both files (.vbox and .vdi) are identical. But if the copy on the server is corrupt, it wouldn't run on another computer, would it? This is a mystery to me. I'll try setting up a new VM from scratch to see if it still works. I can't do that until after my vacation though....

Edit: I also performed a memory test with "mdsched" without finding an error.