virtualbox.org

I got a new SSD for my laptop. I copied my VMs to my new Windows 10 installation on this device.

I believe the guest OS is Windows 10 version 1909 as was the host on the installation on the old SSD. Currently running Version 1909 (OS Build 18363.836).

I was running VirtualBox-6.1.4-136177 before and on the new install until I tried updating to VirtualBox-6.1.8-137981 to fix the issue with no luck.

The machine is slow, has wierd graphics flickering issues, and gets BSOD saying IRQL NOT LESS OR EQUAL.

I never had any issues with the old SSD, I never got BSOD until I ran it off the new SSD.

operation420.net wrote:I got a new SSD for my laptop. I copied my VMs to my new Windows 10 installation on this device.

How did you do this? There's a right way and many wrong ways...

operation420.net wrote:running VirtualBox-6.1.4-136177 before and on the new install until I tried updating to VirtualBox-6.1.8-137981 to fix the issue with no luck.

This implies to me that the old 6.1.4 version on the new OS installed on the new SSD also had the guest BSODing, and you tried to update Virtualbox to 6.1.8 to see if the problem would go away, right?

Start the guest from full power off, not save-state. Run until you see the problem happen, then shut down the guest from within the guest OS if possible. If not possible, close the Virtualbox window for the guest with the Power Off option set.

Please right-click the guest in the main Virtualbox window's guest list, choose Show Log. Save the far left tab's log, zip the log file, and post the zip file, using the forum's Upload Attachment tab.

Also, please relate what exact steps you took to copy the guest over.

Was the old SSD having any issues?

I copied the files from drive F:\ (USB to M.2 SATA Encloure) to drive C:\ under the %HOMEPATH%\VirtualBox VMs folder.

I also copied the %HOMEPATH%\.VirtualBox folder. All my VMs show up fine. I am able to launch the VM as I was before, minus the BSOD.

Yes, I initially installed the same version as before. After getting BSODs I installed the latest version as of then. Since then I added a new VirtualDisk.vdi file and installed Windows 10 on that with the other vdi as a USB device to access my data from it. Would this have messed up the logs? Do the logs contain sensitive information that I should remove before making public? (Username, host machine name, virtual machine name)

I never got a BSOD since using a the new VDI Virtual Disk file, but it's still slow. Before the performance was great.

Checking the disk for errors using the tool in Tools on the tab on the properties for drive C:\ and using the chkdsk C:\ command says the drive has no errors.

I have a dual core (4 thread) CPU and 8GB of RAM and the VM was 2GB allocated.

Running the VM off the old SSD works OK, so does running a new Windows 10 VM I made to test Win10-v2004. Also, they are running at the same time!!!

Also, is the appropriate section for this here under Windows Guests or should it be on Windows hosts (or elsewhere?)?

The method of copying looks good. %HOMEPATH%\VirtualBox VMs is the default folder for guests, though they can go elsewhere, and the guest folders with the .vbox files and all items therein are the things to copy.

operation420.net wrote: After getting BSODs I installed the latest version as of then. Since then I added a new VirtualDisk.vdi file and installed Windows 10 on that with the other vdi as a USB device to access my data from it. Would this have messed up the logs?

No, a log is just the activity of the operation of a guest. I don't know how this change affected the original guest, but disk can be attached to multiple guests, just that most of the time only one guest with such a multiattached disk can run at a time.

operation420.net wrote:Do the logs contain sensitive information that I should remove before making public? (Username, host machine name, virtual machine name)

Username, host machine name, virtual machine name are not hackable items. I'll give you a for instance: My computer name is CoerI5, my username is SnC, and my guest name is Shopbot v4. Now, hack me.... First thing you'd need to know is where on the web I am, and without my IP address you wouldn't know. So the only thing that would be hackable in the log is if you had your host PC attached directly to the internet instead of through a router, and the public IP address were posted in the log. If you are behind a router and have a 192.168 or 10. or 172.16 IP address on your host, then there's nothing dangerous in the log.

Please find the log file attached

The usual mistake when copying VMs is not actually copying the VM, instead only copying the VDI and then creating a new VM around it. AFAIK that's the only way to get this kind of driver fault.

VBox.log file wrote:00:00:04.423364 Log opened 2020-05-28T02:05:28.847325000Z
00:00:08.996031 VMMDev: Guest Log: BIOS: Booting from CD-ROM...
00:22:41.450241 Changing the VM state from 'RUNNING' to 'RESETTING'
00:22:44.533821 VMMDev: Guest Log: BIOS: Booting from CD-ROM...
00:31:05.649360 Changing the VM state from 'RUNNING' to 'RESETTING'
00:31:08.781365 VMMDev: Guest Log: BIOS: Booting from CD-ROM...
01:32:48.159514 Changing the VM state from 'RUNNING' to 'RESETTING'
01:32:51.492969 VMMDev: Guest Log: BIOS: Booting from CD-ROM...

The VM booted from the ISO file each time, and never from any of the two virtual hard disks.

I can't think why the CD boot would be affected by being moved to another host drive, so we have incomplete or incorrect info.

I copied the entire VM (and all my other VMs in the default VirtualBox Machines folder under %HOMEPATH% / %USERPROFILES%, and the .VirtualBox folder), not copied the VDI and created a new machine.

I got into the Windows install on the VDI, but it chain booted (I am running headless and using RDP, when it was booting it must have booted the DVD, said press anykey to boot, timed out and continued to chain boot the VDI).

In the VBox.log file, I cannot see any indication of an error between each boot starting from the ISO file and the following reset initiated by the guest OS, the latter being typical after a Windows BSOD. In consequence, you should IMHO analyze the BSOD as if it occurred on a bare metal PC.

Yes, perhaps you are right, fth0 (Like eth0 with an f instead of an e?).

I was suggested to run WinDbg or BlueScreenView https://www.nirsoft.net/utils/blue_screen_view.html

Currently I have the VM running off the old SSD. I'll have to shut it down, remove it and add the one on the HDD and run it with and without the ISO mounted and compare the results and see if there's something at the guest-OS level vs the host OS level to help diagnose...

I want to copy the new VM to the SSD since it's updated since the copy but that might not produce accurate results...

So I did some debugging since my last post.

I switched back to and ran the VM off the old SSD (in a M.2 SATA to USB enclosure) for a while because I needed a production instance of this VM. I took some downtime and removed the old SSD instance from Vbox, and added the new SSD instance back.

Upon boot I got weird GFX issues again and right before I went to copy over the Nirsoft program I got a BSOD. I restarted and was able to copy over and run Nirsoft's tool and exported a text file.

I'm also having issues with Linux on this machine/SSD as well. I never ran Linux on here before because I didn't have the space for it, but now that I have this new SSD I am trying to install Linux have been unable to do so. Need to look into that further and see if it's somehow related (hardware issue, but host works fine) or another issue...

FWIW if you FC the copy of the old guest files and the new SSD copy, and the FC returns 'no differences', then the fact that it's a copy can be ruled out.

operation420.net wrote:Upon boot I got weird GFX issues again and right before I went to copy over the Nirsoft program I
got a BSOD

Does this quote relate to this:

operation420.net wrote:I switched back to and ran the VM off the old SSD

or this:

operation420.net wrote:removed the old SSD instance from Vbox, and added the new SSD instance back.

If there's just a few bits of changed data that you can copy off, so that you can dump the copied guest, then make a new copy, and FC the copy to be sure it copied well?

What do you mean by FC?

What I was saying was I removed the new crashing VM from Vbox, added the instance from the old SSD and was able to continue using it.

I went back by removing the working instance from the old SSD and added the new instance I previously copied over (the process above in reverse)...