VMware Cloud Community
_operator
Contributor
Contributor
Jump to solution

Windows 10 instance crashes 24 hours after reverting from a snapshot

Hi,

I'm having trouble with my Windows 10 Technical preview instance and I was thinking if you could help me. All help is very much appreciated.

Host: HP BL460c (intel)

Esxi 5.5

Guest OS: Windows 10 Technical Preview Build 10061

VM version 10

2 CPU's, 8gb memory

When the Guest OS has been powered on AND nobody has used it for exactly 24 hours it crashes. So I revert it from a snapshot and after 24 hours it goes down. If I look at the events in vCenter I can see: "VMware ESX unrecoverable error: (vcpu-0) NOT_REACHED bora/devices/ahci/ahci_user.c:1521" I know it is not a supported Windows version but I was hoping someone might know what this error means and maybe point me to the right direction. All previous windows 10 builds have worked perfectly and from the Windows logs it seems just like someone suddenly pulled the power cord so no luck there.

From the log just before the crash:

2015-04-27T08:17:05.726Z| vcpu-0| I120: NOT_REACHED bora/devices/ahci/ahci_user.c:1521

2015-04-27T08:17:10.375Z| vcpu-0| W110: A core file is available in "/vmfs/volumes/543d0569-8bfc70dd-5584-0017a4770408/WINDOWS 10/vmx-zdump.001"

2015-04-27T08:17:10.375Z| vcpu-0| W110: Writing monitor corefile "/vmfs/volumes/543d0569-8bfc70dd-5584-0017a4770408/WINDOWS 10/vmmcores.gz"

2015-04-27T08:17:10.610Z| vcpu-0| I120: Counting amount of anonymous memory

2015-04-27T08:17:10.628Z| vcpu-0| I120: Total Count of Anon Pages and CR3 pages 8924

2015-04-27T08:17:10.635Z| vcpu-0| W110: Dumping core for vcpu-0

2015-04-27T08:17:10.635Z| vcpu-0| I120: CoreDump: dumping core with superuser privileges

2015-04-27T08:17:10.635Z| vcpu-0| I120: VMK Stack for vcpu 0 is at 0x4123a0c55000

2015-04-27T08:17:10.635Z| vcpu-0| I120: Beginning monitor coredump

2015-04-27T08:17:11.947Z| vcpu-0| I120: End monitor coredump

2015-04-27T08:17:11.948Z| vcpu-0| W110: Dumping core for vcpu-1

2015-04-27T08:17:11.948Z| vcpu-0| I120: CoreDump: dumping core with superuser privileges

2015-04-27T08:17:11.948Z| vcpu-0| I120: VMK Stack for vcpu 1 is at 0x4123a0cd5000

2015-04-27T08:17:11.948Z| vcpu-0| I120: Beginning monitor coredump

2015-04-27T08:17:12.828Z| vcpu-0| I120: End monitor coredump

2015-04-27T08:17:12.829Z| vcpu-0| W110: Dumping extended monitor data

2015-04-27T08:17:16.162Z| vcpu-0| I120: CoreDump: ei->size 53374976 : len = 53374976

2015-04-27T08:17:16.177Z| vcpu-0| I120: Backtrace:

2015-04-27T08:17:16.177Z| vcpu-0| I120: Backtrace[0] 000003fffe592190 rip=00000000237be60e rbx=00000000237bdde0 rbp=000003fffe5921b0 r12=0000000000000000 r13=000003fffdb29100 r14=0000000000000000

r15=00000000325d1700

2015-04-27T08:17:16.177Z| vcpu-0| I120: Backtrace[1] 000003fffe5921c0 rip=00000000231e6805 rbx=00000000241bf148 rbp=000003fffe5926b0 r12=0000000000000001 r13=000003fffdb29100 r14=0000000000000000

r15=00000000325d1700

2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[2] 000003fffe5926c0 rip=00000000234ef288 rbx=000003fffdb27930 rbp=000003fffe5926e0 r12=00000000325d3078 r13=000003fffdb29100 r14=0000000000000000 r15=00000000325d1700

2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[3] 000003fffe5926f0 rip=00000000234efcdc rbx=000003fffdb27930 rbp=000003fffe592c60 r12=000004001a59f480 r13=000003fffdb29100 r14=0000000000000000 r15=00000000325d1700

2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[4] 000003fffe592c70 rip=0000000023387950 rbx=00000000325d1700 rbp=000003fffe592ce0 r12=0000000000000000 r13=000000000000017a r14=000003fffdb2e100

r15=00000000323b8a30

2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[5] 000003fffe592cf0 rip=0000000023536b9d rbx=00000000243083e0 rbp=000003fffe592d20 r12=0000000024063c00 r13=000000000000017a r14=000003fffdb2e100

r15=00000000323b8a30

2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[6] 000003fffe592d30 rip=0000000023568b3e rbx=0000000000000000 rbp=000003fffe592d70 r12=000000000000012d r13=00000000241bf148 r14=00000000243032e0

r15=0000000024183080

2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[7] 000003fffe592d80 rip=0000000023536ca9 rbx=00000000241cb3a8 rbp=000003fffe592d80 r12=0000000032383cb0 r13=0000000000000000 r14=0000000000000000

r15=0000000000000000

2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[8] 000003fffe592d90 rip=00000000232c8ad8 rbx=00000000241cb3a8 rbp=000003fffe592ec0 r12=0000000032383cb0 r13=0000000000000000 r14=0000000000000000

r15=0000000000000000

2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[9] 000003fffe592ed0 rip=00000000243b7ddc rbx=0000000000000000 rbp=0000000000000000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000

r15=0000000000000000

2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[10] 000003fffe592fe0 rip=0000000024a041cd rbx=0000000000000000 rbp=0000000000000000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000

r15=0000000000000000

2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[11] 000003fffe592fe8 rip=0000000000000000 rbx=0000000000000000 rbp=0000000000000000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000

r15=0000000000000000

2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[0] 000003fffe592190 rip=00000000237be60e in function (null) in object /bin/vmx loaded at 0000000023071000

2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[1] 000003fffe5921c0 rip=00000000231e6805 in function (null) in object /bin/vmx loaded at 0000000023071000

2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[2] 000003fffe5926c0 rip=00000000234ef288 in function (null) in object /bin/vmx loaded at 0000000023071000

2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[3] 000003fffe5926f0 rip=00000000234efcdc in function (null) in object /bin/vmx loaded at 0000000023071000

2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[4] 000003fffe592c70 rip=0000000023387950 in function (null) in object /bin/vmx loaded at 0000000023071000

2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[5] 000003fffe592cf0 rip=0000000023536b9d in function (null) in object /bin/vmx loaded at 0000000023071000

2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[6] 000003fffe592d30 rip=0000000023568b3e in function (null) in object /bin/vmx loaded at 0000000023071000

2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[7] 000003fffe592d80 rip=0000000023536ca9 in function (null) in object /bin/vmx loaded at 0000000023071000

2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[8] 000003fffe592d90 rip=00000000232c8ad8 in function (null) in object /bin/vmx loaded at 0000000023071000

2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[9] 000003fffe592ed0 rip=00000000243b7ddc in function (null) in object /lib64/libpthread.so.0 loaded at 00000000243b0000

2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[10] 000003fffe592fe0 rip=0000000024a041cd in function clone in object /lib64/libc.so.6 loaded at 0000000024931000

2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[11] 000003fffe592fe8 rip=0000000000000000

2015-04-27T08:17:16.178Z| vcpu-0| I120: Msg_Post: Error

2015-04-27T08:17:16.178Z| vcpu-0| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-0)

2015-04-27T08:17:16.178Z| vcpu-0| I120+ NOT_REACHED bora/devices/ahci/ahci_user.c:1521

2015-04-27T08:17:16.178Z| vcpu-0| I120: [msg.panic.haveLog] A log file is available in "/vmfs/volumes/543d0569-8bfc70dd-5584-0017a4770408/WINDOWS 10/vmware.log".

2015-04-27T08:17:16.178Z| vcpu-0| I120: [msg.panic.requestSupport.withoutLog] You can request support.

2015-04-27T08:17:16.178Z| vcpu-0| I120: [msg.panic.requestSupport.vmSupport.vmx86]

2015-04-27T08:17:16.178Z| vcpu-0| I120+ To collect data to submit to VMware technical support, run "vm-support".

2015-04-27T08:17:16.178Z| vcpu-0| I120: [msg.panic.response] We will respond on the basis of your support entitlement.

2015-04-27T08:17:16.178Z| vcpu-0| I120: ----------------------------------------

2015-04-27T08:17:16.188Z| vcpu-0| I120: Exiting

Have you experienced something similar or can you tell what seems to be the issue? Thank you very much for your help!

1 Solution

Accepted Solutions
csteaderman
Contributor
Contributor
Jump to solution

I was able to avoid the crash (no crash in 25 hours) by changing the CD/DVD drive Virtual Device Node from SATA to IDE and then removing the SATA Controller Device.

View solution in original post

7 Replies
vmwarevirtual
Contributor
Contributor
Jump to solution

Hi _operator ,

Me too, i also got the same kind of error messages . But my situation was run the windows server 2016 technical review on vmware workstation 11 . It seems that the current vmware product not yet well supported this kind of version . Waiting the update version to fix this issues out .

error_vmwareworkstaiton11.JPG

dariusd
VMware Employee
VMware Employee
Jump to solution

(Crossposting from VMware VMX Crash Running Win 10 x64 Build 10074, where the same problem is being discussed.)

We have a fix queued up for the next patch release to address this problem.

It turns out that the most recent builds of Windows 10 will sometimes issue S.M.A.R.T. commands to SATA devices even when the device reports that it does not support S.M.A.R.T., and the unexpected commands are confusing our SATA emulation and leading to the error you're seeing.

The fix will simply ignore the unexpected S.M.A.R.T. commands.

I can't say exactly when we'll have the update in your hands, but I'm hoping it will be reasonably soon.  Sorry for the trouble you've all encountered!

Thanks,

--

Darius

csteaderman
Contributor
Contributor
Jump to solution

I was able to avoid the crash (no crash in 25 hours) by changing the CD/DVD drive Virtual Device Node from SATA to IDE and then removing the SATA Controller Device.

_operator
Contributor
Contributor
Jump to solution

csteaderman that did the trick, thank you very much!!

Thanks others also for quick responses, you were most helpful

Reply
0 Kudos
vadonka
Enthusiast
Enthusiast
Jump to solution

Thank You for the workaround. I can confirm this help to avoid the issue. Waiting for the fix from the vmware team! !

Reply
0 Kudos
srwsol
Hot Shot
Hot Shot
Jump to solution

This also fixed my Windows 10 problems.  I was getting the error within 24 hours of running any Windows 10 VM under ESXi 6, even if I hadn't reverted from a snapshot.  The VM simply wasn't running when I went back after a while to do something with it.  You have to scan the event log to see that this error occurred, so if you simply see that your Windows 10 VM has shutdown for no obvious reason, this is probably the problem.  At first I thought I had some sort of activation issue.

Reply
0 Kudos
bkmemeo
Contributor
Contributor
Jump to solution

For those who do not get this resolved by changing SATA to IDE, the "correct" answer is that it's a bug, and that it is now supposedly fixed:

Resolution:- Upgrade the ESXi to 6.0 U1b

http://pubs.vmware.com/Release_Notes/en/vsphere/60/vsphere-esxi-60u1b-release-notes.html
 

        Windows 10 VM VMX fails        The Windows 10 VM vmx process fails with an error message similar to the following in the vmware.log file:

    NOT_REACHED bora/devices/ahci/ahci_user.c:1530

         This issue is resolved in this release.

If it does not resolve the problem, I will update this posting.

For those who aren't ready to upgrade, the workaround for me has been to shutdown the VM, and remove the CDROM altogether, and reboot.

Reply
0 Kudos