Windows 7 64 crash when I move the mouse

[jtberrocal]

Windows 7 64 crash when I move the mouse

Host Windows 10
VirtualBox 5.2.44 - using because have many 32bit machines

Including Vbox.log and vboxhardening.log

[scottgus1]

Host Windows 10
VirtualBox 5.2.44 - using because have many 32bit machines

Virtualbox doesn't run on 32-bit hosts,the physical PC. As I see it you have a 64-bit computer so you can run up-to-date Virtualbox.

Virtualbox still runs 32-bit, 16-bit, maybe even 8 bit OS's. I have DOS VMs on my Windows 10 Virtualbox 6.1.16 host.

The log shows the VM booting from CD-ROM and rebooting after Resets. So far I can't see a 'crash' yet.

Please update Virtualbox to 6.1.18 and try a fresh new VM.

[jtberrocal]

Host Windows 10
VirtualBox 5.2.44 - using because have many 32bit machines

Virtualbox doesn't run on 32-bit hosts,the physical PC. As I see it you have a 64-bit computer so you can run up-to-date Virtualbox.

Virtualbox still runs 32-bit, 16-bit, maybe even 8 bit OS's. I have DOS VMs on my Windows 10 Virtualbox 6.1.16 host.

The log shows the VM booting from CD-ROM and rebooting after Resets. So far I can't see a 'crash' yet.

Please update Virtualbox to 6.1.18 and try a fresh new VM.

You misunderstood me. The 32bit machines are the VM machines. My Windows 10 host is 64 bit. The VM has a DVD Iso with the Windos 7 64 bit upgrade as the VM was a 32bit and I am upgrading it.

I dont want to create new VMs as the ones I have have many configurations and start from scratch is not the best approach for me. That is why I am upgrading the VMs from 32bit to 64bit.

The VM I am currently upgrading is giving me a blue screen crash about an IRQ error but is to fast an have no time to see the specific error.

[mpack]

I think Scott understood you just fine.

This:

VirtualBox 5.2.44 - using because have many 32bit machines

Explicitly states a belief that 5.2.44 is needed to run 32bit VMs. That belief is not correct.

Therefore we'd like to know what prevents you from updating VirtualBox: certainly no discussion of bugs is useful if you have eliminated that option.

[jtberrocal]

I think Scott understood you just fine.

This:

VirtualBox 5.2.44 - using because have many 32bit machines

Explicitly states a belief that 5.2.44 is needed to run 32bit VMs. That belief is not correct.

Therefore we'd like to know what prevents you from updating VirtualBox: certainly no discussion of bugs is useful if you have eliminated that option.

After I upgraded to release 6 all my VMs started to crash on boot, looping in startup. I have Ubuntu, Centos, FreeBSD and Windows VMs, all make the same start boot, crash, restart boot by themselves in a loop. I downgrade to 5.2 then all was Ok.

Now I am upgrading VMs to 64bit before upgrading to VB 6 but on Win 7 upgrade I am getting the crash when I move the mouse over the VM.

Is something about IRQ error but cant see the full error as is to fast and restarts.

[jtberrocal]

Here is a link to a video capture of the VM with error:

http://jetsystripod.com/publicphotos/Or ... -19-33.mp4

[jtberrocal]

I think the Vbox.log of the crash session is lost because when the VM crashes it automatically starts a new session thus the vbox.log with the crash is replaced with the new one.

How can I make VB to stop and not start again in a loop?

[scottgus1]

when the VM crashes

It is important to recognize that there are two things that could crash:

1. The Virtualbox environment that holds the OS may crash. In this case a Virtualbox error message might appear, or the VM will report itself as Aborted in the main Virtualbox window. On rare occasions the Virtualbox environment may just disappear with no warning or message. Logs are written as the events happen. No Virtualbox error that I know of will delete a previously-written log due to a Virtualbox environment crash.

2. The OS in the VM may crash/BSOD/kernel-panic etc. The Virtualbox stays open and the OS will display errors in its screen, not through an extra Virtualbox error message or in the main Virtualbox window. The OS may also reboot if it is programmed to do so, and the Virtualbox environment will note this reboot in the log and keep running the OS and keep logging.

Your posted vbox.log above fits scenario 2. The OS, not Virtualbox, is crashing, or at least resetting.

I think the Vbox.log of the crash session is lost because when the VM crashes it automatically starts a new session

No, it isn't lost. It's the most recent vbox.log still. If you completely stop the Virtualbox environment, this log stays behind and becomes vbox.log.1 when the VM is started again. There are always 4 logs in the folder from the 4 most recent runs of the Virtualbox environment once you've run the VM more than 4 times. Each log carries all the reboots and BSODs of the OS while that Virtualbox environment is running.

How can I make VB the OS in the VM to stop and not start again in a loop?

FTFY. Web-search your OS to see how to stop automatic reboots, if you really need that. But reboots don't kill the logs.

After I upgraded to release 6 all my VMs started to crash on boot, looping in startup. I have Ubuntu, Centos, FreeBSD and Windows VMs,

Windows 10 hosts have some unique issues, but we on the forum might be able to help. It would definitely be a host problem if all the VMs fail. We have a list of suspects, but we need a vbox.log from Virtualbox 6.1.something.

The video doesn't seem to show anything except your main Virtualbox window. A static picture would do as well, but it doesn't help solve the problem unfortunately.

I am upgrading VMs to 64bit

Take backups if anything goes wrong. If you are upgrading the VMs to move up to Virtualbox 6.1.x, you don't need to. I have plenty of 32-bit and 16-bit OS's in my 6.1.16 Windows 10 host. In fact, a major part of the intent of hypervisors like Virtualbox is to run old OS's.

Please upgrade to 6.1.18, and try making a new VM, to see if the install media is good, or to catch host issues. If the new VM has trouble, post the zipped hardening and vbox.logs again.

[jtberrocal]

I upgraded to the newest release for my host, Win 10 64 bit.

Finally manage to get a screen capture of the vm crash.

http://jetsystripod.com/publicphotos/20 ... -47-16.mp4

Included Vbox.log.1 because the VM auto restarts after the crash so the log is renewed