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.

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

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. 

Attachments: 

AttachmentSize
Downloadtext/plain KeBugCheckEx_call_stack.txt20.02 KB

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

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

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.

Hi Alexander

Were Intel engineers able to reconstruct the call stack?

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

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

800mb original size, compressed with 7zip.

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.

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.

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

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 

Hi Alexander 

Can you share more details?

Thanks in advance

@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

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

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

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.

Attachments: 

AttachmentSize
Downloadtext/plain kebugcheck-109-analysis-2.txt1.73 MB

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 

Quote:

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

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

Quote:

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.

@Alexander

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

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 

Is it possible to give an ETA on this fix?

Quote:

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.

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.

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 

Quote:

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.

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.

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.

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

Quote:

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.

Quote:

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.

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

For those who don't know this product : http://www.genymotion.com/

is a very good alternative until Intel release a patch for HAXM. Very fast Android emulator

Great news: The hotfix is available for download! Please go to http://software.intel.com/en-us/articles/intel-hardware-accelerated-execution-manager/ . There is a hotfix for Microsoft Windows* 8.1 and for OS X 10.9. 
Let us know if the hotfix is working for you. 

Thanks all for helping us resolving this issue!
Alex 

thank you Alex.

Thanks Alex... however, after update, the Emulator is unable to start with "use host GPU" checked. The Emulator will just load with black screen...

Just tried to uncheck "use host GPU",  the emulator loaded very fast... However, without using host GPU, inside emulator look very laggy and not smooth at all....  

Hope some updates coming soon.. Thanks.

It does seem to work with host GPU for me tho. Might be specific.

Quote:

MySKY O. wrote:

Thanks Alex... however, after update, the Emulator is unable to start with "use host GPU" checked. The Emulator will just load with black screen...

Just tried to uncheck "use host GPU",  the emulator loaded very fast... However, without using host GPU, inside emulator look very laggy and not smooth at all....  

Hope some updates coming soon.. Thanks.

The fix is working so far - No crach.  Thanks Alex

Hi all.. just uninstall and reinstall it.. now its working ..... 

Thanks all for the effort..     :)

Quote:

Andres C. wrote:

It does seem to work with host GPU for me tho. Might be specific.

Quote:

MySKY O.wrote:

Thanks Alex... however, after update, the Emulator is unable to start with "use host GPU" checked. The Emulator will just load with black screen...

Just tried to uncheck "use host GPU",  the emulator loaded very fast... However, without using host GPU, inside emulator look very laggy and not smooth at all....  

Hope some updates coming soon.. Thanks.

So far it's working fo me, also with GPU host emulation. I will wait some days to judge if it's completely fixed, but I trust Intel engineneers.

Thank you.

I installed the hotfix from  http://software.intel.com/en-us/articles/intel-hardware-accelerated-execution-manager/ . 

Then I tried to uninstall an app from emulator working with Intel Atom(x86) CPU selected, and Win 8.1 x64 crashed with the same error CRITICAL_STRUCTURE_CORRUPTION

Does the crash occure during the uninstall?

In my first attempt went wrong but I made a mistake and now it is working fine. What I did wrong was that I thought the fix was a patch for the current driver when in fact the fix is the fixed driver itself. Removed the HAXM and installed only the fix and it worked. No crash so far.

I had this issue as well, same error message whenever my computer would crash every 15-20 minutes following me installing Windows 8.1. I read a ton of forums and one person said that uninstalling the program MacDrive worked for them. I know not everybody has this program, but I did, and I don't know how it causes the problem...but uninstalling it stopped the crashing. I'm going onto my second hour without any crashing.

Also, as a random additional bit of information...when MacDrive was installed Call of Duty: Ghosts would stutter a lot and be unplayable. I thought it was just a buggy game...but when I uninstalled MacDrive the game runs normally at high settings. I don't know if you all have MacDrive, or how it is causing these problems. But uninstalling it definitely helped. I had spoken with HP Tech Support and they were telling me to restore my computer to factory settings (Windows 8), which would've led to days of me reinstalling all of my software...thank God I didn't have to do that.

Anyway, hope this works for those of you who have MacDrive on your computers. For those of you who don't, good luck.

What is MacDrive?

Quote:

iliyapolak wrote:

What is MacDrive?

MacDrive is a Windows software application where you can open, save, and transfer files on a Mac disk or drive.

http://www.mediafour.com/products/macdrive

Thanks @Ben for explaining.

@Stephen C

If you have still BSOD of MacDrive(kernel dump file) would you upload it?I am really interesting in investigation of that crash.

Thanks in advance.

@Alexander The link to the fix download is dead. Is it possible to fix this or is there another link we should use?

I was seeing this blue screen also and just came across this thread.  I installed the latest patch pointed to above, and within an hour still hit another blue screen.  Analysis from WinDbg below, which quite clearly points to the HAXM driver.  I'm running Windows 8.1 x64 on a MacBook Air.

Please let me know how I can help you get to the bottom of this issue.  This is quite impactful.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
 
FAULTING_IP: 
IntelHaxm+c3df
fffff800`0340c3df f30fc775f8      vmxon   qword ptr [rbp-8]
 
CONTEXT:  ffffd00039e8cc80 -- (.cxr 0xffffd00039e8cc80)
rax=0000000000000000 rbx=0000000000000000 rcx=000000026f527000
rdx=ffffd00039e8d770 rsi=ffffe000004a6010 rdi=ffffe000005f0310
rip=fffff8000340c3df rsp=ffffd00039e8d6b8 rbp=ffffd00039e8d6c0
 r8=ffffd00039e8d778  r9=7fffe000005f3750 r10=ffffe000005f3750
r11=7ffffffffffffffc r12=ffffe000004a6010 r13=ffffd00039e8d770
r14=ffffffffffffffff r15=0000000000000002
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
IntelHaxm+0xc3df:
fffff800`0340c3df f30fc775f8      vmxon   qword ptr [rbp-8] ss:0018:ffffd000`39e8d6b8=000000026f527000
Resetting default scope
 
DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT
 
BUGCHECK_STR:  0x3B
 
PROCESS_NAME:  emulator-x86.e
 
CURRENT_IRQL:  2
 
LAST_CONTROL_TRANSFER:  from 000000026f527000 to fffff8000340c3df
 
STACK_TEXT:  
ffffd000`39e8d6b8 00000002`6f527000 : 00000000`00000001 fffff800`0340994d 00007ffd`00000002 ffffe000`00000001 : IntelHaxm+0xc3df
ffffd000`39e8d6c0 00000000`00000001 : fffff800`0340994d 00007ffd`00000002 ffffe000`00000001 00000000`00000000 : 0x00000002`6f527000
ffffd000`39e8d6c8 fffff800`0340994d : 00007ffd`00000002 ffffe000`00000001 00000000`00000000 00000000`00000001 : 0x1
ffffd000`39e8d6d0 fffff800`034091ab : ffffe000`004a6010 ffffe000`004a6010 ffffd000`3f63f000 ffffe000`004a6010 : IntelHaxm+0x994d
ffffd000`39e8d720 fffff800`0340444a : fffff800`0340dc01 ffffe000`004a6010 ffffe000`004a6010 7fffe000`005f3750 : IntelHaxm+0x91ab
ffffd000`39e8d770 fffff800`03401607 : 00000000`00000000 ffffe000`0e67e9b0 ffffe000`0e67e9b0 00000000`00000000 : IntelHaxm+0x444a
ffffd000`39e8d7b0 fffff800`03401b4f : ffffe000`0e67e8e0 00000000`40002418 ffffe000`028f97d0 ffffd000`39e8db80 : IntelHaxm+0x1607
ffffd000`39e8d840 fffff800`6b7cf395 : ffffe000`0e67e8e0 ffffd000`39e8db80 ffffe000`028f97d0 fffff800`6b6f6180 : IntelHaxm+0x1b4f
ffffd000`39e8d870 fffff800`6b7cfd2a : 00000000`0028e4bc 00000000`0008fdb0 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x845 [d:\wbrtm\minkernel\ntos\io\iomgr\internal.c @ 10066]
ffffd000`39e8da20 fffff800`6b5608b3 : 00000000`00000001 ffffd000`39e8db80 00000000`00000000 fffff800`6b7b730e : nt!NtDeviceIoControlFile+0x56 [d:\wbrtm\minkernel\ntos\io\iomgr\devctrl.c @ 110]
ffffd000`39e8da90 00000000`77ad2772 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 [d:\wbrtm\minkernel\ntos\ke\amd64\trap.asm @ 2372]
00000000`0008ee08 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x77ad2772
 
 
FOLLOWUP_IP: 
IntelHaxm+c3df
fffff800`0340c3df f30fc775f8      vmxon   qword ptr [rbp-8]
 
SYMBOL_STACK_INDEX:  0
 
SYMBOL_NAME:  IntelHaxm+c3df
 
MODULE_NAME: IntelHaxm
 
IMAGE_NAME:  IntelHaxm.sys
 
DEBUG_FLR_IMAGE_TIMESTAMP:  52784488
 
STACK_COMMAND:  .cxr 0xffffd00039e8cc80 ; kb
 
FAILURE_BUCKET_ID:  0x3B_IntelHaxm+c3df
 
BUCKET_ID:  0x3B_IntelHaxm+c3df
 
ANALYSIS_SOURCE:  KM
 
FAILURE_ID_HASH_STRING:  km:0x3b_intelhaxm+c3df
 
FAILURE_ID_HASH:  {7ce3553e-56e5-47fb-c62f-3ac19ef94b86}
 

Pages

Leave a Comment

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