Intel HAXM causes BSOD in Windows 8.1

Intel HAXM causes BSOD in Windows 8.1

107 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Confirmed, I have absolutely the same issue.

My Windows 8.1 Pro X64 RTM crashes with CRITICAL_STRUCTURE_CORRUPTION when Intel HAXM 1.0.6 R3 is used.

When HAXM is disabled there is no such issue.


As I wrote in the op's link, I have the same issue. And as Mike did, I disinstalled HAXM driver (1.0.6) and the BSODs went away. Please check this bug...thanks


Sorry for the late answer. We will looking into this. I will update the thread as soon as we finished the investigations. 


We are still investigating on this issue. The dumps doesn't indicate that this is directly caused by HAXM. It would be helpful to know how widespread this issue is and if it's still occour after the latest Windows* updates. 


Thank you for investigating. I don't know exactly if the crash occurred due to HAXM driver, in fact sometimes it crashed without the emulator or eclipse open - in my case just browsing for example, in other words no active application that could use the driver, as far as I know.

What I'm sure is that when I disinstalled the driver, everything worked fine and no crashed occurred since then, so I thought it's at least related.

I'm downloading the update right now (the today's ones of xxx MB), I'll report back if something changed.

Hi Mateo

What are the Bc codes of blue screen?

Bad news...

@iliyapolak What do you mean by "Bc codes"? If you mean the error shown in the BSODs, it's CRITICAL_STRUCTURE_CORRUPTION

The problem is still present, I've updated my Windows 8.1 RTM with the latest updates from Microsoft. I opened eclipse and the emulator, and after 30/45 minutes a crash occurred. The windows Event Viewer still says it's an "EventID 41 (Kernel Power)".

I've attached the .dmp file. I've seen thanks to BlueScreenView (v1.52) that the cause it's the ntoskrnl.exe, with bugcheckcode 0x000000109 at address ntoskrnl.exe+14dca0. As wikipedia says, the driver is responsable for, amongh others, hardware virtualization, and here I think the HAXM driver comes in play.

During the installation of HAXM, I used the suggested size of memory of 2GB if that helps.


Downloadapplication/zip 101713-5390-01.zip18.33 KB


I'm an Android developer, i got HAXM and since yesterday win 8.1. So, blue screen at least once by hour.

I hope there will be a fix as soon as possible.



It's very easy to reproduce. I would suggest to get a copy of Windows 8.1 and give it a shot. I'm not sure why you haven't done so already. There is a long email thread at Microsoft Answers Forum so that should give you additional information. People are getting the 8.1 update now so expect moe reportings.


Yes I was interested in STOP error code.

Please run on that dump file windbg with the !analyze -v command it will give a more detailed analysis of the BSOD that the program which you have used.Can you post the fourth parameter of Bc code it should be a hex value?

Later I will look at that dump file.

I also eveloped this problem upon upgrading from 8 to 8.1.  This solved the problem for me.  You must follow the first two instructions and then restart.  It's a major bug that is causing this, but this is the tempororary work around. Good luck - Josh

I am not a developer, but I had the exact same issue (BSOD with CRITICAL_STRUCTURE_CORRUPTION error) after upgrading from 8 to 8.1.  This is how I solved it.  Make sure you restart after following the first two solutions.  Good luck - Josh G.

@JoshG2013, thanks for the link, unfortunatly those fixes won't apply to this particular issue, since for one that video is on the premise that the bug happened in Windows 8 which it didn't.

Also, they're not related to system power or missing drivers. But thanks for the try.

Also a note, seems that users of Windows 8.1 upgraded today to the public release, I assume with the GA update have also the issue... so, so much for the hope of that getting it fixed. Hopefully now that it's public release this bug will get more attention.

Would be great to have a fix for this, hoping to upgrade to 8.1 soon. Had this issue with preview build & android emulator.

Hi JoshG

As it was pointed out by Andres C it will not apply to the situation described in this thread.Hopefully the dump file can reveal the offending driver name and in that video does not show any steps related to how the culprit(driver) was indentified.

This is definately a HAXM issue. I've also experienced a number of BSODs with the critical structure error since upgrading to Windows 8.1. 

This occurs each time I run the Android emulator (with HAXM installed).

After uninstalling HAXM, the emulator runs fine without any issues (i.e. no more BSODs). Unfortunately, it's painfully slow without the acceleration, so hopefully Intel fixes this soon.

Kernel dump should reveal the offending driver(hopefully).

Same issue here. First driver verifier pointed me to Poweriso driver. Removed that one. Still got BSOD's.
Uninstaled HAXM, no problems anymore.

No problems on Windows 8.0, only now on 8.1. BSOD every 30 minutes, lost some work due to it.

Kernel minidump doesn't find anything, also driver verifier doesn't handle it. Note that Virtualbox has similar issues with Critical Structure Corrupted BSOD's in 8.1, so it certainly looks like some VT-X driver issues with Windows.

Please fix, I rely on my fast android emulators while developing.

Kernel minidump with verifier enabled:!708&authkey=!AINm...

>>>Kernel minidump doesn't find anything,>>>

Did you use windbg to analyze the crash?

Minidump should not be collected because it contains only faulting process address space.Please eneable full dump option.

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?

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.

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."

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'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...

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.

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

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.


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.


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. 


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.

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

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

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

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?


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

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)

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:

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.


Downloadapplication/zip minidump.zip99.42 KB

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?


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 *
* *

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
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.
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:







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

LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff801a9f4dca0

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


fffff801`a9f4dca0 48894c2408 mov qword ptr [rsp+8],rcx


SYMBOL_NAME: nt+14dca0



IMAGE_NAME: ntkrnlmp.exe


IMAGE_VERSION: 6.3.9600.16404

FAILURE_BUCKET_ID: 0x109_nt+14dca0

BUCKET_ID: 0x109_nt+14dca0


FAILURE_ID_HASH_STRING: km:0x109_nt+14dca0

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

Followup: MachineOwner

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

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


Downloadapplication/zip msinfo32.zip98.98 KB
Downloadtext/plain analyze-v.txt2.85 KB

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.

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


Downloadapplication/zip KERNEL.zip90.81 MB
Downloadtext/plain output.txt2.09 KB

Tomorrow I wil look at kernel dump.

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. 

Uploaded txt file.


Downloadtext/plain 0x109 BugCheck.txt760.77 KB

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..


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.


Leave a Comment

Please sign in to add a comment. Not a member? Join today