Thanks Michal. I tried the test build VirtualBox-4.3.15-95286-Win.exe and it did not produce the issue any more.
However, my custom virtual PCI device dll cannot be loaded by 4.3.15 with error: Unable to load R3 module (VERR_LDRVI_NOT_SIGNED). Does this mean from 4.3.15, VBox needs the device module to be signed? Is there any way to disable it? Thanks. -Ray > > > See https://www.virtualbox.org/ticket/10097 . This problem was fixed in > 4.3.14 for Windows 7 guests and I have currently no reason to think > Windows 8 is different. > > And yes, it's entirely normal that all local APICs in a system are mapped > at the same address. And those IPIs with vector zero are in fact NMIs > (the delivery mode says it's NMI, hence the vector is meaningless and it > will be delivered through IDT vector 2 as an NMI, not a maskable > interrupt). > > > Regards, > > Michal > > ----- Original Message ----- > From: [email protected] > To: [email protected] > Sent: Friday, August 1, 2014 7:06:38 AM GMT +01:00 Amsterdam / Berlin / > Bern / Rome / Stockholm / Vienna > Subject: [vbox-dev] Crash on Win 8 guest when kernel debugging is enabled > via network > > Hi guys, > > I have been fighting with this issue for quite a while but still do not > have any clue about how to solve it. > > Basically, I have a Win 8 64bit guest OS running on VBox 4.3.12 (both > official release and my private build versions) on Win 7 64bit host. If I > do not enable kernel debugging via network on the guest Win 8 with > multi-core, it boots up without problem. But if the kernel debugging and > multi-core are enabled, guest OS just bug-checks at very early stage > during the boot, with the following bug-check codes: > > BugCheck 124, {3, 0, 0, 0} > BugCheck 80, {4f4454, 0, 0, 0} > > Every time when it bug-checks, it always does not stop on core 0. Since > they are NMI related, I dump the apic info in the guest with WinDbg, as > the following: > > 1: kd> !apic > Apic @ ffdab000 ID:1 (50014) LogDesc:02000000 DestFmt:ffffffff TPR F0 > TimeCnt: 00000000clk SpurVec:3f FaultVec:e2 error:0 > Ipi Cmd: 01000000`00000c00 Vec:00 NMI Lg:01000000 edg high > Timer..: 00000000`000300fd Vec:FD FixedDel Dest=Self edg high > m > Linti0.: 00000000`000100c0 Vec:C0 FixedDel Dest=Self edg high > m > Linti1.: 00000000`000184c0 Vec:C0 NMI Dest=Self lvl high > m > TMR: > IRR: > ISR: D1 > 1: kd> ~0s > 0: kd> !apic > Apic @ ffdab000 ID:0 (50014) LogDesc:01000000 DestFmt:ffffffff TPR F0 > TimeCnt: 00000000clk SpurVec:3f FaultVec:e2 error:0 > Ipi Cmd: 02000000`000c00d1 Vec:D1 FixedDel Dest=Othrs edg high > Timer..: 00000000`000300ff Vec:FF FixedDel Dest=Self edg high > m > Linti0.: 00000000`000100c0 Vec:C0 FixedDel Dest=Self edg high > m > Linti1.: 00000000`000184c0 Vec:C0 NMI Dest=Self lvl high > m > TMR: B1 > IRR: D1 > ISR: > > Then notice IPI has an interrupt to vector zero. This is confirmed after > apic log is enabled in VBox as well: > > 04:27:44.429801 0000000000001e80 EMT-0 apic_deliver dest=1 dest_mode=0 > dest_shorthand=0 delivery_mode=5 vector_num=0 polarity=1 trigger_mode=1 > 04:27:44.429801 0000000000001e80 EMT-0 apic_deliver dest=1 dest_mode=0 > dest_shorthand=0 delivery_mode=5 vector_num=0 polarity=0 trigger_mode=1 > 04:33:41.362210 00000000000018ec EMT-0 apic_deliver dest=2 dest_mode=1 > dest_shorthand=0 delivery_mode=4 vector_num=0 polarity=0 trigger_mode=0 > 04:33:49.438736 00000000000018ec EMT-0 apic_deliver dest=1 dest_mode=0 > dest_shorthand=0 delivery_mode=5 vector_num=0 polarity=1 trigger_mode=1 > 04:33:49.439236 00000000000018ec EMT-0 apic_deliver dest=1 dest_mode=0 > dest_shorthand=0 delivery_mode=5 vector_num=0 polarity=0 trigger_mode=1 > 04:33:49.743774 0000000000001114 EMT-1 apic_deliver dest=1 dest_mode=1 > dest_shorthand=0 delivery_mode=4 vector_num=0 polarity=0 trigger_mode=0 > 04:33:50.489369 0000000000001114 EMT-1 apic_deliver dest=1 dest_mode=1 > dest_shorthand=0 delivery_mode=4 vector_num=0 polarity=0 trigger_mode=0 > 04:33:50.856916 0000000000001114 EMT-1 apic_deliver dest=1 dest_mode=1 > dest_shorthand=0 delivery_mode=4 vector_num=0 polarity=0 trigger_mode=0 > 04:33:51.685521 00000000000018ec EMT-0 apic_deliver dest=2 dest_mode=1 > dest_shorthand=0 delivery_mode=4 vector_num=0 polarity=0 trigger_mode=0 > 04:33:51.878045 0000000000001114 EMT-1 apic_deliver dest=1 dest_mode=1 > dest_shorthand=0 delivery_mode=4 vector_num=0 polarity=0 trigger_mode=0 > 04:33:51.894047 00000000000018ec EMT-0 apic_deliver dest=2 dest_mode=1 > dest_shorthand=0 delivery_mode=4 vector_num=0 polarity=0 trigger_mode=0 > > > Note that the initial two interrupts to vector 0 are also seen with > successful guest boot. But the problematic one has more interrupts to > vector 0. After check more logs, I found the following two: > > 04:33:51.878045 0000000000001114 EMT-1 CPU1: apicMMIOWrite at > 00000000fee00300 > 04:33:51.894047 00000000000018ec EMT-0 CPU0: apicMMIOWrite at > 00000000fee00300 > > > It seems that both core have the same local APIC address. Is this correct? > > As I'm totally stuck at the moment, really appreciate if someone can give > me some direction on this issue. > > Btw, VBox 4.3.14 does not work for me as its GUI refuses to start. > > Thanks. > > -Ray > > > _______________________________________________ > vbox-dev mailing list > [email protected] > https://www.virtualbox.org/mailman/listinfo/vbox-dev > _______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
