Custom Query (16363 matches)
Results (1783 - 1785 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #9404 | obsolete | BSOD happen Virtual Box 4.1 on Windows 7 host installed Eset | ||
| 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 | ||
| 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 | ||
| 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:
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). 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. |
|||

