Hi,
Are you sure this is the correct log file?
I can see a resume at 12:00:25 on 2017-01-05
vmware tools waves hello at 12:00:30,
then a suspend at 12:00:50 and the log ends at 12:00:52
but no reboot of the guest OS..
So I think this log is the wrong one,
A resume, uninstall vmware tools and reboot of the guest OS within 27 seconds is very fast.. unless I'm missing something.
--
Wil
Jaime,
My best guess is that it was in the vmware.log file not in the vmware-0.log one, but I might be wrong.
Just attach all .log files from your vm next time, it is better to have too much info when troubleshooting as not enough.
Noting down the time when you boot the VM into the unbootable state might help too in tracking down where it happens in the logs.
--
Wil
Jaime,
and thank you for the write up on the time. That was really helpful!
There's not much details in the log about the crash, however when looking at it I see this:
2017-01-09T12:19:50.655+01:00| vcpu-3| I125: PCIBridge4: ISA/VGA decoding enabled (ctrl 0004)
2017-01-09T12:19:51.775+01:00| svga| I125: SVGA disabling SVGA
2017-01-09T12:19:51.853+01:00| svga| W115: WinBSOD: (28) 'Beginning dump of physical memory. '
and then more details about crash dump saving to disk.
What is interesting here is that the SVGA gets disabled before the BSOD hinting strongly that it is an issue with the display driver.
In your config it has this line:
svga.vramSize = "134217728"
and then a bit later in the normal boot with vmware tools I see this:
2017-01-09T10:11:05.390+01:00| vmx| I125: SVGA: Maximum display topology 4480x1920.
2017-01-09T10:11:05.390+01:00| vmx| I125: Ignoring svga.vramSize value in config file because svga.autoDetect is enabled.
2017-01-09T10:11:05.390+01:00| vmx| I125: Increasing vramSize to 8388608 (configured size 4194304 too small)
2017-01-09T10:11:05.390+01:00| vmx| I125: SVGA-GFB: Initial gfbSize=8388608
The interesting part about that is that you didn't set it to 4194304...
My guess here is that the vramSize as set there is too large or that the non vmware tools svga driver gets confused by dual screens, but that's only a guess.
I compared with a Windows 7 VM I have and there's no vramSize setting in there. But I also admit that I am just running one screen.
In your case I would shut down the VM, make a copy of the vmx and then remove the lines:
svga.numDisplays = "2"
svga.maxWidth = "5120"
svga.maxHeight = "3200"
svga.vramSize = "134217728"
Boot the VM, uninstall VMware Tools ... reboot (hopefully) and reinstall VMware Tools, then set the configuration again for the 2 displays using VMware workstation (not by editing the vmx manually)
--
Wil
Hi,
There's more roads that lead to Rome and I'm not often willing to give up. 
As we are in "remove non standard lines from the .vmx" mode already, how about removing these two lines:
acpi.smbiosVersion2.7 = "FALSE"
acpi.mouseVMW0003 = "FALSE"
Especially the first line I cannot find any info on what it does (well I can guess) and the only thing I see is crash related when searching for it.
The line with the mouse is probably fine.
Then you tried a vmware tools repair.. and it failed. But what did it fail on?
There's a log, vminstxxxx.log in the temp folder (see: Troubleshooting a failed VMware Tools installation in a Guest Operating System (1003908) | VMware KB )
Please attach.
Finally.. the copy&paste failing is usually to do with the vmtoolsd daemon not running (for whatever reason).
I do see that on one of my VMs every now and then and in that case instead of restarting the VM I first kill the vmtoolsd process that runs under my own user and then run a little batch file.
It has this contents:
"C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr
It gets stuck on running.. which is fine (you can kill the stuck dos screen ) there should again be a vmtoolsd process running under your user account.
In my case I always get copy&paste back after that workaround.
I'm not sure if it helps with unity.
--
Wil
Darius,
Thanks for the tips always nice to learn a bit more.
For Jaime it means not having to remove the lines and spent time on trying as they are expected.
Do you have additional tips for Jaime to try and/or troubleshoot?
--
Wil
Jaime,
Headstrong being an asset as a programmer depends. For customers I tend to drop that approach and search for an alternative solution when I can't find an answer within a preset time frame. Anyways..
vmtoolsd should have two processes running.
One as SYSTEM user and another one running under your user account.
Ah I see you got it working while I'm typing this up. Great to hear there's a solution.
Still no answer on why your VM would BSOD when you remove vmware tools, but sometimes you gotta count your blessings.
--
Wil
Nice to hear that you got things working. I've been catastrophically busy working a Support Request for the last few days, which is why I did the hit-and-run post of random education earlier and then promptly vanished again. 
Now I have a smidgen more time available.
Re. vmtoolsd: Usually there are two processes (as you've found), one for SYSTEM and one for the logged-in user. Interactions with the clipboard and with the user's desktop (drag and drop) go through the instance running as the user. Some other stuff (automatic guest display sizing? requests to restart/shutdown the guest OS? various other things?) have to be handled by the SYSTEM instance. I'm not terribly knowledgeable in the innards of Tools and copy/paste and drag/drop and Unity... I know there are lots of moving parts that all need to move in a coordinated fashion for those features to work, and I know that usually those moving parts should automatically be put into place by the Tools installer and shouldn't require messy tinkering or manual launches of Tools processes.
Re. the BSOD: No idea; There's not enough useful info on the BSOD screen, so I'd need to see a crash dump. Weird that you're not getting a dumpfile at all. (And double-weird that it correlates to uninstallation of VMware Tools.) Can you double-check the Windows Event Log (eventvwr.exe) in the "System" log to see if it reports an unusual location for the dump file or a problem writing the dump file out? I'm assuming you waited long enough for the dumpfile write to complete, and that you have enough free disk space on the VM's virtual C: drive. :smileygrin: Alternatively: If you can suspend or snapshot the VM while it's at the BSOD screen, we may be able to use the vmss2core tool included with Workstation and Fusion to convert the VM's suspended state (the .vmem and .vmss/.vmsn files which will appear in the VM's directory on the host) into a MEMORY.DMP suitable for analysis with WinDbg or your favorite BSOD analysis tool. (Neat, eh?)
Re. general config options: mem.hotadd should probably be removed from your VM's configuration. Windows 7 doesn't support memory hot add, and there are a few places behind-the-scenes where things might get unnecessarily complicated with hotadd support enabled. I doubt it is causing the BSOD or other problems though. And... it looks like you are doing some fun stuff with that VM, judging by its config and log... :smileymischief: But it all looks basically sane.
Re. systems imported from physical. "Brand-name" or integrated systems are the worst for rampant bundled drivers that can cause problems during P2V. The closer your host system is to a generic PC with a clean-installed retail OS, the better the likely outcome of a P2V. Remove every single unnecessary driver and software package... Each and every one could cause stability problems. Some of the uninstallers don't work so well either (cough... okay, don't look too closely at Workstation's uninstaller...) so problematic stuff might even remain after uninstalling everything. It'd definitely be "cleaner" to start off with a fresh installation directly into a VM, but on the flip-side... redoing ten years worth of accumulated software installation and customization is not an appealing prospect (and not always possible with lost installation media or software keys), which is why P2V remains a popular choice for some users. My gut feeling is that your trouble with Tools and possibly with the BSOD might very well be caused by one or more pieces of zombie software from your OS's time on a physical machine.
Cheers,
--
Darius