VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (1783 - 1785 of 16363)

Ticket Resolution Summary Owner Reporter
#9404 obsolete BSOD happen Virtual Box 4.1 on Windows 7 host installed Eset sakamori
Description

I installed Virtual Box 4.1 on windows 7, it worked fine. Then, installing ESET Smart Security onto windows7, BSOD was happened. So I disabled all Virtual Box drivers in safe mode and Restarted. then, BSOD was not happened. Uninstalling Virtual Box 4.1 and reboot Windows, BSOD was not happened. I guess installing both of ESET and Virtual Box 4.1 causes BSOD.

#9406 obsolete Networking - Host-Only settings ignored after upgrade Ion
Description

Custom settings for the Host-Only adapter are not retained after an upgrade; the files "VirtualBox.xml" and VirtualBox.xml-prev" contain the right info :

<ExtraDataItem name="HostOnly/VirtualBox Host-Only Ethernet Adapter/IPAddress" value="198.51.100.1"/>
<ExtraDataItem name="HostOnly/VirtualBox Host-Only Ethernet Adapter/IPNetMask" value="255.255.255.240"/>

... but applied seetings are the default ones :

Carte Ethernet VirtualBox Host-Only Network :

   Suffixe DNS propre à la connexion. . . :
   Adresse IPv6 de liaison locale. . : fe80::bcef:ff6a:cd5f:f9b%43
   Adresse IPv4. . . . . . . . . . . : 192.168.56.1
   Masque de sous-réseau. . . . . . . . . : 255.255.255.0
   Passerelle par défaut. . . . . . . . . :

Just upgraded from 4.0.12 to 4.1 to confirm the bug is still present.

#9410 obsolete Strange VDI Corruption Incident Justin Gottula
Description

I was running a Windows 7 32-bit guest on Windows 7 64-bit host today and happened to be pausing/resuming with some regularity (trying to balance CPU time between a pair of running VMs by pausing the one I didn't need running at the moment). At one particular moment on one particular boot, and, according to the log, just as I told the VM to pause for a moment, I got a 'VDI: invalid header in <the vdi file the VM booted from>' error message, which I simply ignored at first. However, attempts to continue execution of the VM were unsuccessful, so I reset it, after which every attempt to boot resulted in the same error:

Power up failed (vrc=VINF_SUCCESS, rc=E_FAIL (0X80004005))

Also, the virtual disk showed up with a warning icon throughout the VirtualBox GUI. So, I concluded that the VDI file had become corrupted somehow. Being a curious person, I popped open my hex editor and compared this VDI file with the VDI file for the boot drive from the other VM I had been running. With this comparison, and a handy reference to the VDI file format with hex offsets, I made the following observations:

1) The VDI file appeared to have been overwritten by something that definitely did not belong in a VDI file from address 0x40 (64 bytes into the file) to around 0x11d8 or so (give or take a few 0x10).
2) This something had overwritten very important header fields like the size of the drive, and the UUID, making it totally unmountable (hence, the errors).
3) The offending overwrite appeared (by comparison to several valid VDI files) to have overwritten important data starting at offset 0x1000 and ending at 0x11d8 or so (again, the end is hard for me to determine since I'm unfamiliar with the structure of that part of the file). It is abundantly obvious that important stuff was overwritten with something that definitely did not belong in that part of the file.
4) The binary content that was written to this portion of the VDI file appeared abundantly similar to parts of an NTFS partition that I was able to also open in a hex editor (strings like 'FILE0', unicode strings like 'S.E.C.U.R.I.T.Y...L.O.G' and 'S.Y.S.T.E.M', plenty of what appeared to be isolated unicode backslashes).

From this, I hypothesize that the virtual hard drive code wrote some sector of the guest NTFS filesystem into the header part of the VDI file, possibly for reasons relating to pausing and resuming often, but just as probably for other reasons entirely.

The first 128 KiB (0x20000) of the VDI file is attached to this ticket.

It might be relevant to note that this was a 20.0 GiB dynamic VDI file, connected to a SATA controller in the VM, with the SSD mode turned on. The guest drivers were installed on the guest at the time of the failure.

Fortunately, I didn't lose any important data (I was not yet finished installing and updating the guest operating system and the purpose of the VM was to be a driver development testbed/debugging environment anyway). However, I think this bug deserves a close look because of just how fatal it could be.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy