When Virtual machine restarts sometimes goes to different OS then crashes

[fth0]

you'll never get that green-bars bootloader screen in Win10

Ok. I cannot prove otherwise at the moment. And even YouTube is on your side , showing only Netbooks (with 1024x600 resolution) booting Windows 7 with the Windows Vista boot screen, but not Windows 8/8.1/10. So let's ignore my theory for the time being.

Regarding the provided BCD store content, I see 5 alternatives for starting:

1. The virtual hard disk has another partition that is started from, and the BCD store isn't used at all.

2. Windows 10 {current} is started as usual.

3. The Windows Recovery Environment {13fd2ad5-9140-11e9-8be2-c80d3c9ea0fc} is started. Note that it is not on a separate partition in this installation.

4. The Windows Resume Application {fcb798d0-7448-11e9-9700-f719bc7c16a6} is started (from hibernation).

5. The Windows Memory Diagnostic {memdiag} is started.

One could try and find out how the last three alternatives look like ...

... I've already tried numbers 3 and 5 -> no Windows Vista boot screen

[fth0]

@TheawesomeMCB:

Some further ideas to differentiate between the possible starting modes:

Please start the Windows 10 VM (from the saved state, as usual). Inside the guest OS, start a cmd shell with admin rights, enter the command "bcdedit /set {bootmgr} displaybootmenu yes". This enforces the Windows 10 Boot Manager to be displayed (on a normal working start). Open the Windows 10 Disk Management and post a screenshot of it, so we can see the partitions of the virtual disk. Disable hibernation in the energy settings. Restart the guest OS as usual. Does the Boot Manager show up before the crash?

[TheawesomeMCB]

Did that bcdedit and it accecpted it (bcdedit didn't work in command shell but command prompt seemed to have worked)

Disk management:

bootmgr.PNG (26.6 KiB) Viewed 5345 times

After restart:

booting.PNG (10.43 KiB) Viewed 5345 times

After pressing enter at that screen:

booting2.PNG (4.65 KiB) Viewed 5345 times

Then it crashes

[socratis]

There's something wrong with that booloader. That's definitely not a Win10 bootloader screen.

I would just delete that VM and install a fresh one. You could have done it thrice already in the time that this discussion is going on...

[TheawesomeMCB]

So I just created a fresh VM and did the same thing to see if reinstalling a fresh windows 10 VM (You can see it's a totally different name and new drive)

And I created a snapshot, restored the snapshot, restarted the VM and the VM crashed again...

same error.PNG (37.18 KiB) Viewed 5327 times

[socratis]

VBox.log? For the new VM, ZIPPED...

BTW, please don't go Full-Screen mode from the beginning of the life of the VM. And if you do, crop the image, just like you did in your previous ones. I'm not particularly fond of lots of grey areas, that make it difficult to focus on the important features of the screenshot...

[TheawesomeMCB]

My apologizes! I was showing the whole screen so you saw in the taskbar title that it was a different VM

Here's the log:

[socratis]

My apologizes! I was showing the whole screen so you saw in the taskbar title that it was a different VM

If you weren't in Full-Screen mode, then yes, you could have done that.

BTW, I don't want to see all of your logs. When I'm asking for a log, I don't want to see random logs, from random runs, with random settings. I want to see "The" log where/when the problem occurs.

00:00:02.642612 Console: Machine state changed to 'Restoring'
00:00:58.535142 !!         VCPU1: Guru Meditation -1607 (VERR_PGM_HANDLER_NOT_FOUND)

It's an error that becomes more and more prominent; restoring from a saved-state causes the PGM_HANDLER error. Just like your previous VM, exactly.

[fth0]

It's an error that becomes more and more prominent; restoring from a saved-state causes the PGM_HANDLER error. Just like your previous VM, exactly.

And just like the case of vbpaul (viewtopic.php?f=6&t=94912#p458635).

@socratis
I've reviewed the log files again and compared them to the cases of vbpaul (and others). Some of my findings:

1. The host OS is Windows 10 1903 (or older); the guest OS is Windows 10 1903 (or older, Windows 8.1, Linux). The VM is configured with VBoxSVGA (or VMSVGA), but with 3D and 2D acceleration both disabled. While running, the VM windows are maximized:
   

   Code: Select all

   00:00:02.954496 [/Devices/vga/0/Config/] (level 4)
   00:00:02.954497   3DEnabled        <integer> = 0x0000000000000000 (0)
   00:00:02.954502   VMSVGA3dEnabled  <integer> = 0x0000000000000000 (0)
   00:00:02.954503   VMSVGAEnabled    <integer> = 0x0000000000000001 (1)
   [...]
   00:00:10.689077 GUI: 2D video acceleration is disabled
   

2. The saved state is created either by an online snapshot or by closing the VM into saved state, so this may be irrelevant.
3. Restarting from saved state seems to work without problems. But right after reaching the running state, there are some VMMDev Guest Log messages indicating Session 0 is about to close. This may be either an precondition of the later crash (destroying physical memory that will later be assumed to still exist), or some delayed messages from before the saved state (note the high time stamps inside the messages), or something totally different, I'm not sure about that:
   

   Code: Select all

   00:00:10.109267 Changing the VM state from 'RESUMING' to 'RUNNING'
   [...]
   00:00:10.222550 VMMDev: Guest Log: 04:19:47.209500 control  Session 0 is about to close ...
   00:00:10.222845 VMMDev: Guest Log: 04:19:47.209500 control  Stopping all guest processes ...
   00:00:10.222881 VMMDev: Guest Log: 04:19:47.209500 control  Closing all guest files ...
   [...]
   00:00:10.238496 VMMDev: Guest Log: Got multi resize request 1 displays
   00:00:10.238555 VMMDev: Guest Log: [0]: 0 0x39 0,0 1920x975 0
   00:00:10.356629 VMMDev: Guest Log: VBoxTray: (WDDM) invalid bpp 0, using 32bpp instead
   00:00:10.359849 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000ea90000 w=1920 h=965 bpp=32 cbLine=0x1E00 flags=0x1 origin=0,0
   00:00:10.359915 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000ea90000 w=1920 h=975 bpp=32 cbLine=0x1E00 flags=0x1 origin=0,0
   

4. Restarting from within the VM (even after many hours in the vbpaul case), when booting from hard disk, the VM resolution changes to 640x480 instead of the expected 1024x768 (I'm still searching for a way to reproduce this detail to see the Windows Vista boot screen myself ):
   

   Code: Select all

   00:00:45.812688 VMMDev: Guest Log: BIOS: Booting from Hard Disk...
   00:00:48.087958 GIM: HyperV: Guest OS reported ID 0x1040a0000271b
   00:00:48.087980 GIM: HyperV: Open-source=false Vendor=0x1 OS=0x4 (Windows NT or derivative) Major=10 Minor=0 ServicePack=0 Build=10011
   00:00:48.088002 GIM: HyperV: Enabled hypercall page at 0x00000000001c9000
   00:00:48.088419 GIM: HyperV: Queried extended hypercall capabilities 0x1 at 0x0000000000007000
   00:00:48.088444 GIM: HyperV: Enabled TSC page at 0x000000000000c000 - u64TscScale=0xb60b5d00000000 u64TscKHz=0x36ee81 (3 600 001) Seq=1
   00:00:48.088517 TM: Switching TSC mode from 'VirtTscEmulated' to 'RealTscOffset'
   00:00:48.088597 GIM0: HyperV: Enabled APIC-assist page at 0x000000000000d000
   00:00:48.324483 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000ea90000 w=640 h=480 bpp=0 cbLine=0x140 flags=0x0 origin=0,0
   00:00:48.895272 GIM1: HyperV: Enabled APIC-assist page at 0x000000003ffff000
   

   The expected resolution change from a previous start of the same VM, which exhibits a different timing:
   

   Code: Select all

   00:38:16.616996 VMMDev: Guest Log: BIOS: Booting from Hard Disk...
   00:38:17.098335 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000ce50000 w=1024 h=768 bpp=24 cbLine=0xC00 flags=0x0 origin=0,0
   00:38:22.108107 GIM: HyperV: Guest OS reported ID 0x1040a0000271b
   00:38:22.108128 GIM: HyperV: Open-source=false Vendor=0x1 OS=0x4 (Windows NT or derivative) Major=10 Minor=0 ServicePack=0 Build=10011
   00:38:22.108158 GIM: HyperV: Enabled hypercall page at 0x000000000020e000
   00:38:22.108663 GIM: HyperV: Queried extended hypercall capabilities 0x1 at 0x0000000000007000
   00:38:22.108703 GIM: HyperV: Enabled TSC page at 0x000000000000c000 - u64TscScale=0xb60b5d00000000 u64TscKHz=0x36ee81 (3 600 001) Seq=1
   00:38:22.108742 TM: Switching TSC mode from 'VirtTscEmulated' to 'RealTscOffset'
   00:38:22.108838 GIM0: HyperV: Enabled APIC-assist page at 0x000000000000d000
   00:38:22.553307 GIM1: HyperV: Enabled APIC-assist page at 0x000000003ffff000
   

   There are at least three log messages (between each last boot and crash), indicating that the expected OS version build is booting:
   

   Code: Select all

   00:00:51.869179 VMMDev: Guest Log: VBoxGuest: Windows version 10.0, build 18362
   [...]
   00:00:51.898197 VMMDev: Guest Additions information report: Interface = 0x00010004 osType = 0x0003B100 (Windows 10, 64-bit)
   [...]
   00:00:54.052292 VMMDev: Guest Log: VBoxMP::DriverEntry: OsVersion(10, 0, 18362)
   

5. The crash happens during the execution of the VBoxMP::DxgkDdiStartDevice method (part of the VBox WDDM Miniport driver), between two of its usual log messages (code block 1: crash, code block 2: previous start):
   

   Code: Select all

   00:00:58.533819 VMMDev: Guest Log: VBoxMP::vboxWddmPickResources: found the VBE card
   00:00:58.533940 VMMDev: Guest Log: VBoxMP::DxgkDdiStartDevice: Handling complex topologies enabled
   00:00:58.534785 Changing the VM state from 'RUNNING' to 'GURU_MEDITATION'
   00:00:58.534797 Console: Machine state changed to 'GuruMeditation'
   00:00:58.535141 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   00:00:58.535142 !!
   00:00:58.535142 !!         VCPU1: Guru Meditation -1607 (VERR_PGM_HANDLER_NOT_FOUND)
   

   Code: Select all

   00:38:52.497273 VMMDev: Guest Log: VBoxMP::vboxWddmPickResources: found the VBE card
   00:38:52.497408 VMMDev: Guest Log: VBoxMP::DxgkDdiStartDevice: Handling complex topologies enabled
   00:38:52.499852 VMMDev: Guest Log: VBoxMP::DxgkDdiStartDevice: using HGSMI
   00:38:52.500265 VMMDev: Guest Log: VBoxMP::vboxWddmVModesAdd: WARNING! :resolution 1280x1024 not accepted by the frontend
   00:38:52.500426 VMMDev: Guest Log: VBoxMP::vboxWddmVModesAdd: WARNING! :resolution 1400x1050 not accepted by the frontend
   00:38:52.500577 VMMDev: Guest Log: VBoxMP::vboxWddmVModesAdd: WARNING! :resolution 1600x1200 not accepted by the frontend
   00:38:52.500707 VMMDev: Guest Log: VBoxMP::vboxWddmVModesAdd: WARNING! :resolution 1920x1440 not accepted by the frontend
   00:38:52.500878 VMMDev: Guest Log: VBoxMP::voxWddmVModesInitForTarget: WARNING! :vps(0x57)!=NO_ERROR
   00:38:52.500962 VMMDev: Guest Log: VBoxMP::voxWddmVModesInitForTarget: WARNING! :vps(0x57)!=NO_ERROR
   00:38:52.501139 VMMDev: Guest Log: VBoxMP::DxgkDdiStartDevice: WDDM: VRAM 0xe0000000/0x8000000, FIFO 0xfde00000/0x200000, IO 0xfff0/0x10
   

   From the source code In this area, I would expect physical memory to be allocated. The VERR_PGM_HANDLER_NOT_FOUND error indicates that some physical memory is either deregistered or modified instead.

PS: While I understand your general sentiment of getting multiple log files, in this case I'm happy to have got at least two of them, because the oldest one documents the whole history of this VM.

[TheawesomeMCB]

It's an error that becomes more and more prominent; restoring from a saved-state causes the PGM_HANDLER error. Just like your previous VM, exactly.

So what do we do now?

[fth0]

If you're so kind, you could try and help finding out if the 3D Acceleration, the 2D Video Acceleration and/or the maximized VM window are necessary to reproduce the problem. For example, try the following experiments with your new VM (the first one is a pre-test):

(1) Start the VM from the saved state, shut the guest down, take a snapshot, start the VM up again, close it into a new saved state, start it up again, then restart the guest. Does the crash still happen? If yes, try (1a), else try (1b).

(1a) Revert the VM to the snapshot created in (1), enable 3D/2D acceleration in the VM settings, start the VM, un-maximize the VM window and restart the guest. Does the crash still happen? If no, try other combinations of these three changes to isolate the ones necessary for the crash to occur.

(1b) Start the VM from the saved state, un-maximize the VM window, then restart the guest. Does the crash still happen?

PS: Because there is the workaround of Discard Saved State, I wouldn't count on a high interest from the developers. So it could take several days (or even weeks) until a detailed investigation will take place.

[caspertone]

I have same behaviour as described by OP.
Same boot screen...
Those are VMs fully installed from original OS W10 1903. No multipartition. No upgrade.
See viewtopic.php?f=2&t=95107&p=460050#p460050
See https://www.virtualbox.org/ticket/19007
See viewtopic.php?f=6&t=94912&p=461946#p461946

Time to join all threads and take seriously the bug?

[TheawesomeMCB]

(1) Start the VM from the saved state, shut the guest down, take a snapshot, start the VM up again, close it into a new saved state, start it up again, then restart the guest. Does the crash still happen? If yes, try (1a), else try (1b).

(1a) Revert the VM to the snapshot created in (1), enable 3D/2D acceleration in the VM settings, start the VM, un-maximize the VM window and restart the guest. Does the crash still happen? If no, try other combinations of these three changes to isolate the ones necessary for the crash to occur.

(1b) Start the VM from the saved state, un-maximize the VM window, then restart the guest. Does the crash still happen?

1. 1b
1b. Yes

[fth0]

@TheawesomeMCB: Thanks for helping. I have no further questions at the moment.

Time to join all threads and take seriously the bug?

No, yes. Joining the 5 to 10 threads would render them un-readable IMHO, because some of them are rather long already. And I've read that the VirtualBox developers have started looking into the problem, so the first hurdle is taken. Now it's time to wait patiently ...

[caspertone]

Thanks.
Time for patience.