dimet's Posts

This issue has been investigated by Microsoft support and was determined to be the issue with VMware Workstation "vm3dum64.dll". The problem: Visual Studio 2022 (VS2022) on guest OS has a substantial scrolling lag on any file with 100+ lines. It is visible while dragging the scroll bar thumb with a mouse and observing that the thumb is substantially behind the mouse pointer even during slow mouse moves. This was benchmarked against Visual Studio 2019 (VS2019). On VS2019, this issue does not show up. The explanation from MSFT is that VS2022 uses 3D acceleration while VS2019 was not. Further investigation by MSFT revealed that "vm3dum64.dll is maxing out one core and consumes 50% of the CPU. That is a module from VMware. On the render thread, that is taking place.". The issue was reproduced on multiple different VMware VMs. The above happens only when "Accelerate 3D Graphics" is enabled for the VM. When it is disabled, the issue goes away. Environment: VMware Workstation 16.2.5 Pro. Hardware: high-end laptop Lenovo P16, CPU I9-12900HX 5GHz, 64GB RAM. Host OS: Windows 10 Pro build 19045. Guest OS: Windows 10 Pro build 19045.   The above is for VMware support investigation.    

I've just installed VMware workstation 16.0.0. That was an upgrade from VMware Workstation 12.5. Host OS: Windows 10 1809. I tried to perform digital signing using SDK's signtool.exe from within the VM with guest OS (Win7 Pro). VM is connected via NAT. I've noticed that it takes much longer to connect to the timestamp server. The investigation showed that during TCP connectivity the number of packets simply lost/discarded (including those with RST flag) on the guest OS. Please see the attached screenshots comparing the traffic within the guest and on the host. Several packets even above the packet with RST are being lost. Because of this behavior, Network Address Translation is not usable in this Workstation release.        

Hello, I've been observing this behavior for a while. When TCP client (web browser) within the guest OS connecting to an outside server (web server) and the firewall within guest OS starts blocking packets after the TCP connection is established, after some time the VMware Workstation starts issuing TCP packets with ACK+PSH+FIN on behalf of the outside server. The packets are issued every 100 milliseconds and it never stops (for at least several days). In VMware Workstation 9 and earlier it was going on for about 30 sec then stopped. In Workstation 11 it just keeps going. The Suspend-Resume or Reboot of the guest OS has no effect. The disconnect-reconnect to guest OS of the network has no effect. Only reboot of the host OS helps. It was observed for Win 7 x64 as a host OS and both Win XP x86 and Win7 x86 as a guest OS. I would guess that when a TCP client process is forcefully terminated, it may also cause the TCP connection not being closed by the client gracefully and result in the same behavior from VMware Workstation. My guess is that it may be related to statefull TCP processing by Workstation. So when TCP state machine times out, it tries to gracefully terminate the connection it thinks still exists. Is there Workstation setting that can limit the number of attempts for such graceful TCP termination or a time limit on it?

Reporting BSOD upon startup of Windows 7 x64 host, sometimes even before the first login. It happens quite often when USB Corsair Flash Voyager mini is plugged into the Gearhead usb hub (UH7200BLK) which in turn is connected to the laptop. VMWare Workstation 9.0.1 build 894247 OS: Windows x64 Hardware: Dell Latitude E6520 with 8GB RAM. Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Built by: 7601.18247.amd64fre.win7sp1_gdr.130828-1532 Machine Name: Kernel base = 0xfffff800`04057000 PsLoadedModuleList = 0xfffff800`0429a6d0 Debug session time: Mon Jan 20 11:42:42.971 2014 (UTC - 8:00) System Uptime: 0 days 0:00:38.188 Loading Kernel Symbols ............................................................... ................................................................ ................................................................ ....... Loading User Symbols PEB is paged out (Peb.Ldr = 000007ff`fffdf018).  Type ".hh dbgerr001" for details Loading unloaded module list .. ******************************************************************************* *                                                                             * *                        Bugcheck Analysis                                    * *                                                                             * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck A, {fffff8a00420e550, 2, 1, fffff80004197588} *** ERROR: Module load completed but symbols could not be loaded for hcmon.sys Probably caused by : hcmon.sys ( hcmon+6289 ) Followup: MachineOwner --------- 3: kd> !analyze -v ******************************************************************************* *                                                                             * *                        Bugcheck Analysis                                    * *                                                                             * ******************************************************************************* IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high.  This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: fffff8a00420e550, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000001, bitfield : bit 0 : value 0 = read operation, 1 = write operation bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status) Arg4: fffff80004197588, address which referenced memory Debugging Details: ------------------ OVERLAPPED_MODULE: Address regions for 'vstor2_mntapi10_shared' and 'rimmpx64.sys' overlap WRITE_ADDRESS:  fffff8a00420e550 Paged pool CURRENT_IRQL:  2 FAULTING_IP: nt!IoEnumerateDeviceObjectList+68 fffff800`04197588 48895d00        mov     qword ptr [rbp],rbx DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT BUGCHECK_STR:  0xA PROCESS_NAME:  vmware-usbarbi TRAP_FRAME:  fffff88008136550 -- (.trap 0xfffff88008136550) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=0000000000000008 rbx=0000000000000000 rcx=fffffa8009304440 rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000 rip=fffff80004197588 rsp=fffff880081366e0 rbp=fffff8a00420e550 r8=0000000000000000  r9=0000000000000000 r10=fffffa800694e148 r11=0000000000000001 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0         nv up ei ng nz na pe nc nt!IoEnumerateDeviceObjectList+0x68: fffff800`04197588 48895d00        mov     qword ptr [rbp],rbx ss:0018:fffff8a0`0420e550=0000000000000000 Resetting default scope LAST_CONTROL_TRANSFER:  from fffff800040cc169 to fffff800040ccbc0 STACK_TEXT:  fffff880`08136408 fffff800`040cc169 : 00000000`0000000a fffff8a0`0420e550 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx fffff880`08136410 fffff800`040cade0 : 00000000`00000006 fffffa80`09304440 00000000`00000000 fffffa80`09304440 : nt!KiBugCheckDispatch+0x69 fffff880`08136550 fffff800`04197588 : fffffa80`09304440 00000000`00000000 fffff8a0`0420e530 fffff880`08136780 : nt!KiPageFault+0x260 fffff880`081366e0 fffff880`058c0289 : 00000000`00000000 fffff980`10680fd0 fffff8a0`0420e530 00000000`000007ff : nt!IoEnumerateDeviceObjectList+0x68 fffff880`08136720 fffff880`058bda9c : 00000000`00000015 fffff980`10680fd0 fffff980`10680fd0 00000000`00000250 : hcmon+0x6289 fffff880`08136780 fffff880`058be136 : 00000000`00000000 00000000`81012368 fffffa80`09986a40 fffffa80`09e70240 : hcmon+0x3a9c fffff880`081367f0 fffff800`04575d26 : fffffa80`09e70240 00000000`00000009 fffffa80`09c29f20 fffffa80`09e70240 : hcmon+0x4136 fffff880`08136870 fffff800`043e93a7 : fffffa80`09c29f20 fffff880`08136b60 fffffa80`09c29f20 fffffa80`09e4c580 : nt!IovCallDriver+0x566 fffff880`081368d0 fffff800`043e9c06 : 00000000`00000001 00000000`0000014c 00000000`00000000 00000001`3f88ac40 : nt!IopXxxControlFile+0x607 fffff880`08136a00 fffff800`040cbe53 : fffffa80`0a1fb3e0 fffff880`08136b60 fffff880`746c6644 fffff880`08136af8 : nt!NtDeviceIoControlFile+0x56 fffff880`08136a70 00000000`76d9132a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 00000000`0197f928 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76d9132a STACK_COMMAND:  kb FOLLOWUP_IP: hcmon+6289 fffff880`058c0289 3bc3            cmp     eax,ebx SYMBOL_STACK_INDEX:  4 SYMBOL_NAME:  hcmon+6289 FOLLOWUP_NAME:  MachineOwner MODULE_NAME: hcmon IMAGE_NAME:  hcmon.sys DEBUG_FLR_IMAGE_TIMESTAMP:  5077611f FAILURE_BUCKET_ID:  X64_0xA_VRF_hcmon+6289 BUCKET_ID:  X64_0xA_VRF_hcmon+6289 Followup: MachineOwner ---------