Intel HAXM causes BSOD in Windows 8.1

[sav_s_]

This is easily repoducible. Pl fix this ASAP. 

http://answers.microsoft.com/en-us/windows/forum/windows8_1_pr-system/criticalstructurecorruption-windows-81/42b145c2-20f2-4a50-b4d2-dea455b390f8

[Soichi_H_]

I've ran analyze -v and attached the output. I've also attached the dump from msinfo32 command... if it's useful at all.

[Soichi_H_]

I forgot to push "Start Upload" button before clicking sumit... trying again.

[Bernard]

Thanks for attached docs.

Unfortunately there is no present callstack can you run kb command?I am afraid that because of PG crash callstack could not be reconstructed.

[Matteo_A_]

Here are the kernel dump (.zip) if skydrive won't let you to download, and there's also my output from !analyze -v

[Bernard]

Tomorrow I wil look at kernel dump.

[Bernard]

Did preliminary analysis of your kernel dump.Unfortunately cannot get call stack there is only call to BugCheckEx function displayed.Looked at SSDT table which seems to be partially overwritten.GDT selectors are different for entries 8 and 9.

Uploaded txt file of manual windbg analysis. 

[Bernard]

Uploaded txt file.

[Soichi_H_]

There are a whole bunch of people having the same problem with VirtualBox, and it looks like the workaround for now is to limit the number of CPU to 1 per VM (or to disable I/O APIC all together). I am not sure if this is VirtualBox(Oracle) issue, or the Intel chip issue, or Windows 8.1 issue..

[Bernard]

Hi 

Was not able to recreate the call stack of the crash I will give another try today.I suspect that automated windbg analysis will not work when the PatchGuard brings down the system.The faulting IP deep inside ntoskrnl.exe belongs to KeBugCheckEx which simply loads stack with return value stored in rcx register.Today I will continue investigation of that dump file and will try somehow to obtain trap frame and maybe from there dump rsp  registers in order to reconstruct the call stack.

Can anyone post the content of GDT selectors only those users whose BSOD has value of 0x3 corrupted GDT.

[Bernard]

The problem is that BSOD in some cases has different values one of them points to corrupted GDT and second points to overwritten MSR register.In your case it seems that GDT was corrupted (relying only on BSOD info).

[Bernard]

Finally reconstructed the call stack , but it mainly contains the function calls and parameter passing  behind the KeBugCheckEx.Investigated also emulator-x86.exe call stacks partially raw stacks,but so far was not able to find any culprit. 

[Bernard]

Emulator-x86.exe threads and their call stacks.Use !teb on address of Thread Environment Block to dump stack address and its size next use dqs esp -3000 esp+3000 to dump raw stack data.

Hope that this information will be helpful in problem solving.

[ffffe000054a5900 emulator-x86.e]
10e8.000b90 ffffe000054d2080 ffffdfbf Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeWaitForMultipleObjects+0x40a
nt!ObWaitForMultipleObjects+0x289
nt!NtWaitForMultipleObjects32+0xda
nt!KiSystemServiceCopyEnd+0x13
+0x77122772
10e8.0010f4 ffffe0000556a880 ffffeeb6 Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeRemoveQueueEx+0x275
nt!IoRemoveIoCompletion+0x8a
nt!NtWaitForWorkViaWorkerFactory+0x30a
nt!KiSystemServiceCopyEnd+0x13
+0x7fff5fa7806a
10e8.0010c8 ffffe00005394880 ffffe736 Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeRemoveQueueEx+0x275
nt!IoRemoveIoCompletion+0x8a
nt!NtWaitForWorkViaWorkerFactory+0x30a
nt!KiSystemServiceCopyEnd+0x13
+0x7fff5fa7806a
10e8.0011f4 ffffe00005565500 ffffe3fa Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeWaitForSingleObject+0x248
nt!NtWaitForSingleObject+0xb2
nt!KiSystemServiceCopyEnd+0x13
+0x77122772
10e8.001020 ffffe0000553d080 ffffe953 Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeWaitForSingleObject+0x248
nt!NtWaitForSingleObject+0xb2
nt!KiSystemServiceCopyEnd+0x13
+0x77122772
10e8.001194 ffffe0000553c080 ffffdfbf Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeWaitForMultipleObjects+0x228
nt!ObWaitForMultipleObjects+0x289
nt!NtWaitForMultipleObjects32+0xda
nt!KiSystemServiceCopyEnd+0x13
+0x77122772
10e8.0011c0 ffffe0000552d080 ffffebab Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeWaitForMultipleObjects+0x228
nt!ObWaitForMultipleObjects+0x289
nt!NtWaitForMultipleObjects32+0xda
nt!KiSystemServiceCopyEnd+0x13
+0x77122772
10e8.001180 ffffe00005709680 ffffe64b Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeRemoveQueueEx+0x275
nt!IoRemoveIoCompletion+0x8a
nt!NtWaitForWorkViaWorkerFactory+0x30a
nt!KiSystemServiceCopyEnd+0x13
+0x7fff5fa7806a
10e8.001034 ffffe000055fb080 ffffe569 Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeRemoveQueueEx+0x275
nt!IoRemoveIoCompletion+0x8a
nt!NtRemoveIoCompletion+0x124
nt!KiSystemServiceCopyEnd+0x13
+0x77122772
10e8.000f74 ffffe00004543080 ffffe3fa Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeWaitForSingleObject+0x248
nt!NtWaitForSingleObject+0xb2
nt!KiSystemServiceCopyEnd+0x13
+0x77122772
10e8.000c1c ffffe00005453080 ffffe857 Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeWaitForSingleObject+0x248
nt!NtWaitForSingleObject+0xb2
nt!KiSystemServiceCopyEnd+0x13
+0x77122772
10e8.000aa4 ffffe0000573f880 ffffe858 Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeWaitForSingleObject+0x248
nt!NtWaitForSingleObject+0xb2
nt!KiSystemServiceCopyEnd+0x13
+0x77122772
10e8.000988 ffffe00004636080 ffffe9e5 Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeWaitForSingleObject+0x248
nt!NtWaitForSingleObject+0xb2
nt!KiSystemServiceCopyEnd+0x13
+0x77122772
10e8.0007a4 ffffe00004d07880 ffffe4ab Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeWaitForSingleObject+0x248
nt!NtWaitForSingleObject+0xb2
nt!KiSystemServiceCopyEnd+0x13
+0x77122772
10e8.0006b4 ffffe00005738080 ffffe842 Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeWaitForSingleObject+0x248
nt!NtWaitForSingleObject+0xb2
nt!KiSystemServiceCopyEnd+0x13
+0x77122772
10e8.000f28 ffffe00006155080 ffffe3fa Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeWaitForSingleObject+0x248
nt!NtWaitForSingleObject+0xb2
nt!KiSystemServiceCopyEnd+0x13
+0x77122772
10e8.0008e0 ffffe000061d1880 ffffe4ad Blocked nt!KiSwapContext+0x76
nt!KiSwapThread+0x14e
nt!KiCommitThreadWait+0x127
nt!KeWaitForSingleObject+0x248
nt!NtWaitForSingleObject+0xb2
nt!KiSystemServiceCopyEnd+0x13
+0x77122772

[Matteo_A_]

Thanks iliyapolak, to be honest I don't understand anything af all this stuff, but I'm sure it could be helpful to whom is capable of reading.

But...who should we blame? It's Microsoft fault, becouse with win8 things worked? Or it's a internal problem related to Intel? And most importantly: are the two companies aware of this situation?.

[Bernard]

Hi Matteo

I know it is not easy stuff to understand ,but in case of such a problems debugging at machine code level is needed to understand what went wrong.I hope that someone at Intel maybe HAXM developers could find it helpful.

Regarding the problem I do not think that this is MS fault.I think that it is more misbehaved kernel mode code.

[Bernard]

Hi Alexander

Were Intel engineers able to reconstruct the call stack?

[Peter_d_]

Finally had the time to create a kerneldump from a Android Emulator with HAXM crash:

https://skydrive.live.com/redir?resid=42E041A300BECF72!709&authkey=!AFCO5_AiJyBbCcM

800mb original size, compressed with 7zip.

[Bernard]

Can you look at last parameter of BSOD was it 3 or 7?

Regarding dump I will manually analyze tomorrow and post the results.It really puzzles me that automated analysis does not work.I suppose that in case of PatchGuard initiated crash it is simply not performed by windbg heuristic engine.

[Babu_S_]

My Windows 8.1 PC crashes due to H/W acceleration for android emulator. Once I unstalled it, there is no crash any longer. Looking forward to a fix for this.

[anonymous_s_]

Alex- same problem using avd/haxm with IDEA for android devel. Xeon 1245-v3 other details here. http://code.google.com/p/android/issues/detail?id=61399  sorry just have a minidump

[Alexander_W_Intel]

Hi,

we probably found the root cause of the issue. We testing this at the moment internally. Thanks for all the helpful posts. This really contributed a lot to find the issue. 

I will keep you updated in this post . 

Alex 

[Bernard]

Hi Alexander 

Can you share more details?

Thanks in advance