Blue screen after restore
Blue screen after restore
My Windows 10 guest is hosted on Linux. Using VirtualBox 6.1.34. I have been backing up my 'VirtualBox Vms' direcitory weekly to a tarfile, and verifying that tarfile.
I attempted to restore the tarfile to the 'VirtualBox VMs' directory (after deleting all files in that directory first). When I launched the VM, I get only a blue screen. No messages, nothing. I've done such restores numerous times in the past on different Linux hosts and don't recall this ever happening. Is there anything I can do, or am I just out of luck?
I attempted to restore the tarfile to the 'VirtualBox VMs' directory (after deleting all files in that directory first). When I launched the VM, I get only a blue screen. No messages, nothing. I've done such restores numerous times in the past on different Linux hosts and don't recall this ever happening. Is there anything I can do, or am I just out of luck?
-
- Site Moderator
- Posts: 20945
- Joined: 30. Dec 2009, 20:14
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Windows, Linux
Re: Blue screen after restore
If the blue screen is a BSOD inside the VM, this means the VM 'hardware' is probably running well but the OS inside the VM has issues. You could troubleshoot the BSOD inside the VM using Windows' usual web-searchable methods.MarkFoley wrote:When I launched the VM, I get only a blue screen.
To check the VM hardware, Start the VM from full normal shutdown, not save-state. Run until you see the problem happen, then shut down the VM from within the VM's OS if possible. If not possible, close the Virtualbox window for the VM with the Power Off option set.
Right-click the VM in the main Virtualbox window's VM list, choose Show Log. Save the far left tab's log, zip it, and post the zip file, using the forum's Upload Attachment tab.
Re: Blue screen after restore
Before I upload the log, I want to make sure ... This isn't a BSOD, it's just a plain blue screen. No text, no prompts, no messages. I am starting from a full shutdown. I cannot shut down from within the VM as nothing is responsive. I can shut down (power off) from the VBox Manager. Will the the log thus generated be useful?
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: Blue screen after restore
Please provide the (zipped) log, it will definitely answer questions that you can't.
Re: Blue screen after restore
Log attached. Thanks.
- Attachments
-
- VBoxlog.zip
- blue screen
- (32.91 KiB) Downloaded 9 times
-
- Site Moderator
- Posts: 20945
- Joined: 30. Dec 2009, 20:14
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Windows, Linux
Re: Blue screen after restore
This VM is booting from a CD-ROM in the host CD drive:
(One other thing, which may or may not be pertinent, and may not be causing problems if this VM has worked before: The VM has 8 processors in it, and there's 8 physical cores on the host. Virtualbox will start 8 separate VM threads to handle these 8 processors, which could swamp your host if the VM OS asked it to. Additionally, due to extra scheduling oversight, the host runs the VM slower the more processors the VM has. Multi-processor-aware 3rd-party software in the VM would be a good reason to have so many cores, but a basic OS with nothing extra will not benefit from the extra processors and will run slower. Modern Windows loves 2 processors.)
Is this by intent? The VM hardware never rolls over to boot from the hard disk.00:00:02.459861 [/Devices/ahci/0/LUN#1/AttachedDriver/] (level 5)
00:00:02.459863 Driver <string> = "HostDVD" (cb=8)
.....
00:00:07.709540 VMMDev: Guest Log: BIOS: Booting from CD-ROM...
(One other thing, which may or may not be pertinent, and may not be causing problems if this VM has worked before: The VM has 8 processors in it, and there's 8 physical cores on the host. Virtualbox will start 8 separate VM threads to handle these 8 processors, which could swamp your host if the VM OS asked it to. Additionally, due to extra scheduling oversight, the host runs the VM slower the more processors the VM has. Multi-processor-aware 3rd-party software in the VM would be a good reason to have so many cores, but a basic OS with nothing extra will not benefit from the extra processors and will run slower. Modern Windows loves 2 processors.)
-
- Volunteer
- Posts: 5677
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: Blue screen after restore
No, it does. Whenever you see the "BIOS: Booting from CD-ROM..." log message as the last boot device selection message, check the VM Statistics under "/Public/Storage" to see what really happened.scottgus1 wrote:The VM hardware never rolls over to boot from the hard disk.
-
- Site Moderator
- Posts: 20945
- Joined: 30. Dec 2009, 20:14
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Windows, Linux
Re: Blue screen after restore
Intéressant!
As to why it happened, I'd say it wasn't a Virtualbox glitch. Probably the tarballing got glitched, or the restore. Silly question, I know, but do you ensure that the VMs are fully shut down before backing up?
Very useful, fth0! Thanks!fth0 wrote:check the VM Statistics under "/Public/Storage"
So we do have a read from the VM's 'hard disk', a megabyte and a third, and a few kB read. Not much. Gonna guess this is a hosed VM OS. I'd try booting the VM with Windows 10 (or is it 7? "WIN10VM/WIN7VM.vdi") install media and run a repair install.00:00:02.459837 [/Devices/ahci/0/LUN#0/Config/] (level 5)
00:00:02.459839 Format <string> = "VDI" (cb=4)
00:00:02.459841 Mountable <integer> = 0x0000000000000000 (0)
00:00:02.459842 Path <string> = "/home/mfoley/VirtualBox VMs/WIN10VM/WIN7VM.vdi" (cb=47)
00:00:02.459843 Type <string> = "HardDisk" (cb=9)
.....
00:00:38.670672 /Public/Storage/AHCI0/Port0/BytesRead 1397760 bytes
00:00:38.670675 /Public/Storage/AHCI0/Port0/BytesWritten 16384 bytes
As to why it happened, I'd say it wasn't a Virtualbox glitch. Probably the tarballing got glitched, or the restore. Silly question, I know, but do you ensure that the VMs are fully shut down before backing up?
Re: Blue screen after restore
The tarfile backups are around 23G, and the VDI file is 133G, so I don't get why it craps out after reading a mere meg+.scottgus1 wrote: So we do have a read from the VM's 'hard disk', a megabyte and a third, and a few kB read. Not much. Gonna guess this is a hosed VM OS. I'd try booting the VM with Windows 10 (or is it 7? "WIN10VM/WIN7VM.vdi") install media and run a repair install.
Yes, it is Windows 10. It was originally a Windows 7 system that was upgraded. I don't really know how to change the .vdi name. I didn't try to simply rename the file and properly renaming is probably documented, but I never bothered.
I booted the VM from a Windows 10 installation DVD and did a "Troubleshooting" repair, which took several hours. However, when it finished and booted to the supposedly repaired VM I still got the blue screen
I cron backup the WIN10VM directory to tarfile weekly. Usually, I manually shut down before the backup, but if it's still running the backup script does a savestate. After the backup it does a 'tar -tf' to verify the tarfile.As to why it happened, I'd say it wasn't a Virtualbox glitch. Probably the tarballing got glitched, or the restore. Silly question, I know, but do you ensure that the VMs are fully shut down before backing up?
Not sure what to try next. I have 3 backups (3 weeks), all of them hosed. I've been using Vbox for several years, and done restored like this multiple times, but I've never had this happen before. I could install Windows from scratch, but would lose much.
Would the post-repair VM log be useful? I just clobbered it trying something else, but I could re-do the repair and get the log.
-
- Site Moderator
- Posts: 20945
- Joined: 30. Dec 2009, 20:14
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Windows, Linux
Re: Blue screen after restore
There's no need to, I was just curious if the VM got misconfigured.MarkFoley wrote: I don't really know how to change the .vdi name
That's a bummer. It would be interesting to see if the data inside the VM is still readable. Try attaching the disk to another VM, see if you can get at the data inside.MarkFoley wrote:I booted the VM from a Windows 10 installation DVD and did a "Troubleshooting" repair
FWIW backing up save-stated VMs ties the VM to the Virtualbox version that was running the VM at the time. Saved states can't survive Virtualbox version changes. This VM wasn't save-stated, was it?MarkFoley wrote:Usually, I manually shut down before the backup, but if it's still running the backup script does a savestate.
You could try troubleshooting inside the VM OS using Microsoft methods to see what's happening, same as what might be done if this happened on a real PC. The post-repair log might help, but we'll need a forum guru to interpret it if there's more than the usual working-VM-bad-OS logging.
Re: Blue screen after restore
I can do that as I still have the saved tarfiles. How do I do that? From a running VM, how do I attach another VDI file? I'll definitely try this on one of my blue-screen VMs.scottgus1 wrote:MarkFoley wrote:That's a bummer. It would be interesting to see if the data inside the VM is still readable. Try attaching the disk to another VM, see if you can get at the data inside.MarkFoley wrote:I booted the VM from a Windows 10 installation DVD and did a "Troubleshooting" repair
Wow! I didn't know that. 3 of the 4 images I tried to restore were save-stated, but the 4th one, the only one that wasn't blue-screening, was save-stated. Even so, the last time I upgraded VBox was in May version 6.1.34), and all the saved images were July and August. So, the save-stated backup should have still been the same VBox version. However, as an additional desperate hope, I did upgrade VBox to 6.1.36 4 days ago to see if that might help. It did not, but the save-stated version did fire up as previously described (no CMD Admin mode, etc.). I was able to copy some of my important app installation files off that to a shared network drive.FWIW backing up save-stated VMs ties the VM to the Virtualbox version that was running the VM at the time. Saved states can't survive Virtualbox version changes. This VM wasn't save-stated, was it?MarkFoley wrote:Usually, I manually shut down before the backup, but if it's still running the backup script does a savestate.
Yes, I did this with assistance from https://answers.microsoft.com/en-us/windows/forum. I was directed to https://docs.microsoft.com/en-US/troubl ... rtup-issue, but after running the chkdsk in the Troubleshooting command prompt (which took hours and found several thousand of "Deleted Corrupted Attribute List Entry", "Deleting Orphan File Record Segment", "Deleting an Index Entry", "Inserting data attribute into file", and possibly others). In the end, it was unable to repair. I tried this on several of the backups.You could try troubleshooting inside the VM OS using Microsoft methods to see what's happening, same as what might be done if this happened on a real PC. The post-repair log might help, but we'll need a forum guru to interpret it if there's more than the usual working-VM-bad-OS logging.
So, I gave up and re-installed Windows 10 from the installation DVD.
Nevertheless, I am concerned as to how this happened and how all 4 of my weekly tarfile backups were unable to start up. This makes me anxious for the future. I verify all backups after creating them. If the host crashes (rare) I boot to DVD and run fsck. If the Windows VM crashes (more frequently and usually a result of the KDE desktop crashing) I've run chkdsk /f /r on the boot drive to repair any problem. I can't figure out any way that all 4 VM backups would be un-usable. This despite my continued use of the VM since the oldest backup on 17 Jul 2022. It was running after that date, and I've shutdown and restarted multiple time since then, but the backup from that and more recent dates don't run (other than the save-state version which was quite corrupted). As mentioned, I've used VBox on multiple computers including Mac since 2016, or earlier, and have done this tar-restore many times w/o problem.
I think I'll add another image backup app like Acronis. I think I need "belt and suspenders" given that the suspenders broke!
Let me know about attaching a VDI image and I'll check out your suggestion.
Re: Blue screen after restore
As mentioned, I ended up reinstalling Windows 10 from DVD and fortunately had all the app installation DVDs or programs available. I also added an Acronis image backup to the restored computer which will give me another backup from which to restore the entire computer. I backup the VM weekly and Acronis backup monthly.
My last post asked about accessing the .vdi image. There are miscellaneous files on the trashed VM: images, docs, etc. I did find a way to mount a .vdi image, which is great! This uses qemu which can be downloaded from your distro's repository. For example, Slackware: 'sqg -p qemu;sbopkg -i qemu'; Ubuntu: 'apt-get install qemu-utils'. Then:
The VM image that was the topic of this post had too many corrupted files/directories to use, but I had older backups that worked just fine. I generally found the Windows 10 VMs in /dev/nbd0p2 or ...p3, and my Windows 7 VM in /dev/dbd0p1.
When finished with the image, do:
The following method also works if doing this on a machine with Virtual Box installed:
When finished:
My last post asked about accessing the .vdi image. There are miscellaneous files on the trashed VM: images, docs, etc. I did find a way to mount a .vdi image, which is great! This uses qemu which can be downloaded from your distro's repository. For example, Slackware: 'sqg -p qemu;sbopkg -i qemu'; Ubuntu: 'apt-get install qemu-utils'. Then:
Code: Select all
modprobe nbd
qemu-nbd -c /dev/nbd0 WIN10.vdi
fdisk -l /dev/nbd0 # to see the partitions
mount /dev/nbd0p1 /mnt/tmp # or /dev/nbd0p2
# All the VM files are now available in /mnt/tmp
When finished with the image, do:
Code: Select all
umount /mnt/tmp
qemu-nbd -d /dev/nbd0
modprobe -r nbd
Code: Select all
$ vboximg-mount --list
-----------------------------------------------------------------
VM: WIN10VM
UUID: 3ed2c35b-c329-4e0a-b595-dd346a3cc1c9
Image: WIN10VM.vdi
UUID: 414d6f67-4eac-40a5-9931-978a9becdd39
$ vboximg-mount -i 414d6f67-4eac-40a5-9931-978a9becdd39 -o allow_root joe
$ ls -l joe
total 58006964
lr--r--r-- 1 root root 0 Sep 21 12:48 WIN10VM.vdi -> /home/mfoley/VirtualBox\ VMs/WIN10VM/WIN10VM.vdi
-rw-r--r-- 1 65534 65534 107374182400 Sep 21 12:58 vhdd
-rw-rw-rw- 1 root root 607125504 Dec 31 1969 vol0
-rw-rw-rw- 1 root root 106764959744 Dec 31 1969 vol1
$ sudo mount joe/vol1 /mnt/tmp
Code: Select all
umount /mnt/tmp
umount joe
-
- Site Moderator
- Posts: 20945
- Joined: 30. Dec 2009, 20:14
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Windows, Linux
Re: Blue screen after restore
Looks like we lost track of this topic, sorry!
I'd say for now try not using the tar system and do straight file copy and file compare.
That's a puzzle. I do backups with straight no-zip file copy, so a file compare can check the integrity, and because disk space is decently cheap.MarkFoley wrote:I am concerned as to how this happened and how all 4 of my weekly tarfile backups were unable to start up. This makes me anxious for the future.
I'd say for now try not using the tar system and do straight file copy and file compare.
In another VM's Storage settings, click the disk controller, then Add Hard Disk. Then in the mini Media Manager, select the first bad VM's disk. (I'm not in front of a Virtualbox host just now, so the terminology might be fuzzy.) Note that the other VM's OS has to be able to understand the attached disk's file system.scottgus1 wrote:Try attaching the disk to another VM