VM with W10x64 crashes HOST VBoxDDR0.r0

[KONNEX]

Hi.
I'm developing a heavy customized windows 10 version for a customer with scripts.
After running the scripts sometimes the VM crashes with the screenshot attached and sometimes it gives my host sytem a blue screen!
The scripts trigger a normal reboot and than sometimes the error message comes up or VBoxDDR0.r0 crashes my host system. In general I can reproduce the failure like in 80% of the restarts.
The VM does NOT crash after my host is restarted and the VM gets started. I also seems not to crash if I shutdown the VM instead of restart.

In short: VM restart will trigger BSOD or shown Guru Meditation.

I never thought a VM could cause a bluescreen on the host. The BSOD says somthing with: VBoxDDR0.r0
No Minidump enabled on the host, but now i will turn it on.

Maybe someone has an idea what causes the bsod?

Logs and the pic in the attachment.

02-05-_2020_19-42-14.png (43.58 KiB) Viewed 1153 times

[scottgus1]

Your client's guest's guru meditated over VERR_PGM_HANDLER_NOT_FOUND, which happens sometimes when a guest starts from a saved state.

And this guest started from a saved state:

00:00:02.433974 Console: Machine state changed to 'Restoring'

'Restoring' says 'Starting' when the guest starts from full shut-down.

There are occasions when a host environment changes enough that a saved state can no longer be restored to what the host can provide. There were errors like these before the guru meditated:

00:06:28.285122 AssertLogRel F:\tinderbox\win-rel\src\VBox\Devices\Graphics\DevVGA.cpp(5648) int __cdecl vgaR3PciIORegionVRamMapUnmap(struct PDMDEVINSR3 *,struct PDMPCIDEV *,unsigned int,unsigned __int64,unsigned __int64,enum PCIADDRESSSPACE): RT_SUCCESS_NP(rc)
00:06:28.285149 VERR_PGM_HANDLER_PHYSICAL_CONFLICT (-1603) - Attempt to register an access handler for a physical range of which a part was already handled.
.....
00:06:31.838190 AssertLogRel F:\tinderbox\win-rel\src\VBox\Devices\Graphics\DevVGA.cpp(5648) int __cdecl vgaR3PciIORegionVRamMapUnmap(struct PDMDEVINSR3 *,struct PDMPCIDEV *,unsigned int,unsigned __int64,unsigned __int64,enum PCIADDRESSSPACE): RT_SUCCESS_NP(rc)
00:06:31.838214 VERR_PGM_HANDLER_PHYSICAL_CONFLICT (-1603) - Attempt to register an access handler for a physical range of which a part was already handled.

The errors appear to be related to guest video memory.

Try a full reboot of the host, then try to start the guest. If that doesn't work, right-click the guest in the main Virtualbox window's guest list and choose Discard Saved State. All of the data that was unsaved to the guest's disk before the guest was save-stated will be lost, unfortunately. In the future, try to fully shut down the guest instead of save-stating it.

[KONNEX]

Hm if I understand you right, you say/think I'm starting from a saved state (like in the middle of a session?) this is not the case.

The Base of my VM working is to have 2 snapshots (in Power Off state).
Snapshot1: Clean (empty)
----> Snapshot 2: Installed (just Windows) [Power off]

I'm running the instance, do some heavy modding with restart in the end.
--> this restart causes DDR0 or the Continue / Ignore Window.

Nothing like restore within a Session.

I have a write-through Disk (vmdk) attached to the VM (this is why I normaly capture in Power-Off state) but this Disk isn't used while the whole modding.

As you think this could relate to some video memory, might it help to update video drivers (intel igpu)?

[scottgus1]

you say/think I'm starting from a saved state (like in the middle of a session?) this is not the case.

The log says it is:

00:00:02.433974 Console: Machine state changed to 'Restoring'

FWIW the log says the guest only has one CPU in it. The host has two physical cores, so the typical forum advice to leave one core for the host is being followed, good. However, Windows 10 really needs two cores to work nicely. Either the host is too under-powered, or you might take a calculated risk and add the second core to the gust. The guest doesn't really "take" the cores, it just shares them with the host. If the guest goes 100% on both cores the host might starve, or at least get sluggish for a bit. Maybe not. I have a two-core-hyperthreaded host like you have and I run two-core guests on it successfully.

I do not know if the snapshot and write-through disks have anything to do with the problem, nor what "heavy modding" is involved. If that means PEEKs and POKEs then who knows what might happen? I would recommend, if you would cry enough to water the Sahara if the guest died because the data inside was irreplaceable, then don't use snapshots. Use an unsnapshotted guest, and take copies of the guest folder and all guest drive files while the guest is fully shut down, not save-stated. The forums are replete with weeping users who did something wrong with a snapshot.

One interesting possibility:

VBoxDDR0.r0 crashes my host system

I don't know for certain what VBoxDDR0.r0 does exactly (I'm a fellow user) but the DDR strikes me as possibly related to memory, and the guest log does report memory issues (the guest video memory is really another chunk of regular host RAM, not from the host video card). Try a memory test on the host? (No guest running, reboot the host to the memory tester environment, let it run repeatedly overnight.)

[KONNEX]

Hey let me claify a few things.

1) Thanks for you help! I really appreciate it.
2) I'm not crying nor whining.
3) I never said anything about important data. The VM is designed to check on things and throw it away afterwards. (therefore the "clean" state)

I'm using the VM for developing the heavy modding stuff. - But this should just involve Windows stuff and should not effect the VM (from my POV). It's about disabling Services, Scheduled Task, Injecting Polcies and so several stuff more. In the Stage Silent installation (like a few months ago) there was never a BSOD. Only since I'm working on the "lockdown" features. I only changed the settings by adding sound to the config.

I would exclude a ram issues as only VB crashed the system while rebooting after the modding. It crashed shortly after the bootlogo. I also utilize a bunch of ram from day to day and failing ram would show more issues than in this very specific situation.
I updated the Intel Driver and will change from 1 to 2 CPU. It's just a duo-core 6600U.
I will clear all snapshots, change to 2 CPU, remove sound again. If this helps I know it had something to do with one of this components.

thanks so far

[scottgus1]

2) I'm not crying nor whining.

Oh no, we're on the same page, I didn't think you were.

When we get some poor folks who report a snapshot chain three miles long and all their deceased relatives' pictures are in the guest and they deleted one of those backup snapshots they took four years ago and now the guest won't start and can anybody get Daddy's pictures off this dead guest, and all we can say is restore from a backup, and they go "I don't have one!!!!" One can feel the tears oozing through the screen... because snapshots ain't backups and make a guest delicate. Thus the concern that if the data were important, don't let it rest on a snapshot. But if one knows how to use snapshots properly, like you do, then they can be used well.

Myself, I only have what the log says. Others might know better exactly what the errors mean. FWIW virtual machines of any hypervisor push the host into areas of its memory that it might not normally touch. So a bad bit in the higher GB might cause a guest to go bad and a host BSOD, when the host by itself might never touch the higher GB and be OK otherwise.

a few months ago) there was never a BSOD

Has anything changed since a few months ago?

[KONNEX]

Ah, no problem.
I may got it a little the wrong way. I currently kinda feel the time pressure. :/

Yeah, I only use Snapshots while running for very certain tasks. It also doesn't work well with the write-through HDD if this gets mounted externaly and so on.. but there is a workaround for that. I'm drifting, back to topic.

With RAM, as you said might be possible but I cant test it right away. But I will keep it in mind.
Currently I'm not working in the VM but the one session with updated intel graphics driver, 2 core, no audio did not crash the system nor did I got the Guru Message.
I will see within the next week if something helped.

[fth0]

00:00:03.131161 AIOMgr: Endpoint for file 'D:\Workspace\VM\Work\1809 LTSC Getinge\1809 LTSC.vhd' (flags 000c0781) created successfully
00:00:03.132961 AIOMgr: Endpoint for file 'D:\Workspace\VM\Work\1809 LTSC Getinge\Snapshots/{c26372cb-58cb-44fd-bbc2-08d306c9a5f4}.vhd' (flags 000c0781) created successfully
00:00:03.134217 AIOMgr: Endpoint for file 'D:\Workspace\VM\Work\1809 LTSC Getinge\Snapshots/{8a01d8f5-75d7-4854-8b67-036c0c81168c}.vhd' (flags 000c0781) created successfully
00:00:03.135879 AIOMgr: Endpoint for file 'D:\Workspace\VM\Work\1809 LTSC Getinge\Snapshots/{4afc7b15-87f0-41d2-a78d-0d70030ba705}.vhd' (flags 000c0781) created successfully
00:00:03.137885 AIOMgr: Endpoint for file 'D:\Workspace\VM\Work\1809 LTSC Getinge\Snapshots\{9cdd7aeb-7810-4e24-a261-b265f2aab48a}.vhd' (flags 000c0723) created successfully

Regarding the saved state: I guess that your latest Snapshot ({9cdd...}.vhd) contains a saved state. For example, if you created this snapshot by pausing the VM, creating the snapshot and powering off the VM, you've also created a saved state. Independent of how you managed to create the saved state: start the VM, shut down the guest OS itself, and then create a new snapshot from within the VirtualBox Manager. Start your experiments from this new shapshot, and the crashes shouldn't occur any more.