VB VM of WinXP Panic and told to report to support forum

[mdlueck]

Greetings,

For quite some time now always while running the latest VB PUEL on Xubuntu 14.04 x64 (VirtualBox VM 5.1.16 r113841 linux.amd64), my main WinXP x86 VM "gets corrupted". What I mean by that is starting up that particular VM, spikes the WinXP guest OS CPU utilization to 100%, Host OS Disk I/O is steady/constant. Frequently I must push the reset button. Jumping to a terminal (Ctrl-Alt-F1) and trying to login... system so busy I cannot get authenticated before the 60 second timer triggers and starts the login process over.

The only recovery method I know when the VM gets into this state is to roll back to the latest backup of the VM files.

This morning that happened again. However this time it told me to post the log and screen shot of the VM to this support forum. Thus, doing so. Odd... not allowed due to size to upload the produced VBox.png. Please advise how to provide that file. Shows the WinXP desktop. CPU meter on the Object Desktop Control Center is pegged at 100%. As usual, I had JUST logged in.

I am thankful,

[socratis]

not allowed due to size to upload the produced VBox.png. Please advise how to provide that file. Shows the WinXP desktop.

If it shows nothing important, don't worry.

my main WinXP x86 VM

00:00:00.555892 Guest OS type: 'WindowsXP_64'

I believe that you should change the OS type in the VM Settings.

00:00:00.454919 Host RAM: 7918MB (7.7GB) total, 3256MB (3.1GB) available
00:00:00.609603 RamSize   <integer> = 0x00000000c0000000 (3 221 225 472, 3 072 MB, 3 GB)
00:00:00.610048 VRamSize <integer> = 0x0000000001200000 (18 874 368, 18 MB)

3072+18+overhead = really close to 3256. Either close some applications on the host, buy more RAM for the host, or reduce the amount of RAM assigned to the guest. On the same front, I would increase the vRAM to at least 32 or 64 MB or even more if you enable 2D and 3D acceleration in your VM settings. Which you should...

And, since I'm reading the logs sequentially, guess what the next "interesting" piece of information came out of the log?

00:01:56.937241 !!         VCPU0: Guru Meditation -8 (VERR_NO_MEMORY)

That's your VM crashing (Guru meditation) with a pretty straight message. I don't think I need to say anything more...

[mdlueck]

Greetings socratis,

my main WinXP x86 VM

00:00:00.555892 Guest OS type: 'WindowsXP_64'

I believe that you should change the OS type in the VM Settings.

Used to be that I could boot x64 Linux inside a WinXP x86 VM instance. Then suddenly new VM's I would create would fail to boot x64 Linux in a WinXP x86 VM instance. I found the workaround was to flip to declaring WinXP X64, which allows me to dual boot in the VM between x64 Linux and x86 Windows.

I use Linux to image/deploy Windows. Dual boot with Grub as the boot manager.

00:00:00.454919 Host RAM: 7918MB (7.7GB) total, 3256MB (3.1GB) available
00:00:00.609603 RamSize   <integer> = 0x00000000c0000000 (3 221 225 472, 3 072 MB, 3 GB)
00:00:00.610048 VRamSize <integer> = 0x0000000001200000 (18 874 368, 18 MB)

3072+18+overhead = really close to 3256. Either close some applications on the host, buy more RAM for the host, or reduce the amount of RAM assigned to the guest. On the same front, I would increase the vRAM to at least 32 or 64 MB or even more if you enable 2D and 3D acceleration in your VM settings. Which you should...

Noted. Add more RAM to the Host OS... I will look up what the Max RAM is for the Intel motherboard.

I will bump up the VM's vRAM setting.

And, since I'm reading the logs sequentially, guess what the next "interesting" piece of information came out of the log?

00:01:56.937241 !!         VCPU0: Guru Meditation -8 (VERR_NO_MEMORY)

That's your VM crashing (Guru meditation) with a pretty straight message. I don't think I need to say anything more...

So is the crash that the host OS was exhausted of RAM? I was just logging into the VM guest OS, so should have been a very minimal draw... perhaps 768MB at the time.

Since the VM shows 100% CPU utilization, and disk I/O is maxed, I was suspecting something was going wrong inside the VM and not memory exhaustion of the Host OS. So that is a very helpful finding, which I am grateful for.

I am thankful,