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

[Bernard]

@Alexander 

I made little progress and I was able to find that NtTib.Exceptions points to GDT address and the same address is passed to KeBugCheckEx in register R9 and I suppose that the BSOD is related to GDT corruption on processor 0.Still was not able to find which part of code corrupts GDT.

Can you confirm this?

Thanks

[Peter_d_]

@Alexander: good to hear! Would love to test it here!

[Bernard]

Tomorrow I will upload my crash dump analysis.Unfortunately I was not able to reconstruct the call stackwhich led to BSOD.

[Bernard]

Hi Peter d

Did extensive manual analysis of your kernel dump file.Unfortunately I was not able to find the culprit.As I pointed it out in my previous posts windbg automated analysis does not work and I am not able to find the exact instruction which caused the BSOD I suppose that somehow PatchGuard could be involved for example by obscuring the call stack or paging it out.

As usual I uploaded a text file of analysis and I hope that it could help somehow to solve the problem.

[Alexander_W_Intel]

Hi,

We have confirmed that we found the root cause of this issue. It's related to the GDT. The Intel HaXM team is testing an update to support newly released OSes (Microsoft Windows* 8.1 and OS X Mavericks*).  This will probably take some days until we fully validated it. I will keep you updated.

Thanks,
Alex 

[Matteo_A_]

Alexander Weggerle (Intel) wrote:

Hi,

We have confirmed that we found the root cause of this issue. It's related to the GDT. The Intel HaXM team is testing an update to support newly released OSes (Microsoft Windows* 8.1 and OS X Mavericks*).  This will probably take some days until we fully validated it. I will keep you updated.

Thanks,
Alex 

I'm very glad to hear that. Thank you, I hope this fix will really take only few days :D

[Vincent_P_1]

Yes, a very good news. Thanks everyone for your investigation

[Bernard]

Alexander Weggerle (Intel) wrote:

Hi,

We have confirmed that we found the root cause of this issue. It's related to the GDT. The Intel HaXM team is testing an update to support newly released OSes (Microsoft Windows* 8.1 and OS X Mavericks*).  This will probably take some days until we fully validated it. I will keep you updated.

Thanks,
Alex 

Glad that my analysis worked.Can you post more details?Here I mean was the culprit related to overwriting 8 and 9 selector in GDT?

Thanks in advance.

[Bernard]

@Alexander

Were you able to reconstruct the call stack prior to BSOD despite of PatchGuard?

[Alexander_W_Intel]

iliyapolak wrote:

@Alexander
Were you able to reconstruct the call stack prior to BSOD despite of PatchGuard?

No not really. The HAXM development team found out that this is related to the GDT and so could really quickly nail down the issue. 

Thanks a lot for you help!
Alex 

[Luke_H_]

Is it possible to give an ETA on this fix?

[Bernard]

Alexander Weggerle (Intel) wrote:

Quote:

iliyapolak wrote:
@Alexander
Were you able to reconstruct the call stack prior to BSOD despite of PatchGuard?

No not really. The HAXM development team found out that this is related to the GDT and so could really quickly nail down the issue. 

Thanks a lot for you help!
Alex 

You are welcome.

[Bernard]

By reading analysis of PatchGuard 3 (uninformed.org) it was mentioned in that article that  executing thread's call stack probably that one which modified critical structures will be zeroed by PG before calling KeBugCheckEx.

[Alexander_W_Intel]

Luke H. wrote:

Is it possible to give an ETA on this fix?

I assume it's somewhere between a few days and two weeks. We know that a lot of people are waiting for the fix, so we try to release it as fast as possible.

Thanks for your patience!
Alex 

[Luke_H_]

Alexander Weggerle (Intel) wrote:

Quote:

Luke H. wrote:
Is it possible to give an ETA on this fix?

I assume it's somewhere between a few days and two weeks. We know that a lot of people are waiting for the fix, so we try to release it as fast as possible.

Thanks for your patience!
Alex 

Thanks for the update.

[Ivan_P_1]

It is outrageous that bugs like this one were not caught neither by Microsoft nor Intel. I am an Android developer and use the HAXM driver to speed up my Android emulator.

Since I upgraded to Windows 8.1 I started getting those intermittent crashes.Thought that it was some driver incompatibility, but even after a crash course in Windows memory dump analysis and kernel debugging I could not identify the problematic driver. I did a clean reinstall of Windows using only the microsoft provided default drivers for my laptop's hardware. Unfortunately I did install the Intel HAXM driver again as I simply did not think of this piece of software as a driver and I just ignored it as a possible culprit. Needless to say my system went on crashing.

I became convinced that it was some kind of intermittent hardware malfunction so I bought a new laptop as I need a stable machine for my work. After I got exactly the same crash on my new laptop 30 minutes after I installed my development environment I suddenly realized that the HAXM driver might gave something to do with it. With this information I was able to Google this thread.

This bug cost me $1700 for the new laptop I did not actually need. As I said I am outraged.

[sav_s_]

Windows 8.1 consumer preview is available since June 26, 2013. This issue was first reported in Microsoft forums on June 30, 2013. I added it here a month ago when I saw the issue. It took another month for Intel engineers to even reproduce the issue, even with great community help, when it's clearly 100% reproducible.

It appears to be a problem in Intel development process where they lack timely testing on new OS releases or major OS updates. You can't release system software and then live in a vacuum.

[Bernard]

,>>> but even after a crash course in Windows memory dump analysis and kernel debugging I could not identify the problematic driver>>>

Yes I agree with you.

You can look at my uploaded text files of my attempt to find the culprit.Altough the corrupted structure was not so hard to identify(GDT address was passed in R9 register) and checking processor 0 control region  NtTib.Exceptions member revealed the same address.Initially I suspected the PatchGuard of beign involved in zeroing offending thread kernel mode stack,but was not able to find any source of information about the windbg inability to perform automated analysis(!analyze -v) when PG is involved in BSOD.Later I came to conclusion that Win OS does not have any hardware support needed to check the integrity of critical structures so it must rely on software to do it.And knowing the PG scanning interval ~10-15 min I thought that it maybe impossible to find the offending instruction which modified GDT because kernel mode stack could have been paged out.

[anonymous_s_]

Ivan P. wrote:

It is outrageous that bugs like this one were not caught neither by Microsoft nor Intel. I am an Android developer and use the HAXM driver to speed up my Android emulator.

<...deleted .>

This bug cost me $1700 for the new laptop I did not actually need. As I said I am outraged.

Let me preface I rarely resond to posts like this but I feel you are so over teh top that I had to.

Hmm... did you stop to check the Android bug reports?   I put one there a two weeks ago and Google responded the next day it was a known issue with HAXM and directed me to this thread.   I'm taken aback at your hostility towards Intel... while it does seem there was a delay in initially getting to work on this problem. to blame them for your decision to buy new hardware?   I've been around computers for a long time, but only recently started coding in java and for android (decades ago having worked on maiinframes in cobol and fortran) and I can honestly say I never ever would have considered this to be my hardware fault.  It was pretty obvious to be a problem with the emulator after the windows 8.1 update.  System works fine before update.  System works fine after update except  BSOD when I run emulator.

Perhaps next time take a deep breath and search a bit harder for other reports with same symptons before something so drastic.

[Ivan_P_1]

anonymous s. wrote:

Hmm... did you stop to check the Android bug reports?   I put one there a two weeks ago and Google responded the next day it was a known issue with HAXM and directed me to this thread.  

Unfortunately there was nothing in the crash to point me in the direction of the Android development environment - as it is Java based I do not tend to think about it as capable to cause such kinds of issues. Googling about this kind of error (gdt critical structure corruption & Windows 8.1) did not return any results to indicate that HAXM was the problem. Most of the info I was able to gather from the web was that this could be caused either by a driver problem or a hardware malfunction. I actually suspected that the issue was driver-related, so I played with the Windows driver verifier and  WinDbg analyzing the crash dumps, but as I said above I could not find anything to point me to a specific driver. After I did a clean reinstall of Windows 8.1 with only the Microsoft provided device drivers and I still was getting those crashes I began to think that it was a hardware problem that coincided with my Windows 8.1 upgrade.

[Bernard]

>>>Unfortunately there was nothing in the crash to point me in the direction of the Android development environment>>>

You can get some clues by looking at BSOD codes.In my cases two of uploaded dump files have the minor code set to 0x3 which points to corrupted internal structure.

>>> WinDbg analyzing the crash dumps>>>

Were you able to run successfully !analyze -v command?