Hi
I have been running VMWare Workstation Pro for years but have not used it during the past 2-3 weeks, during which time I have upgraded from WS 12.0 to 12.1 and applied the latest Windows 10 patches.
Now I cannot run any VM's, I get a BSOD every time I attempt to start one followed by a forced reload due to a Windows "Clock_Watchdog_Timeout" error...
Any advice or help would be greatly appreciated.
Would you please upload the BSOD dump file and the vmware.log? thanks
Good day.
Thank you for the reply.
I uninstalled the "VMWare Workstation Enhanced Keyboard Driver" and that resolved the issue I had.
I am experiencing the same problem on a Win 10 64 bit host running 1511
I upgraded from Windows 8.1 a week ago and am experiencing the clock_watchdog BSOD randomly when trying to run a Ubuntu guest.
Have noted that the VMware Authorization Service is not being started at boot (although this is random)
Tried repair install of VMWare Workstation 12.1, sometime the VM guest will then start other times it crashes with clock_watchdog BSOD
The VMware Workstation 12.1 product is really unusable until this issue is fixed by the VMware team.
Could someone please advise how to fix this?
Peter
Wonder if this is related to the bridging issues?
When I upgraded to Win 10, the bridged network was not available in my VMs, did the restore default in the Virtual Network Editor thing and then it seemed to work. Then the random BSODs starting again when trying to start the VMs.
When a bridged VM did start it was very slow to get going and the Win 10 desktop (outside the VM window) became a bit unresponsive, shutting down the VM improved response on the Win 10 desktop.
Changing the VMs to NAT seems to work fine with no impact to the Win 10 desktop or other apps running.
Wonder if there is some compatibility issue with the VMware bridged network driver (in 12.1) and Win 10 1511?
I had a whole lot of customized networks to accommodate Cisco VIRL. At some point in the course of upgrading to 12.1.0 and/or uninstalling the enhanced keyboard driver, my virtual networks are got reset to default 😞 which includes one bridged network. At present all is working reliably for me, will just have to setup all the virtual networks again.
Not sure if this helps at all...
I am still getting this wretched problem, tried everything I can think of...reset VM network settings...repair install of VMware Workstation 12.1
Keep getting these random BSODs...got two in a row today.
Basically, version 12.1 is unusable....
The only way I could get my VMs to start was to do the following at each and every boot....
Run Virtual Network Editor, change settings, restore defaults, changed bridged from Automatic to Intel network device.
This then did its stuff and restarted VMWare services.
I did notice after reboot from BSOD that often the following services were not automatically started (Event log confirmed this)
- VMware Authorization Service
- VMware Workstation Server
After doing the restore defaults (above) these along with the other VMware services are now in running state.
Guess then I need to do the restore defaults after each and every boot until VMware fix 12.1?
Any other suggestions to fix this please?
Thanks
Peter
Hi, PeterEvans59:
Would you please upload the "Collected support data" and the windows dump files ? Thank you very much
Hi,
Happy to provide minidump and support data, but is there a more secure way of doing this rather than posting to an open forum?
Peter
Hi, Peter:
Then would you please upload the info to my personal mail ? wangyan3688639@gmail.com, thanks.
Hi,
Randomly, Windows 10 Pro 64-but host will crash with BSOD when trying to start Linux VM.
This occurs when the following services are not running:
- VMware authorisation service
- VMware server service
Sometimes Windows boots with the above services started and VMs start fine.
If these are not started at boot which is random 1 out of 3 boots, then BSOD occurs unless the above services are started.
This is totally reproducible.
Issue is why do those services not always start at boot, I have tried to find a pattern but have been unsuccessful.
Peter
Hello, I recently turned back on my windows xp vm which I havent used for a couple months or so and I have been getting this bsod clock watchdog timeout error(using workstation 12.0)... Sometimes I was able to get into my account on my xp vm and then it would do that or it would do it during the boot process it has just been all over the place... I have tried messing with the vm settings(RAM, graphics memory, etc) but with pretty much the same results and even tried the repair option for the program with no effect. I am doing this on a laptop and I would have had it for a couple of years now about. I have a AMD A8 cpu and my laptop is a DELL Inspiron 15 3000 series. So I guess I am at least trying to figure out what the heck is wrong with it since I know vmware can work with this make and model of computer since it used to work fine... I am convinced it might be the cpu is either getting old(Doubt it but maybe), cpu is overheating because of thermal paste wearing out, or something else. Do you need any vm dump files to ascertain this since I saw a post of you helping people with a similar issue to mine.
Sincerely, Matt Metschan
i have same issue when i use Windows 10 ver 1803 Vmware Workstation 15.0.
Host guest is Ubuntu18.04.
it cost a BSOD or Host Frezz,When i start a Java 1.6 docker container.
Here is a sample of Dockerfile
and Menory.dmp
Microsoft (R) Windows Debugger Version 10.0.17763.1 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available.
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 17134 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 17134.1.amd64fre.rs4_release.180410-1804
Machine Name:
Kernel base = 0xfffff802`3b61b000 PsLoadedModuleList = 0xfffff802`3b9c9210
Debug session time: Thu Oct 4 14:58:32.133 2018 (UTC + 8:00)
System Uptime: 0 days 1:05:34.969
Loading Kernel Symbols
...............................................................
................................................................
................................................................
................
Loading User Symbols
PEB is paged out (Peb.Ldr = 000000ba`213fb018). Type ".hh dbgerr001" for details
Loading unloaded module list
............
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 101, {18, 0, ffff8000aa666180, 2}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
Followup: MachineOwner
---------
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 0000000000000018, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: ffff8000aa666180, The PRCB address of the hung processor.
Arg4: 0000000000000002, The index of the hung processor.
Debugging Details:
------------------
KEY_VALUES_STRING: 1
STACKHASH_ANALYSIS: 1
TIMELINE_ANALYSIS: 1
DUMP_CLASS: 1
DUMP_QUALIFIER: 401
BUILD_VERSION_STRING: 17134.1.amd64fre.rs4_release.180410-1804
SYSTEM_MANUFACTURER: HUAWEI
SYSTEM_PRODUCT_NAME: KPL-W0X
SYSTEM_SKU: C233
SYSTEM_VERSION: M1B
BIOS_VENDOR: HUAWEI
BIOS_VERSION: 1.12
BIOS_DATE: 07/16/2018
BASEBOARD_MANUFACTURER: HUAWEI
BASEBOARD_PRODUCT: KPL-W0X
BASEBOARD_VERSION: M1B
DUMP_TYPE: 1
BUGCHECK_P1: 18
BUGCHECK_P2: 0
BUGCHECK_P3: ffff8000aa666180
BUGCHECK_P4: 2
BUGCHECK_STR: CLOCK_WATCHDOG_TIMEOUT_8_PROC
CPU_COUNT: 8
CPU_MHZ: 7cc
CPU_VENDOR: AuthenticAMD
CPU_FAMILY: 17
CPU_MODEL: 11
CPU_STEPPING: 0
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXPNP: 1 (!blackboxpnp)
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
PROCESS_NAME: svchost.exe
CURRENT_IRQL: d
ANALYSIS_SESSION_HOST: LAPTOP-HOS9SO75
ANALYSIS_SESSION_TIME: 10-04-2018 15:21:34.0416
ANALYSIS_VERSION: 10.0.17763.1 amd64fre
STACK_TEXT:
fffff802`3d880b78 fffff802`3b8162ae : 00000000`00000101 00000000`00000018 00000000`00000000 ffff8000`aa666180 : nt!KeBugCheckEx
fffff802`3d880b80 fffff802`3b6fa1bd : 00000000`00000000 fffff802`3a7bf180 00000000`00000246 00000000`0003d7be : nt!KeAccumulateTicks+0x1185de
fffff802`3d880be0 fffff802`3b6fb2a3 : fffff780`00000340 fffff802`3a7bf180 00000000`0003d7be 00000000`00000000 : nt!KiUpdateRunTime+0x5d
fffff802`3d880c30 fffff802`3bf6f883 : 000006d8`555b28b8 00000000`00000000 00000000`00000000 ffffeb83`4678d890 : nt!KeClockInterruptNotify+0x8f3
fffff802`3d880f40 fffff802`3b747d85 : fffff802`3bfd0cb0 00000000`00000000 00000000`00000000 00000000`00000000 : hal!HalpTimerClockInterrupt+0x63
fffff802`3d880f70 fffff802`3b7c5c3a : ffffeb83`4678d910 fffff802`3bfd0cb0 00000000`00000001 00000000`00000001 : nt!KiCallInterruptServiceRoutine+0xa5
fffff802`3d880fb0 fffff802`3b7c6127 : 00000000`594a9c4d fffff802`3bfd0cb0 00000000`00000000 00000000`00000000 : nt!KiInterruptSubDispatchNoLockNoEtw+0xea
ffffeb83`4678d890 fffff802`3b663236 : 00000000`00000000 ffffeb83`4678dbb0 00000000`00000000 00000000`00000000 : nt!KiInterruptDispatchNoLockNoEtw+0x37
ffffeb83`4678da20 fffff802`3b71df05 : 00000000`00000000 00000000`00000001 00000000`00015c52 00000000`00015c52 : nt!MiFlushTbList+0x346
ffffeb83`4678db70 fffff802`3b71d34d : fffff802`3b9e8960 ffffeb83`4678ddc0 fffffee0`8737dd88 0a000002`0f0df863 : nt!MiFlushTbAsNeeded+0x285
ffffeb83`4678dcc0 fffff802`3b71d8a0 : ffffeb83`4678df20 00000000`00000000 ffffd884`00001000 00000000`00001000 : nt!MiCommitPoolMemory+0x57d
ffffeb83`4678de00 fffff802`3b700854 : ffffeb83`4678df19 ffffc10e`6fbb1000 00000000`00000001 00000000`00e6fbb1 : nt!MmAllocatePoolMemory+0x80
ffffeb83`4678de60 fffff802`3b67fbf4 : fffff802`00000001 fffff80b`53336dc5 ffffc10e`00000000 00000000`00000000 : nt!MiAllocatePagedPoolPages+0x554
ffffeb83`4678df80 fffff802`3b905d37 : 00000000`00000000 00000000`58706e50 ffffd884`a3f50000 fffff802`58706e50 : nt!ExpAllocateBigPool+0x5a4
ffffeb83`4678e080 fffff802`3bb4c991 : 00000000`00000003 00000000`00000000 fffff802`58706e50 fffff802`3b90caf0 : nt!ExAllocatePoolWithTag+0x927
ffffeb83`4678e170 fffff80b`53302061 : ffffc10e`72fd8d80 00000000`00000001 ffffeb83`4678e658 fffff802`3bb6b979 : nt!PiDqSerializationAlloc+0x71
ffffeb83`4678e1a0 fffff80b`533024b6 : ffffc10e`72fd8d80 ffffeb83`4678e658 00000000`00000001 ffffc10e`703be6f0 : msrpc!Ndr64MesTypeEncode+0xb1
ffffeb83`4678e200 fffff802`3bb71793 : ffffc10e`73f85420 ffffd884`00000000 ffffc10e`73f85420 ffffeb83`4678e658 : msrpc!NdrMesTypeEncode3+0x196
ffffeb83`4678e5c0 fffff802`3bb74247 : ffffd884`aab5b690 ffffc10e`7063b230 00000000`00000000 ffffeb83`4678e6d8 : nt!PiDqQuerySerializeActionQueue+0x1a3
ffffeb83`4678e650 fffff802`3bb6f8fa : ffffd884`a0a00000 00000000`00000000 ffffd884`aab5b690 ffffc10e`6dd6c400 : nt!PiDqIrpQueryCreate+0x25b
ffffeb83`4678e790 fffff802`3bb6e816 : ffffd884`a1ee7af0 ffffd884`a0ad7e40 fffff802`3b90c9a0 ffffd884`af823160 : nt!PiDqDispatch+0x9a
ffffeb83`4678e7d0 fffff802`3b655ef9 : ffffd884`a1ee7af0 ffffd884`af823190 00000000`00000001 00000000`20206f49 : nt!PiDaDispatch+0x46
ffffeb83`4678e800 fffff802`3bb0119b : ffffd884`a1ee7af0 ffffeb83`4678eb80 00000000`00000001 00000000`00000000 : nt!IofCallDriver+0x59
ffffeb83`4678e840 fffff802`3bb0082f : ffffd884`00000000 ffffd884`af8231e0 00000000`00000000 ffffeb83`4678eb80 : nt!IopSynchronousServiceTail+0x1ab
ffffeb83`4678e8f0 fffff802`3bb00fd6 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x66f
ffffeb83`4678ea20 fffff802`3b7d4a43 : ffffc10e`6f8d2550 fffff802`3bb000dd 00000000`00000000 00000000`00000000 : nt!NtDeviceIoControlFile+0x56
ffffeb83`4678ea90 00007fff`decf9fd4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
000000ba`21bfe298 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007fff`decf9fd4
THREAD_SHA1_HASH_MOD_FUNC: f0c0ea8570d9cf21c293d3c611a631923756d246
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: b5b729fa6b03c806140ee6e0b5f4436f15a784a5
THREAD_SHA1_HASH_MOD: 9804f66d0efb06a1b44e7f4f22eaf4bb7449bcd8
SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
STACK_COMMAND: .thread ; .cxr ; kb
FAILURE_BUCKET_ID: CLOCK_WATCHDOG_TIMEOUT_8_PROC_ANALYSIS_INCONCLUSIVE!unknown_function
BUCKET_ID: CLOCK_WATCHDOG_TIMEOUT_8_PROC_ANALYSIS_INCONCLUSIVE!unknown_function
PRIMARY_PROBLEM_CLASS: CLOCK_WATCHDOG_TIMEOUT_8_PROC_ANALYSIS_INCONCLUSIVE!unknown_function
TARGET_TIME: 2018-10-04T06:58:32.000Z
OSBUILD: 17134
OSSERVICEPACK: 0
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 784
PRODUCT_TYPE: 1
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS Personal
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: 2018-09-15 10:18:09
BUILDDATESTAMP_STR: 180410-1804
BUILDLAB_STR: rs4_release
BUILDOSVER_STR: 10.0.17134.1.amd64fre.rs4_release.180410-1804
ANALYSIS_SESSION_ELAPSED_TIME: 1d55
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:clock_watchdog_timeout_8_proc_analysis_inconclusive!unknown_function
FAILURE_ID_HASH: {a475aa10-a8b4-488e-695e-4b6211d48f3d}
Followup: MachineOwner
---------