[VirtualBox 4.3.28 released! --- Forum: http://forums.virtualbox.org/ --- Bugtracker: http://www.virtualbox.org/wiki/Bugtracker --- User Manual: http://www.virtualbox.org/manual/UserManual.html] [10:05] == S466531257BOSS [5c4c254c@gateway/web/freenode/ip.92.76.37.76] has joined #vbox [10:06] hi, i have a serious problem with VirtualBox 4.3.28 running on Windows NT 6.3.1 x86 ( Windows 8.1 Industry Embedded all Updates 32-Bit ), which kills my machine totally ( mean immediate shutdown/restart ) mostly with machines, that either try to use the nx feature, or trying to activate virtualization themselve, or if i try bto run a 64-Bit machine; [10:06] The machine it runs on is a Dell 740 OptiPlex, sporting a AMD Athlon X2, 2.7 Ghz, run 2x2GB RAM DDR II [10:06] anyone here who think is able to help out, to go on with me, to isolate the failure? [10:07] <@MichalN> First of all, is it a regression or did VirtualBox never work on that system? [10:08] Hi, it is in this case a fresh install, though the same setup, did run before [10:08] i had to reinstall the whole, because the previous setup was killed totally [10:08] btw. the system runs via native vhd boot [10:08] == geomyidae_ [uid214@pdpc/supporter/professional/geomyidae] has quit [Quit: Connection closed for inactivity] [10:09] <@MichalN> OK, so it used to work but possibly very different software setup. [10:09] <@MichalN> What was the working VirtualBox version? [10:09] yes, it varies, but bthe virtualbox version was the same [10:09] it is as given 4.3.28 [10:10] <@MichalN> Ah, so the same VirtualBox version worked on the same hardware with a different host OS setup? [10:10] sorry, no; it is exactly setup in the same manner as before [10:10] same host os, same vbox [10:10] only difference maybe drivers [10:11] as i used the given wddm driver for the graphics before [10:11] now it is the ati driver [10:11] do you think this might be a point ? [10:12] i run a firepro v5700 [10:12] <@MichalN> Well, *something* must be different, right? :) It could be the host display driver, although to be honest it sounds unlikely. [10:12] dual head [10:12] do you have an idea, maybe a test ova [10:12] to reduce the possibilities [10:13] a step by step setup [10:13] <@MichalN> Some kind of Linux live CD would be good for testing, with a freshly created VM using default settings. [10:13] <@MichalN> In all problem cases the host system reboots but does not BSOD? So no crash dump? [10:13] no crtash dump at all, totally kill [10:13] what i can say is [10:14] that ANY time an applianxce tries to use bridged modes [10:14] it definately kills [10:14] but besides that, i cant reduce it to special settings [10:14] until now [10:14] :) [10:14] what do you say is a guaranteed setup [10:15] as for now i am chatting via webchat on the given machine [10:15] so it would be a perfect test if you can say what definately should function at all [10:15] if i am away you know what happened [10:15] :) [10:16] release is 100309 [10:16] <@MichalN> Well, everything should function :) If you have a 32-bit VM, does it make a difference whether it uses software or hardware virtualization? [10:16] of vbox [10:16] no, tested that already [10:16] <@MichalN> You mean both can reboot the host? [10:17] all given combinations of usinh soft vs hard, nx on off etc. using shared folders or not, etc. im through wiith [10:17] tested already with ubuntu lucid for pae without nx, net install [10:17] <@MichalN> And that rebooted the host too? [10:17] <@MichalN> A 64-bit VM on a 32-bit host OS is a very special case, but it sounds like that's not the only problem. [10:17] and same with pae nx , also debian jessie live and old ova [10:18] it rebooted while system was already running [10:18] that is the only difference [10:18] <@MichalN> The trouble is that if the system just reboots, there's no way to tell what really caused it. Doesn't have to be VirtualBox. [10:18] so it got further [10:18] any idea for a sandboxed environment i could setup ? [10:18] <@MichalN> Also could be flaky hardware (memory, CPU, whatever). [10:19] thought that too [10:19] but already made ram and cpu stress test [10:19] no failure at all [10:19] hard disk also clean [10:19] gpu test runs fine too [10:19] btw, the host is running stable for days even under full use [10:20] <@MichalN> Stress tests don't always find the problem because they don't stress the hardware the same way as "real world" apps :) [10:20] independent of running [10:20] AH [10:20] yes ithere is a difference [10:20] == fmehnert [~fm3@p54B4662B.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!] [10:20] == fmehnert_ [~fm3@p54B4662B.dip0.t-ipconnect.de] has joined #vbox [10:20] it is crashing o Windows 8.1 [10:20] i have debian jessie as host too and ubuntu 15.04 [10:20] they do not crash [10:20] for host os [10:21] but at the moment i can not tell if it ios the same release [10:21] <@MichalN> Is that on the same host system? [10:21] yes [10:21] multiboot [10:21] <@MichalN> OK, that makes a hardware problem much less likely. [10:22] thought so, but to admit, i forget about that fact, so we can reduce it to windows version if that makes a difference [10:22] == `Cam [~textual@60-241-86-210.static.tpgi.com.au] has quit [Quit: ZZZ] [10:22] == towo` [~towo@ipb21920e8.dynamic.kabel-deutschland.de] has joined #vbox [10:23] what do you think is there any sandbox i could use to run the vbox ? [10:23] <@MichalN> Anyway, the only starting point so far is that that the more or less same setup used to work reliably, but no longer does. So the obvious question is what exactly changed to break it :) [10:23] yes :) [10:23] wait i have an idea [10:23] <@MichalN> I'm not sure what exactly you mean by sandbox. It's not really going to do anything, VirtualBox needs to access the host OS/hardware. [10:24] it could be that it not wotrked anymore after installing the visual studio ultimate 2013 testdrive [10:24] but i am not sure about it [10:24] at least it was the last software i installed [10:24] == fmehnert__ [~fm3@p54B4662B.dip0.t-ipconnect.de] has joined #vbox [10:24] == fmehnert_ [~fm3@p54B4662B.dip0.t-ipconnect.de] has quit [Client Quit] [10:24] i use visula studio community and professional normally [10:25] so it might be a point [10:27] you give up ? :) [10:28] ah sorry overread; by sandbox i mean things like sandboxie or similar [10:28] or debug via vs [10:28] whatever, any idea might help [10:29] <@MichalN> No, sandboxie etc. will do no good. [10:29] okay [10:29] <@MichalN> The only idea I have is narrowing down the problem to the change between working/non-working setup. If it's not VirtualBox, it has to be something else. [10:30] does vbox have a full logging mode ? [10:30] means is there an option to let it log anything [10:30] <@MichalN> Only debug builds, and even then it may not help. [10:30] hmm, sad [10:30] <@MichalN> If the host memory is getting corrupted for example, logging won't do much good. [10:31] <@MichalN> But the problem is again that a host reboot can be caused by pretty much anything. It's normally an indicator that the system state is too corrupted to continue. [10:31] are there any test ovas from oracle or community, maybe it is possible to narrow down INSIDE a vm [10:31] <@MichalN> But there's an infinite number of possible causes. [10:32] <@MichalN> I can't think of anything. Again, Linux live CDs are good for self-contained and reproducible testing (not installing the OS, just booting up). [10:33] sorry if not mentioned it to detail, NO PROBLEM AT ALL with any live cd [10:33] <@MichalN> Ahh, sorry, I missed that. [10:33] by any i mean: ubuntu lts versions 32 and 64 bit, debian wheezy and jessie, kali 1.1.0a [10:34] only distro that has problems by running very very slowly [10:34] is fedora 21, 17 and 19 [10:34] <@MichalN> So it's not a general instability, it's something the guest OS does to trigger it. [10:34] no you dont miss i just did not got to it in detail until now [10:34] yes, i think so [10:36] what i could think of in fedora is 2 things: boxes, as it uses libvirt by default in 21 and the anaconda installer which is incredibly dumb in my opinion [10:36] so fedoara aside [10:36] all debian based os run fine as live [10:37] <@MichalN> Even the 64-bit guest OS versions work fine as live CD? [10:37] independent of live or, installer, netinstaller, graphical, cli, or even installed, but after having user profile setup they crash too [10:37] yep [10:37] even 64bit [10:38] so to be specific in the moment the guest os ( debian based ) switches from initial initrd to full desktop mode, hanging in drivers and stuff [10:38] so after rebooting into the fully setup guest os [10:38] do we have a breadcrumb ? :) [10:39] <@MichalN> Hard to say yet. [10:39] i thought so :) [10:39] <@MichalN> Does the host reboot always happen at the same point in the guest OS startup? [10:39] <@MichalN> As in, is it reliably reproducible or is there some randomness? [10:39] as i can visually follow, yes [10:40] in case of debian systems, right after logging in in a graphical env [10:40] <@MichalN> Does the VM have 3D enabled? [10:40] i tested both [10:40] on and off [10:40] <@MichalN> And it kills the host either way? [10:40] yep [10:41] is there a switch for vbox to run without any extension ? [10:41] just to countertest [10:41] <@MichalN> What do you mean by "extension"? [10:41] without any use of hardware acceleration or remapping, maybe the vbox mangement gui is not reliable [10:42] ah theres another thing [10:42] <@MichalN> You could try running a headless VM. [10:43] i do not run vbox from the documents folder, instead from a diverse pathh on a separate hdd [10:43] but i always do that [10:43] <@MichalN> That shouldn't matter. [10:43] okay [10:43] what would be the right switches for running headless in supersafe mode, if there is any option like that ? :) [10:44] <@MichalN> VBoxManage startvm --type headless [10:44] <@MichalN> Or I think holding Shift while starting the VM from the GUI VM Manager should do it. [10:45] Just to prove me wrong: Can it be that running via native vhd boot ( so host inside a vhd ) is confusing vbox, as i use vhd instead of vdi or qcow for guests [10:45] shift while using start-button in gui or from menu ? [10:46] any difference [10:46] <@MichalN> Shift while double-clicking on the VM, I think. [10:46] <@MichalN> The VHD boot is really unlikely to cause trouble, but of course *something* must be. [10:47] okay i add that to my tests, any other ideas before i go with it, as i am still running on the problematic host with this chat :) [10:47] <@MichalN> Anyway, virtual disks are just files to VirtualBox, it doesn't really care what the host filesystem is, if the virtual disks are stored on a network share, etc. [10:48] okay good to know [10:48] <@MichalN> The only ideas I have is a) figuring out what changed on the host to cause this, or b) narrowing down what exactly it is the VM does to trigger the reboot. [10:49] == Akagi201_ [~akagi201@116.226.177.136] has quit [Ping timeout: 258 seconds] [10:49] <@MichalN> As in doing some kind of minimal boot with the guest OS and starting services manually, to get some better idea what is killing it. [10:49] what do you think of the fact, that anytime a guest os tries to use bridged mode it kills definately [10:49] so right before it can boot anything [10:49] == Akagi201 [~akagi201@101.81.71.113] has joined #vbox [10:50] means: right after start of the vm [10:50] <@MichalN> You mean the VM doesn't even start? [10:50] <@MichalN> Or as soon as the guest starts booting? [10:50] <@MichalN> What I think of that is that it's significant one way or another :) [10:50] specifically right at the moment the vm is started the whole machine ( host ) kills [10:50] itself [10:51] <@MichalN> In the "normal" case the VMs are using NAT? Or NAT Network? Or something else? [10:51] on that point, there is a difference, i use the onboard gigabit net now, before i used wifi g to acces my router before [10:52] in these cases a bridged mode is not given they do as described before [10:52] so live ones run without problem [10:52] and installed ones right after switching to full user experience in graphical mode [10:52] yes nat [10:52] in normal case [10:52] or manually set to nothing [10:53] proved that too [10:53] thin is i changed the pci wifi with a firewire pci [10:53] thats why i use cable now [10:54] onboard nvidia gigabit controller [10:54] <@MichalN> OK, so the host networking setup changed. [10:54] :) [10:54] .... yeees [10:54] <@MichalN> Can you try the old setup again? [10:54] sometimes things come up when talking bout ... :) [10:55] hmmm, i think i have usb wifi , if you think its enough to deactivate devices in windows host, that is an option [10:55] or is vbox able to see directly without the hal of windows what devices are inside the host ? [10:56] then i think i should screw the host up [10:56] <@MichalN> No. Host network drivers will be used. [10:56] == DCyrax_ [~chatzilla@a91-156-233-68.elisa-laajakaista.fi] has joined #vbox [10:56] <@MichalN> So what network device is used and what driver that device uses does matter. [10:56] so deactivating plus instead using a wifi usb might reduce the cases y you think ? [10:57] okay i added it to my test variants [10:57] == DCyrax [~chatzilla@a91-156-233-68.elisa-laajakaista.fi] has quit [Ping timeout: 272 seconds] [10:57] any another idea [10:57] <@MichalN> What was the original networking setup again? [10:57] == DCyrax_ has changed nick to DCyrax [10:57] originally internal wifi dlink 54 mbit over g acces to an easybox 803 [10:58] drivers actiove for nvidia gbit onboard controller but not used [10:58] == Hypnoz [~Adium@99-100-176-240.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Leaving.] [10:58] now im using the gbit net directly to an easybox 804 which is now master router [10:59] and the pci wifi dlink is out of and changed with a firewire controller [10:59] the original 803 is chained on the now easybox 804 [10:59] <@MichalN> OK, so the previously used NIC isn't in the system anymore. [10:59] so connecting wifi to the easybox 803 would be the same net i used before [11:00] yep [11:00] its out [11:00] == aeichner_ [~aeichner@2a02:8109:8200:e48:201:2eff:fe35:4709] has joined #vbox [11:00] <@MichalN> Based on what you observed, does it look like the guest doing some network activity might be what's killing the host? [11:00] hmmm [11:01] ubuntu tries to check in ubiquity setup for given access to the nets [11:01] <@MichalN> I should say that NAT should be very safe because in that case VirtualBox is just a regular app that uses the TCP/IP network stack. Bridged networking is completely different. [11:02] == aeichner|nas [~aeichner@2a02:8109:8200:e48:201:2eff:fe35:4709] has quit [Ping timeout: 272 seconds] [11:02] i agree ( as far as my understanding of the insides go ), what makes me humble is that the host crashes immediately after starting the vm, when set to bridged [11:02] okay to be precise [11:03] it does NOT crash when bridging to another net [11:03] i have another unused pci net 100mbit in the host [11:03] i just didnt use it anymore [11:03] but it is present at all [11:03] and just tested if it crashes immediately too when bridged to that one [11:04] <@MichalN> So that didn't kill the host. [11:04] do you think, it could be the onboard gbit ( marvell yukon ) that might be a guaranteed killer independent of networking mode ? [11:04] right that didnt kill the host [11:04] == HeyCitizen [~HeyCitize@69.156.205.235] has quit [Quit: Coyote finally caught me] [11:05] at least until a fully installed guest ( linux) is runnig the desktop [11:05] after login into setup user accopunt [11:05] <@MichalN> That's what it sounds like, but I can't imagine why that would cause trouble with NAT. Unless it was the host NIC driver that's buggy. [11:05] <@MichalN> When you dual boot to Linux, you're using the same Marvell NIC? [11:06] im not into the details of linux systems, do you know if there is a hardware check for before ( in setup mode ) unseen devices like the nvidia onboard marvell yukon) [11:06] yes in host linux i use the same [11:06] <@MichalN> If the same NIC works in Linux then the NIC hardware is probably okay, but the driver still could be faulty. [11:07] == HeyCitizen [~HeyCitize@69.156.205.235] has joined #vbox [11:07] the idea is, maybe the installed guest linux tries to access other devices or do checks on the already found ones, even in nat mode ? like, some of the hardware might slip through to the guest ? [11:07] <@MichalN> You know, a few years ago I had trouble with some AMD board which I think had a similar NIC. The system was just never stable until I replaced it with a different NIC. [11:07] hope you understand what i try to tell, sorry im native german [11:08] <@MichalN> I understand. But no, the guest does not see the host hardware at all. It could only be something indirect. [11:08] so you, sofar agree it COULD be the or one of the problems [11:08] the gbit nic [11:08] <@MichalN> As in the network activity triggered by the guest will one way or another cause activity on the host NIC+driver. [11:08] think it helps deactivate via bios ? [11:09] as far as i know windows 8.1 gives a sh.. on it, as the device is accessible independent of bios setting [11:10] i just can deactivate it via device manager to get rid of it [11:10] <@MichalN> It should be possible to deactivate the device in the BIOS so that Windows can't see it at all, *if* everything works properly. [11:10] :) yeah [11:10] <@MichalN> But yes, disabling it in Device Manager is another option. [11:10] it SHOULD [11:10] okay added that one [11:10] so, you run hot already, anymore ideas, maybe curious ones ? [11:10] :) [11:10] btw [11:10] thanks for discussing these [11:11] it helps a lot to cook more brains than just the one i am carrying ;) [11:11] <@MichalN> No further ideas. So far it's clear there's some kind of problem with networking on the host system, the rest remains to be seen :) Trying a different NIC is definitely a good idea. [11:12] <@MichalN> A bad NIC/driver can easily corrupt host memory which can cause the kind of reboots you're seeing. [11:12] okay ill give it all a tray and countertest if thinking i found a solution; to spend some results, what is the best place? just in case it could help another user with a similar setup [11:13] i could have a lookup for the driver version, maybe the driver was updated on jump to 8.1 with update1 [11:14] so where ( if ) ishould give feedback [11:14] <@MichalN> The VirtualBox bug tracker or forum is probably the best way to share information, although it's not yet clear that there is actually a bug in VirtualBox. [11:14] can you specify what exactly is needed to report a bug ? [11:15] == Tekn0 [~token@unaffiliated/teknomancer] has joined #vbox [11:15] == mode/#vbox [+o Tekn0] by ChanServ [11:15] ill do that work if possible [11:16] == JarJarBenks [~BenOrigin@cpc70137-lutn12-2-0-cust564.9-3.cable.virginm.net] has joined #vbox [11:17] ... just in case it results in a bug [11:18] <@MichalN> See here: https://www.virtualbox.org/wiki/Bugtracker [11:18] == JarJarBenks has changed nick to GenteelBen [11:19] == lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #vbox [11:19] == DCyrax [~chatzilla@a91-156-233-68.elisa-laajakaista.fi] has quit [Read error: Connection reset by peer] [11:19] last question: is it okay to spend this chat logged in case of a bug report ? [11:19] == DCyrax [~chatzilla@a91-156-233-68.elisa-laajakaista.fi] has joined #vbox [11:20] == pauled [~pauled@unaffiliated/pauled] has quit [Quit: pauled] [11:20] <@MichalN> I don't think anyone will want to read the entire conversation but sure, you can save it for later reference. [11:21] thanks a lot, for you helping out and your kindness; ill go testdrive now. thank you, and have a nice day, evening or whatever time ! :) [11:21] == D-Boy [~D-Boy@unaffiliated/cain] has quit [Excess Flood] [11:22] == DCyrax_ [~chatzilla@a91-156-233-68.elisa-laajakaista.fi] has joined #vbox [11:22] <@MichalN> Thanks! [11:22] thank you!, bye