virtualbox.org

Under Oracle VM VirtualBox version 5.0.16 on Win10, I built and have been using a Windows XP virtual machine.

I decided I wanted to add a second display to reflect my physical setup, and used “Settings/Display/Monitor Count” to change the monitor count from 1 to 2.
Now I cannot boot the virtual Windows XP, even after changing the monitor count back to 1.

Windows XP machine shows up as a small window momentarily as it starts to load, then it quickly disappears and I get the message:

Failed to construct 'serial'/0! VERR_IOM_IOPORT_RANGE_CONFLICT (-2602) - The specified I/O port range intruded on an existing range. There is a I/O port conflict between two device, or a device tried to register the same range twice.

Used “Settings/Display/Monitor Count” to change the Monitor Count back to 1, but the startup error/crash continues. Log attached.

I really don’t want to rebuild the entire Windows XP machine again from scratch, because I’ll lose user files I've created within that machine.
I'm thinking there is probably something in the WinXP VirtualBox Machine Definition file that I can change manually to regain access, but it's not apparent what that change would be.

VBox.log wrote: 00:00:01.475420 VRamSize <integer> = 0x0000000000100000 (1 048 576, 1 024 KB)

Eek. I didn't know it was even possible to set graphics RAM this low. Set it to 64MB.

If you have a saved state associated with this VM then discard it (right click, discard saved state).

VBox.log wrote: 00:00:01.422236 Guest OS type: 'Windows7_64'
...
00:00:01.475268 Name <string> = "WinXP" (cb=6)
...
00:00:01.475271 RamSize <integer> = 0x0000000100000000 (4 294 967 296, 4 GB)

If the guest OS is XP 32bit, why on earth did you choose a Win7-64bit template? Also 4GB is probably way more than an XP VM needs. 2GB would be plenty.

mpack, thanks very much for your reply, but I'm really a novice in using virtual machine.

"Discard saved state" is greyed out, so I assume I don't have one saved.

I'm not sure how I managed to get a 64-bit machine with 32-bit WinXP in it.... I remember I started with 64-bit,
then realized my WinXP iso was 32-bit and when I started over I thought I'd corrected that,
and didn't notice it still showed 64-bit; it worked fine for some time before I tried to change the number of displays.

Considering that my goal is to recover/preserve my user files in the virtual machine space (not destroy the virtual space by starting again from scratch),
could you elaborate on how I go about setting the graphics RAM higher?

But, the issue seems to be an "I/O port range conflict", could the too-small graphics ram cause that?
I was trying to add a second display when I caused this problem, then tried to set it back to one display but the problem remained;
I don't want to exacerbate the situation, I can easily start over to build a new virtual machine but I can't easily recreate the user files in the existing virtual machine.

see attachment

I'd think that your error is more likely caused by using the wrong hardware template (i.e. one that XP doesn't support), but that's just a guess.

Nothing I have suggested involves reinstalling the guest or losing files.

Please go into the VM settings and fix the things I mentioned, then we can talk. EXCEPT. If you are saying that XP was installed using the wrong compatibility template then you should probably leave it that way. The other items need to be fixed.

OK, I made that change (video memory), but same result (attached).
I did previously change the graphics ram as you suggested (there was no saved state to delete)
Again I want to stress it was working fine until I changed the number of displays from 1 to 2.

While testing a moment ago, I got an error message indicating that serial ports were all set to the same IRQ, but they are all disconnected.
I tried setting them to different IRQs, but got a boot "Fatal: INT18 failure" when I tried booting (see attached screenshot, but hard to read the INT18 failure msg).

I found a few screenprints from before I changed the number of displays and they do seem to show that the virtual machine was defined as 64-bit.
I agree that probably is the root of the problem, but it WAS working fine before I tried to add a second display...

Is there any way to change that 64-bit setting to 32-bit without destroying the existing virtual machine space (thus destroying user files)?

What if I created a new WinXP 32-bit machine and added the old virtual machine's disk to it.
I realize I'd have to reinstall WinXP and various utility programs to it, but would that new machine
then be able to see user files on the original WinXP 64-bit disk?

I just noticed that your VM's execution cap is set to 1%. Your VM essentially has no CPU to run on.

Well, 1% of an i7 isn't all that bad. I tried changing it to 40%... still has same crash.

wcsbca wrote:What if I created a new WinXP 32-bit machine and added the old virtual machine's disk to it.

You would not likely need to reinstall anything. Scratch this, I didn't read carefully enough. You're thinking of attaching the present disk as a second disk to another guest, sounds like. That would involve a fresh install of the OS and programs, but the data on the second disk could be read and extracted.

Best bet is to make a clone of the disk using Mpack's CloneVDI. Keep the default settings in that tool's window, then when the clone is finished, attach the clone to your new guest. (This way the original guest is unaffected by the test.)

Thanks for the reply, Scottgus1. I probably won't get a chance to try that until tomorrow, but you seem to be confirming what I thought, that the user files may be accessible using that method.
Do you think the original WinXP machine's files would be available to me (like My Documents, etc)? Worth a try.

I'd still prefer to find a way to resurrect my original virtual machine, surely changing the number of displays from 1 to 2 and then back again could not have permanently trashed the WinXP machine.

Simply changing the monitor count should not cause such an error as you posted. Sorry for the seemingly implicational question, but are you really sure that's all you did? The error mentions "serial", any accidental changes to the serial settings? You could try posting the guest's .vbox file, in a zip folder, here on the forum, and we can see if something is wrong with the "recipe".

You could also try making the clone, then attaching the clone to a new XP-32-bit guest as the main drive. Be sure the "IO APOC" setting checkbox on the new guest is the same as the old guest. Other settings should remain defaults, except for the same memory you had before and the recommended 64MB video memory. Since you're working with the clone, the original data should be unaffected. See if it boots.

Scottgus1 said: "You could try posting the guest's .vbox file, in a zip folder, here on the forum, and we can see if something is wrong with the "recipe"."

OK, I stress again that I'm a novice at VirtualBox; I created a virtual WinXP machine a year ago under Win7; I recently installed a Win10 system and tried to install a virtual WinXP machine on it.
I am finding multiple .vbox files on my system, all dated 6/7/2016; there are also two .vbox-extpack files dated 6/8/2016 and 2/9/2015.
Maybe the listing of the files will make more sense to you than it does to me. I know that the day I installed VirtualBox on the Win10 system, I started off incorrectly with a 64-bit machine, then created one that was 32-bit, and that was working, both on 6/7 I believe.
But I've never looked at these .vbox files before, so frankly I'm not certain which of them was working; it worked until 6/10/2016, when I tried changing it by adding the 2nd display
(seems strange that none of the .vbox files have the date of the addition of the 2nd display... I assume that means all changes were part of VirtualBox Manager and not part of the .vbox file itself?).
I am baffled by the vbox-extpack file dated 2/9/2015; perhaps it was carried over from the old Win7 disk when I copied files during my conversion to Win10.

I now also see that you can change the type and version of the machine you are booting with VirtualBox Manager, so I tried changing to Windows XP (32-bit) and
double-clicking, but got the same boot-time result: "Fatal: INT18: Boot Failure"
Maybe you can guide me on what to try next...
if you want to look at a .vbox file, which one would it be?
If the problem is in the VirtualBox Manager, how would I know what settings to alter?

All right, I managed to bring up the virtual machine the way it was, though I don't really understand how that worked...

I added a second 32-bit virtual machine and chose "Use an existing hard disk file" and chose the only file in the list: WinXP.vdi (normal, 10.00 GB).
I fully expected to have to install a new WinXP from a WinXP ISO; instead, WinXP came up exactly as it was before I had the problem, with my user files
and installed programs intact. And, the "bad" WinXP (the one that's been crashing) is still in VirtualBox Manager.

Phew!!!!

But, now I'm back to my original issue: how do I add a second display?
And, do I dare delete the WinXP definition that's been failing?

Hey, it booted up! Nice! It does seem to me that you are using the old XP virtual disk in the new XP guest, and the guest is running fine. That would indicate to me that the definition file for the failed guest was itself bad, not anything with the virtual disk.

Why did it happen? It's just a computer thing. Occasionally errors happen. But I don't think it's common. You may just want to run a disk check on your host disk one day.

The files with ".vbox" extensions are the guest definition files. The files with ".vbox-prev" extensions are backups of the .vbox files Virtualbox makes when an edit to the .vbox file is required. The files with ".vbox-extpack" are the extension packs for Virtualbox itself and are not guest definition files.

You should shut down the guest and back it up before anything else goes wrong. Normally this involves just copying the guest's folder, which appears to be stored in the path "C:\Users\Me\Virtualbox VMs" according to the screenshot in your previous post. However, since you have a drive for one guest attached to another guest, it's a bit more complicated. To get a properly-situated guest that's a breeze to back up, you will have to remove the drive from Virtualbox completely without deleting it, then place it in the folder for the new guest, then re-attach it to your good guest. Once this is done, future backups and restores will be very easy.

After you get the backup, then we can try adding the second monitor. If it goes south again, I'd say something is wrong with your Virtualbox setup and a complete uninstall/reinstall would be in order.

Here's what you need to do to prepare for the back up. Shut down the guest, then carefully follow these steps in order:

1. Open the Virtual Media Manager in the Main Virtualbox GUI window's File menu.

2. Click on the disk file "WinXP.vdi" in the Hard Disks list. In the lower section of the Manager there will be a "Location" line giving the path to the vdi file. Take note of this location, you'll need it for step 3 and 7.

3. Go to that folder and copy (not move) the vdi to another place on the computer, especially a good external drive if you have one. You will have two vdi's, one in the original place and one in the new place. Best practice now is to use the command 'FC' (for "File Compare") in a command prompt window to confirm the copy's integrity.

4. Very likely, in the path "C:\Users\Me\Virtualbox VMs" you will find a folder called "WinXP Rescue". This folder contains the .vbox recipe file for the new guest. Copy the entire "WinXP Rescue" folder and all contents therein to the backup location you copied "WinXP.vdi" to.

5. Go back to the Media Manager. Right-click "WinXP.vdi" in the Hard Disks list and choose "Release". Click the Release button in the pop-up.

6. Be careful on this step: Right-click "WinXP.vdi" in the media list again, and choose "Remove". Click the Remove button in the pop-up. Another pop-up will appear - this is the very dangerous one. Click "Keep". DO NOT click "Delete". If you click Delete your vdi will immediately be deleted, no Recycle Bin, no recovery at all. You will need to restore that backup copy of the vdi if you click Delete.

7. Close the Virtual Media Manager. Now the vdi file is completely out of Virtualbox. Find the original "WinXP.vdi" in the original folder from step 2, and move it this time to the folder "C:\Users\Me\Virtualbox VMs\WinXP Rescue". This is a move, not a copy, so the move will be relatively instant.

8. In the main Virtualbox window, open the "WinXP Rescue" guest's settings, Storage Section. Click the IDE controller, then add a new disk. Choose Existing Disk and navigate to the "C:\Users\Me\Virtualbox VMs\WinXP Rescue" folder. "WinXP.vdi" will be there, choose it. Close the guest's settings window. Now your guest will be properly configured for easy backup.

9. Close the main Virtualbox window. Open the "C:\Users\Me\Virtualbox VMs\WinXP Rescue" folder. Copy the .vbox file (with the blue cube icon) to the "WinXP Rescue" folder in the backup location you made your copies in. You will be asked if you want to overwrite the existing .vbox file in the backup location. Choose Yes and overwrite it.

10. In the backup location, move the "WinXP.vdi" file into the "WinXP Rescue" folder in the backup location. Now your backup location is properly configured to restore.

You should now be able to start and use your "WinXP Rescue" guest.

In the future, the backup process is extremely easy. You just copy the entire "C:\Users\Me\Virtualbox VMs\WinXP Rescue" folder to the desired backup location. All the required files including the disk file will be copied. Restoring is simply copying back and overwriting the originals. FC can be used to confirm the copies.

After all this you can try the second monitor. If the guest dies now, you can simply close Virtualbox completely, then copy the .vbox file from the backup to the "C:\Users\Me\Virtualbox VMs\WinXP Rescue" folder.

You may also delete the original bad guest form Virtualbox now if you want. Right-click the bad guest, click Remove, then in the popup click Remove Only. The guest's definition files and logs will remain on your disk, but they only take up a megabyte or two at most and can be disregarded. (These files may become necessary for troubleshooting purposes if your second attempt at the second monitor also goes bad, so I'd say to hold onto them for a while.)

Let us know how things go!