ralish's Posts

Hi all, The release of Windows 10 has introduced several new security features that are of particular interest to those of us who operate on secured networks. In particular, Device Guard and Credential Guard (Isolated User Mode). Together, these features provide what Microsoft refers to as Virtualisation Based Security. It's worth taking the time to read up on both of these features for the technical details, but at a high-level, they provide code integrity and credential theft protection respectively by virtualising the bulk of the OS with a small "secure kernel" and "secure user-mode" being responsible for enforcing the relevant security controls across the rest of the system. The idea is that compromise of the underlying OS, even up to and including kernel-mode privileges, shouldn't undermine the protections these features can provide short of a hypervisor exploit as the secure system runs at a higher privilege level than the rest of the operating system, including the NT kernel itself. The problem is that both of these features require Hyper-V to be enabled, as they're built on top of the virtualisation technology it provides. This is a problem for VMware Workstation as it refuses to run when Hyper-V is enabled. Does VMware have any plans to support coexistence with Hyper-V in certain contexts? Particularly wrt. support for systems where Device and/or Credential Guard are enabled? Are there any unofficial/unsupported workarounds for being able to use VMware Workstation without having to remove these features? Thanks in advance, -SDL

Hey all, Hoping I can reach someone from VMware to report an annoying regression in the VMware Tools shipped with VMware Workstation 11.1.2. The VMware Tools for Windows 2000 and later have been compiled with an application manifest that references multiple XML schemas within a single tag. This trips over a nasty Windows XP bug: KB921337: The computer may restart when you add a manifest that has the Windows Vista extension to an .exe file or to a .dll file in Windows XP Service Pack 2 (SP2) or in WEPOS The effect is that older Windows XP VMs will immediately crash on loading VMware Tools. The exact set of affected systems is: Any Windows XP system prior to SP2 Any Windows XP SP2 system without the KB921337 hotfix Windows XP SP3 is safe (includes KB921337) This bug was introduced in Workstation 11.1.2. Installing VMware Tools using the windows.iso from Workstation 11.1.1 will not trigger the bug. I recognise this is a bit of a niche case, but the VMware guest OS compatibility guide states Windows XP is supported at all patch levels, and many people installing a Windows XP VM using older installation media may install VMware Tools prior to patching the OS, and so will encounter this bug. The bug will effectively trigger a reboot loop. As a workaround, you can start in Safe Mode and stop the vmtoolsd.exe process from automatically starting. Thanks, -SDL

On a fresh installation of Microsoft Windows Server 2008 Core x64 SP2 on VMware Workstation 9.0.1 I am reliably seeing a crash in the VMware Tools Core Service (vmtoolsd.exe) nearly everytime immediately on logon. The installation is completely fresh with VMware Tools installed immediately after the initial operating system configuration completed. The exact error I'm receiving is as follows: VMware Tools unrecoverable error: (vthread-3) Exception 0xc0000005 (access violation) has occurred. I took a look at the VMware KB but nothing really seemed to match what I'm seeing: VMware Tools on a Windows virtual machine fails with the error: Exception 0xc0000005 (access violation) Error is identical but only seems to apply to a Tools upgrade scenario and this is a fresh install. I checked for duplicates anyway but found none. Upgrading VMware Tools to Fusion 4 or Workstation 8 fails with error: VMware Tools unrecoverable error Error is identical but this issue was fixed back in Workstation 8.0.1 so shouldn't apply. Upgrading to VMware Tools 5.1 causes log spew in the Windows Event Log: Error in the RPC receive loop This error is the closest and on adding in the tools.conf configuration the subsequent reboot didn't crash so I initially thought it was fixed. However, the subsequent reboot had the same problem again; I verified the tools.conf was still in place to be sure (which it was). Interestingly, at the time of this issue I was also setting up several other VMs listed below. Only the Server 2008 Core VM sees this issue making me think it's something specific to this particular OS. Perhaps a missing DLL VMware expects to exist given this is a Core type install? Other VMs installed fine: Microsoft Windows Server 2008 x64 SP2 Microsoft Windows Server 2008 R2 x64 SP1 Microsoft Windows Server 2008 R2 Core x64 SP1 Microsoft Windows Server 2012 x64 Microsoft Windows Server 2012 Core x64 I've attached a couple of crash dumps if anyone from VMware wishes to investigate futher. If anyone else has advice it'd be greatly appreciated!