Custom Query (16363 matches)
Results (2479 - 2481 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #15371 | worksforme | VirtualBox creates unwanted logfiles at unwanted location | ||
| Description |
Since version 5.0.18, VirtualBox seems to write an extra logfile each time I start a virtual machine. Normal, expected behaviour: The logs (filename: Vbox.log, Vbox.log.1 etc) are written in a folder called "Logs", which is a subfolder of the virtual machine's folder, wherever on your harddrive that may be. Since version 5.0.18 (also happens in 5.0.20), I get an extra file with a name like "2016-04-30-16-41-41.074-VirtualBox.exe-5856.log", which is stored directly in the user's folder (%USERPROFILE% = C:\Users\{Username}\). One of those files is created each time I start a virtual machine (doesn't matter which one). There is no way to turn this off, and I have to delete those files manually, I don't want them there. I attached one of those files as an example. Of course, the priority is only minor, this does not "break" VirtualBox, but it is an annoyance. Btw, my OS is Windows 8.1 x64, not sure if this happens on other OS as well. |
|||
| #15368 | duplicate | VirtualBox 5.0.18 does not work with Windows 10 Build 14328 and 14332 | ||
| Description |
I have successful installed the VirtualBox 5.0.18 in Windows 10 Pro Build 14328, then re-installed it after update to Build 14332. In both builds VirtualBox does not start, shows no error messages, simply does nothing. I am using a Samsung Notebook with i3 processor, 8GB RAM and 250GB SSD. No special hardware. I am very sad, because I like VirtualBox and I would like to use it for run Kubuntu 16.04 as guest. |
|||
| #15366 | worksforme | Yosemite 10.10.5 - Kernel Instability and Crash | ||
| Description |
It's possible that your developers are already aware of this crash. Unfortunately, I'm in midst of critical timeline of another SW dev project, but thought I would report this problem anyway. I installed VirtualBox 5.0.16 on the OsX-Yosemite 10.10.5 system, (which, BTW, did also have Fusion 7.1.2 installed on it). It was after the VirtualBox installation that the kernel instabilities were introduced. The complete system lockups, where 2 of the 3 monitors would immediately go black, leaving desktop still showing on a 3rd monitor, on a 2nd GTX-980, were traced to VirtualBox as the culprit, by using your Un-Installer to remove VirtualBox and it's KEXT(s) from the system. There have been no more kernel instabilities since the complete VirtualBox removal. It is important to note, that VirtualBox is causing OsX kernel instabilities, even when no virtual machines are running on the system. (No VMware VMs, nor VBox VMs). Thus you have a very insiduous problem going on within your KEXTs for OsX. That's because after 10 crashes, and inspecting the OsX System Logs, there are common messages produced in that log, which would give clue to the fact that VirtualBox had any problem, OR that any other OsX driver or subsystem had any problem. That's why I used the word "insidious". However, the impact can be devastating for those whom try to utilize VirtualBox for some type of production level system. Hardware: CPU Hexacore 3970X (Extreme) Sabertooth X79 Mobo 64 GB DDR 2 NVidia GTX-780 Misc SSDs OsX 10.10.5 (Yosemite) This instability ALSO exhibits itself on a MacMini (Apple) Mid 2013 with 4 core...also with VMware Fusion 7.1.2. Same symptoms, but needs more stressing of CPUs to exhibit the kernel crash. Multiple streams of audio processing were also involved in 2 crashes. My intution: This instability seems to be related to some type of low level video processing, like potentially GPU raster operations or video buffer movements, possibly your code which is virtualizing the display (if that's possible without VMs running). The bug can occur with VMs running, but most of the crashes I experienced, were with NO VMs running. Our resolution: For now...we have removed VirtualBox from every development system we have. Sorry, that I do not currently have the bandwidth to aid/assist more in your tracking this down. I almost didn't report at all. I just don't have time for it...but I know the nature of this bug is very nasty. |
|||

