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

[Matteo_A_]

I'm running the Android Emulator with HAXM, waiting for a BSOD to collect the full memory dump. I'll report here as soon as Windows crash :S. Can I attach the full memory dump using the tools in this websites (it seems it can accept file up to 4GB)? Or should I upload it somewhere else like skydrive, dropbox etc?

[Peter_d_]

Ok, will see if a full dump will be possible. I saw it deletes them because of disk space (SSD). I also have 16GB ram, so I hope I am not getting a 16GB file then. 

I did indeed use windbg to analyze minidump, but I am not an expert ofcourse here, so please verify for yourself if needed.

[Peter_d_]

Considering this bug is VT-X related, and also happening in Virtualbox, maybe their analysis is useful for you:

"The bug (from my analysis so far) is a timing related issue in the core hypervisor code (VT-x only). It is not related to bridged, USB, guest additions etc. It -does- however depend on whether or not the guest uses the TSC Aux MSR. Most OSes use this MSR to hold the cpu index (APIC id) so it might be possible that the guest doesn't write this MSR if it only has one CPU."

[Peter_d_]

Because this bug is probably VT-X related, maybe the analysis of Virtualbox can help a bit?

The bug (from my analysis so far) is a timing related issue in the core hypervisor code (VT-x only). It is not related to bridged, USB, guest additions etc. It -does- however depend on whether or not the guest uses the TSC Aux MSR. Most OSes use this MSR to hold the cpu index (APIC id) so it might be possible that the guest doesn't write this MSR if it only has one CPU.

Also: do you need full kernel dump, or full memorydump?

[Matteo_A_]

I'm having trouble getting the complete memory dump. It seems it doesn't generate at all. I'm running windows 8.1 on a laptop with 8GB of ram and a 90GB partition of an SSD (24 GB free). I can see the minidump are correctly generated, but i cannot see any MEMORY.DMP file anywhere, even changing the default directory path. What should I do to collect the full memory dump?

Anyway, I think it's quicker for Intel and Microsoft to test this themselves, it's very easy to reproduce as other people have said. It could be a problem also to upload a 8GB files on the net...

[klnerber]

Had the very same issue, system (Windows 8.1 64 Bit) would always crash with BSOD within a few minutes after Android was launched with HAXM.
But I also noticed strange crashes related to the MS Hyper-V network bridge, which would disconnect my machine from the network all the time, forcing me to reboot.

Then I saw some weird warnings concerning my Intel 82579V adapter in the system event log every time after HAXM was launched, right before the BSOD occurred.

So I updated my Intel network drivers to Version 18.7 (released 09/27/2013) and both issues have vanished so far.

HAXM is running stable for several hours now. If you have similar hardware, give it a try.

[klnerber]

Forget it... crashed shortly after I clicked the submit button. Now downgrading to Windows 7.

[Bernard]

Hi Mateo and Peter

I tried to run automated analysis on both files uploaded by you and debugger was not able to reconstruct call stack it is so probably due to collecting minidump file of the failed process.Please collect  kernel dump.

Trying to manually reconstruct the call stack prior to the crash was not successful because the needed data is not available(minidump)I only identified the last argument of KBugCheckEx which is 0x3 which could point to corrupted GDT entry.

[Bernard]

Peter d. wrote:

Because this bug is probably VT-X related, maybe the analysis of Virtualbox can help a bit?

The bug (from my analysis so far) is a timing related issue in the core hypervisor code (VT-x only). It is not related to bridged, USB, guest additions etc. It -does- however depend on whether or not the guest uses the TSC Aux MSR. Most OSes use this MSR to hold the cpu index (APIC id) so it might be possible that the guest doesn't write this MSR if it only has one CPU.

Also: do you need full kernel dump, or full memorydump?

I need to see kernel stack of executing thread in order to find the faulting IP.For know it could be anything.

[Alexander_W_Intel]

Hi,

thanks for all your replies. We are still investigating into this issue. Personally I don't be able to reproduce the issue on a fully updated Windows 8.1 system. So this might be a combination of some installed programs, drivers or settings. I will update this thread as soon as I have new informations about this issue. 

Thanks,
Alex 

[Bernard]

It was stated by someone that crash(BSOD) occures at 30 min intervals it seems that PatchGuard is reponsible for bringing system down in case of critical structure corruption.

[Peter_d_]

Ok, I am now working (developing), so I disabled HAXM for now. Will try to collect a kerneldump this evening.

[Bernard]

Ok Peter please post update when you will be done with collecting kernel dump.

[Bernard]

Btw I suppose that debugging will not be easy because of PatchGuard beign involved in crashing the system.

[Alexander_W_Intel]

Thanks for pointing me to the 30 minutes inteval. I will try to reproduce it with that information. Makes it really tricky. Does anyone knows if the PatchGuard can be started manually to help reproducing the issue?

Thanks,
Alex 

[Bernard]

Hi Alexander

15 to 30 minutes interval is probably PatchGuard scanning interval of crucial OS structures like (IDT,GDT,SSDT ...etc).Unfortunately PatchGuard cannot be disabled unless you enable kernel debugging and actually connect kernel debugger (both machine will be needed host and target).Another option is to use bcdedit tool to diable PG without kernel debugging.

Please read this article http://www.codeproject.com/Articles/28318/Bypassing-PatchGuard-3#_2_1

[Gaby_B_]

Same issue: Uninstal HAXM and the Crashs gone!

Windows 8.1 64 bit.

I guess it is very wide issue releated to ALL android developer on Windows 8. (Unfortunately it is not possible to go back to 8.0 without recovery or fresh install)

[Matteo_A_]

I'm havings BSODs not regolarly, but sometimes it's true it happens after about 30 minutes. Sometimes i got the blue screen after less than 10 minutes, sometimes no crash for hours.

I'm working on a laptop I use for work (I'm an Engineer student), every driver is updated from chipset to touchpad. I've installed Eclipse kepler and added the ADT plugin to it. I've installed HAXM in order to speed up the Android emulator, wich gave me no problem at all on win8. Just to be clear, uninstalling the HAXM driver solved the issue and I'm not having any BSOD since. My laptop is a custom Sony Vaio E series with Intel Core i5-460M 2.53GHz, Ati MobilityRadeon HD5650 1GB, 8GB of RAM Corsair (tested with ramtest), Windows 8.1 latest updated available.

I've managed on collecting a kernel dump (I don't know how!), so here's the link: http://sdrv.ms/GZYSXO

[Soichi_H_]

I am having a similar problem on Windows 8.1 with Core i7-4770K with default BIOS configuration. I get BSOD with crash address of ntoskrnl.exe+14dca0. As soon as I enable VT-X via BIOS, system starts crashing within a few hours. It crashes more often when I am actually running VirtualBox, but it crashes without VirtualBox running although much less frequently. The only way to prevent the crash is to disable VT-X all together via BIOS. 

I have attached my recent minidumps.

I have ran memtest and I didn't find any issues with my 16G DDR3 2133Mhz.

[Bernard]

Please do not upload minidump file because it does not contain kernel mode call stack.It is not related to memory. In your case @Soichi it seems that MSR register (0X176?)was modified(written?) and PG crashed the system.Can you upload or provide !analyze -v output of kernel memory dump?

[Soichi_H_]

iliyapolak,

I am not very familiar with WinDbg, so I am not sure if I am doing this right, but I get following from !analyze -v

5: kd> .symfix; .reload
Loading Kernel Symbols
...............................................................
................................................................
...........................
Loading User Symbols
Loading unloaded module list
...............
5: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a01f5893c8b67a, Reserved
Arg2: b3b72bdee648c035, Reserved
Arg3: 00000005c0000103, Failure type dependent information
Arg4: 0000000000000007, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification

Debugging Details:
------------------

PG_MISMATCH: 1

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x109

PROCESS_NAME: System

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre

LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff801a9f4dca0

STACK_TEXT:
ffffd000`20a06088 00000000`00000000 : 00000000`00000109 a3a01f58`93c8b67a b3b72bde`e648c035 00000005`c0000103 : nt!KeBugCheckEx

STACK_COMMAND: kb

FOLLOWUP_IP:
nt+14dca0
fffff801`a9f4dca0 48894c2408 mov qword ptr [rsp+8],rcx

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt+14dca0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 52341cf4

IMAGE_VERSION: 6.3.9600.16404

FAILURE_BUCKET_ID: 0x109_nt+14dca0

BUCKET_ID: 0x109_nt+14dca0

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x109_nt+14dca0

FAILURE_ID_HASH: {8339dd0b-1f09-c6df-317e-b65c941183a4}

Followup: MachineOwner
---------