Windows Guest has refused to boot up

[baffourt]

I was in the middle of something on the guest when it froze and restarted by itself. I decided to restart it together with the host os.
Now it has refused to start up altogether. It keeps giving me a blue screen then change to black screen and back again. I thought maybe the vdi file was corrupted so I mounted it to a new machine but it produces same result.
log attached as well as the screen shot that flickers to black and back again

[granada29]

Try turning off 3D acceleration in your Display settings and also use the VBoxSVGA controller.

If this works, then re-enable 3D and see what happens.

Also - you are a couple of releases behind - the current version is VirtualBox-7.0.14

Try the current version (unless there is some reason you are unable to).

[baffourt]

Still same results, I received few alerts of Volume mismatch on the host when it was running some weeks ago but I had not come around to do a clean install of the Mac Os Ventura. Do you think it may be what has affected the .vdi file. I even copied the .vdi file to a different machine, set up virtualbox, mounted it and still gives same results. What next steps can I take?

[granada29]

Please post a log with your new configuration.

[baffourt]

New Attachement done, how can I run chkdsk on it, so as to correct the vdi file if there are some bad segments on it?

[granada29]

As far as I can see your VM settings are OK, although the Guest Additions should be updated once you get to a usable windows GUI.

My knowledge of Windows startup/recovery is not very extensive. If you make 3 aborted starts then the next attempt should kick you into advanced recovery. i.e Start your VM then as soon as you see the boot begin, power off/close the VM window. Do this 3 times.

You'll need to follow your nose (i.e. the on screen prompts) to make your way through the recovery screens and then run chkdsk on your virtual disk.

Someone else who knows more about windows may wish to chip in here.

[multiOS]

The VM's vdi file appears to be stored in an unconventional location:

00:00:00.935077 File system of '/Users/[username]/Documents/NewDev.vdi' is apfs

If the Document folder is subject to 'live' backups, i.e. Time Machine or similar, then I would consider it to be at high risk of interference and potential corruption when in operation, as a native Mac backup system cannot possibly understand what may be taking place with the content inside an active 'multi-GB file' that is primarily controlled by a secondary Operating System (Windows) and its installed software, which the backup system cannot monitor/control/understand.