Win7 on Workstation 11 flaming out

goldeneye_007 · ‎01-22-2015

No idea what is going on with this VM. Flames out with 'unrecoverable Error vcpu-0, contact support'.

A basic VM 40GB disk, uniprocessor 1GB memory, nothing fancy.

Workstation 11 running on OpenSUSE 13.2.

vmware.log entries:

5-01-22T16:41:53-05:00[+0.009]| vcpu-0| W110: Caught signal 11 -- tid 15374 (addr 0)

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: SIGNAL: rip 0x0 rsp 0x7f8ef0ae8bf8 rbp 0x4

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: SIGNAL: rax 0x0 rbx 0x2b4d3f8 rcx 0x18 rdx 0xc9b860 rsi 0x7f8ef0ae8ca0 rdi 0x7f8e90008e80

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: r8 0x2b26a58 r9 0x4000001 r10 0x1 r11 0x3246 r12 0x164 r13 0x7f8ef7ac4ec0 r14 0x29aa060 r15 0x7f8ef7ac4ec0

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: SIGNAL: stack 7F8EF0AE8BF8 : 0x0000000000738a2d 0x00007f8ef7ac4f28

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: SIGNAL: stack 7F8EF0AE8C08 : 0xffffffff00000004 0x00000004f241f748

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: SIGNAL: stack 7F8EF0AE8C18 : 0x0000000002b48ea0 0x0000000002b48ea0

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: SIGNAL: stack 7F8EF0AE8C28 : 0x000000000003f8da 0x0000000000000004

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: SIGNAL: stack 7F8EF0AE8C38 : 0x00000004004bccae 0x00007f8ef7ac4ec0

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: SIGNAL: stack 7F8EF0AE8C48 : 0x00007f8e90061750 0x00007f8ef7a91740

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: SIGNAL: stack 7F8EF0AE8C58 : 0x0000000000487dd5 0x0000000000000000

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: SIGNAL: stack 7F8EF0AE8C68 : 0x00007f8ef7ac4ec0 0x00007f8ef7a64fc0

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: Backtrace:

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: Backtrace[0] 00007f8ef0ae8520 rip=00000000004f306e rbx=00000000004f2e40 rbp=0000000000000000 r12=00007f8ef0ae9680 r13=00007f8ef0ae8c78 r14=00007f8ef0ae8c78 r15=000000000000000b

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: Backtrace[1] 00007f8ef0ae8550 rip=0000000000462c89 rbx=000000000000000b rbp=0000000000000004 r12=00007f8ef0ae9680 r13=00007f8ef0ae8c78 r14=00007f8ef0ae8c78 r15=000000000000000b

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: Backtrace[2] 00007f8ef0ae8640 rip=00007f8ef7249890 rbx=0000000002b4d3f8 rbp=0000000000000004 r12=0000000000000164 r13=00007f8ef7ac4ec0 r14=00000000029aa060 r15=00007f8ef7ac4ec0

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: Backtrace[3] 00007f8ef0ae8bf8 rip=0000000000000000 rbx=0000000002b4d3f8 rbp=0000000000000004 r12=0000000000000164 r13=00007f8ef7ac4ec0 r14=00000000029aa060 r15=00007f8ef7ac4ec0

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: SymBacktrace[0] 00007f8ef0ae8520 rip=00000000004f306e in function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0000000000400000

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: SymBacktrace[1] 00007f8ef0ae8550 rip=0000000000462c89 in function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0000000000400000

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: SymBacktrace[2] 00007f8ef0ae8640 rip=00007f8ef7249890 in function (null) in object /lib64/libpthread.so.0 loaded at 00007f8ef723a000

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: SymBacktrace[3] 00007f8ef0ae8bf8 rip=0000000000000000

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| I120: Unexpected signal: 11.

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| W110:

2015-01-22T16:41:53-05:00[+0.009]| vcpu-0| W110+ The core dump limit is set to ZERO; no core dump should be expected

2015-01-22T16:41:53-05:00[+0.014]| vcpu-0| W110: Child process 15392 failed to dump core (status 0x6).

2015-01-22T16:41:53-05:00[+0.014]| vcpu-0| W110: Writing monitor corefile "/home/vmware/Windows7/vmmcores.gz"

2015-01-22T16:41:53-05:00[+0.015]| vcpu-0| W110: Dumping core for vcpu-0

2015-01-22T16:41:53-05:00[+0.015]| vcpu-0| I120: Beginning monitor coredump

2015-01-22T16:41:53-05:00[+0.475]| vcpu-0| I120: End monitor coredump

2015-01-22T16:41:53-05:00[+0.766]| vcpu-0| I120: Coredump encountered overflow 1525:1525 (351 duplicates)

2015-01-22T16:41:53-05:00[+0.886]| vcpu-0| I120: Backtrace:

2015-01-22T16:41:53-05:00[+0.886]| vcpu-0| I120: Backtrace[0] 00007f8ef0ae8020 rip=00000000004f306e rbx=00000000004f2e40 rbp=0000000000000000 r12=0000000000000001 r13=00007f8ef0ae8c78 r14=00007f8ef0ae8c78 r15=000000000000000b

2015-01-22T16:41:53-05:00[+0.886]| vcpu-0| I120: Backtrace[1] 00007f8ef0ae8050 rip=00000000004ce229 rbx=00007f8ef0ae8070 rbp=00000000014c4260 r12=0000000000000001 r13=00007f8ef0ae8c78 r14=00007f8ef0ae8c78 r15=000000000000000b

2015-01-22T16:41:53-05:00[+0.886]| vcpu-0| I120: Backtrace[2] 00007f8ef0ae8550 rip=0000000000462cd8 rbx=000000000000000b rbp=00007f8ef0ae8580 r12=00007f8ef0ae9680 r13=00007f8ef0ae8c78 r14=00007f8ef0ae8c78 r15=000000000000000b

2015-01-22T16:41:53-05:00[+0.886]| vcpu-0| I120: Backtrace[3] 00007f8ef0ae8640 rip=00007f8ef7249890 rbx=0000000002b4d3f8 rbp=0000000000000004 r12=0000000000000164 r13=00007f8ef7ac4ec0 r14=00000000029aa060 r15=00007f8ef7ac4ec0

2015-01-22T16:41:53-05:00[+0.886]| vcpu-0| I120: Backtrace[4] 00007f8ef0ae8bf8 rip=0000000000000000 rbx=0000000002b4d3f8 rbp=0000000000000004 r12=0000000000000164 r13=00007f8ef7ac4ec0 r14=00000000029aa060 r15=00007f8ef7ac4ec0

2015-01-22T16:41:53-05:00[+0.886]| vcpu-0| I120: SymBacktrace[0] 00007f8ef0ae8020 rip=00000000004f306e in function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0000000000400000

2015-01-22T16:41:53-05:00[+0.886]| vcpu-0| I120: SymBacktrace[1] 00007f8ef0ae8050 rip=00000000004ce229 in function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0000000000400000

2015-01-22T16:41:53-05:00[+0.886]| vcpu-0| I120: SymBacktrace[2] 00007f8ef0ae8550 rip=0000000000462cd8 in function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0000000000400000

2015-01-22T16:41:53-05:00[+0.886]| vcpu-0| I120: SymBacktrace[3] 00007f8ef0ae8640 rip=00007f8ef7249890 in function (null) in object /lib64/libpthread.so.0 loaded at 00007f8ef723a000

2015-01-22T16:41:53-05:00[+0.886]| vcpu-0| I120: SymBacktrace[4] 00007f8ef0ae8bf8 rip=0000000000000000

2015-01-22T16:41:53-05:00[+0.887]| vcpu-0| I120: Msg_Post: Error

2015-01-22T16:41:53-05:00[+0.887]| vcpu-0| I120: [msg.log.error.unrecoverable] VMware Workstation unrecoverable error: (vcpu-0)

2015-01-22T16:41:53-05:00[+0.887]| vcpu-0| I120+ Unexpected signal: 11.

2015-01-22T16:41:53-05:00[+0.887]| vcpu-0| I120: [msg.panic.haveLog] A log file is available in "/home/vmware/Windows7/vmware.log".

2015-01-22T16:41:53-05:00[+0.887]| vcpu-0| I120: [msg.panic.requestSupport.withoutLog] You can request support.

2015-01-22T16:41:53-05:00[+0.887]| vcpu-0| I120: [msg.panic.requestSupport.vmSupport.windowsOrLinux]

2015-01-22T16:41:53-05:00[+0.887]| vcpu-0| I120+ To collect data to submit to VMware support, choose "Collect Support Data" from the Help menu.

2015-01-22T16:41:53-05:00[+0.887]| vcpu-0| I120+ You can also run the "vm-support" script in the Workstation folder directly.

2015-01-22T16:41:53-05:00[+0.887]| vcpu-0| I120: [msg.panic.response] We will respond on the basis of your support entitlement.

2015-01-22T16:41:53-05:00[+0.887]| vcpu-0| I120: ----------------------------------------

2015-01-22T16:41:53-05:00[+7.309]| vcpu-0| I120: Exiting

goldeneye_007 · ‎01-22-2015

Oh and Windows boots to login screen before flaming.

If I boot into Safe Mode it actually works. I'm figuring it's a Windows problem,

but haven't been able to confirm or deny.

dariusd · ‎01-22-2015

It would seem unlikely that this is a Windows problem... Windows should not be able to cause a signal 11 on the host side. When the guest boots in safe mode, it will generally be much more "gentle" on the emulated hardware, which could definitely mask a problem in Workstation or in the set of packages installed on your Linux host.

Could you please attach the whole vmware.log? Instead of copy-and-paste, please use the Browse... button below the compose window when preparing a reply to this thread.

Thanks,

--

Darius

goldeneye_007 · ‎01-22-2015

I have managed to get it to boot by disabling EVERYTHING that could possibly be set to status 'connected' at boot time.

Will do some more testing to see what the culprit is.

goldeneye_007 · ‎01-22-2015

It is a problem with the host audio system apparently.

When I check the connect sound at boot I receive the vcpu-0 error.

If I uncheck it before I boot, Win7 loads normally.

goldeneye_007 · ‎01-22-2015

Okay so I made some changes to my host audio system. Specifically switched from Gstreamer to VLC as the backened,

and set the preferred provider to Pulse audio from Alsa (which I use for other things). Then I booted into windows

with the sound card deactivated in VMware, went into windows device manager de-installed the high def audio device, rebooted windows

with sound device still set to not connect during boot in VMware, Windows recognized the high def audio hardware (even though not connected to VM)

and re-installed its drivers. Next I checked Connected on the sound card and ran some tests in Windows against the sound system. All is working.

Finally I rebooted the machine with Sound set to Connected in VMware. All is well. Bizarre...only two hours work to fix

dariusd · ‎01-22-2015

FYI, "disconnecting" the HD Audio device is somewhat similar to unplugging the speakers/line-out from the sound card... It does not remove the sound card from the VM's PCI/PCIe bus.

From your description, it sounds like it might have been a bug in the host's ALSA library (or an incompatibility between Workstation and the host's ALSA library), although we'd probably need to reproduce the issue here (or at least see the vmware.log from the crash) to confirm.

Cheers,

--

Darius

Steven_Hirsch · ‎12-17-2015

Thanks for posting this! I was just burned by the same issue. I've been using VMware 11 on a Ubuntu 12.04 host and spent most of today migrating to Ubuntu 14.04.3 on the same system (new drive). After bringing up the new system my Win 7 guest started blowing up in the exact manner you describe. Fix was the same: Disable audio on boot, start Win 7, remove device driver, restart, connect audio - all is well!

In my case the difference seems to be the use of pulseaudio in the new system. In the Ubuntu 12.04 era, pulse audio was better termed "pulse, but no audio", so I had long ago ripped it out.