btmp's Posts

btmp · ‎03-15-2022

I've moved on and am now using Hyper-V but I used Workstation for many years previously and somehow 'expected' that once I moved on they would suddenly fix everything! (That's how my luck tends to go...

I've moved on and am now using Hyper-V but I used Workstation for many years previously and somehow 'expected' that once I moved on they would suddenly fix everything! (That's how my luck tends to go...) Thanks for the update on the more recent revision, it saves me the effort of re-testing that much myself! I'm obviously still rooting for VMWare to correct Workstation in this (and other aspects) but it's been well over a year since 15.5.x was a near perfect version (while IMO 16.x versions no longer 'just work') and they are no longer producing any 15.x [security update] versions so IMO we are currently stuck between 'acceptable security' or 'annoying usability' or 'unacceptable instability'..Sorry none of those choices worked for us in the long term!

btmp · ‎02-18-2022

Thanks for the link, I hadn't come across that before. Sadly after reading over it and looking into other VMware Workstation drivers installed by default it appears most of them have the same securi...

Thanks for the link, I hadn't come across that before. Sadly after reading over it and looking into other VMware Workstation drivers installed by default it appears most of them have the same security permissions set to allow "Everyone" read and write meaning that if the vstor driver is toxic so are the others. Looking more and more like I'm switching over to Hyper-V =(

btmp · ‎01-19-2022

On more recent versions of VMware Workstation I've found that I cannot mount NTFS formatted drives as writable. Mounting the same drives as READ ONLY works fine. This includes VMware-workstation-ful...

On more recent versions of VMware Workstation I've found that I cannot mount NTFS formatted drives as writable. Mounting the same drives as READ ONLY works fine. This includes VMware-workstation-full-16.2.2-19200509 btw VMware-workstation-full-16.1.2-17966106 was the last version to properly mount NTFS formatted drives as writable. Mounting them as read-only still works but that's not at all helpful when trying to ADD files to the disk or EDIT existing files (eg the registry of windows while troubleshooting found in "C:\Windows\System32\Config" etc) The Drives show up as ? in explorer and the only related Windows Event Logs I've come across are entries like these each time I attempt to mount it with a timestamp that 'almost' matches the mount attempt The system failed to flush data to the transaction log. Corruption may occur in VolumeId: ??, DeviceName: \Device\vstor2-mntapi20-shared-99A22C8D000010000000000001000000. Failure status: The I/O request was canceled. Device GUID: {00000000-0000-0000-0000-000000000000} Device manufacturer: Device model: Device revision: Device serial number: Bus type: <unknown> Adapter serial number: - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> - <System> <Provider Name="Microsoft-Windows-Ntfs" Guid="{3ff37a1c-a68d-4d6e-8c9b-f79e8b16c482}" /> <EventID>140</EventID> <Version>1</Version> <Level>3</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x8000000000000008</Keywords> <TimeCreated SystemTime="2022-01-19T20:28:58.7013511Z" /> <EventRecordID>81</EventRecordID> <Correlation /> <Execution ProcessID="4" ThreadID="5792" /> <Channel>System</Channel> <Computer>NT</Computer> <Security UserID="S-1-5-18" /> </System> - <EventData> <Data Name="VolumeIdLength">2</Data> <Data Name="VolumeId">??</Data> <Data Name="DeviceNameLength">63</Data> <Data Name="DeviceName">\Device\vstor2-mntapi20-shared-99A22C8D000010000000000001000000</Data> <Data Name="Error">0xc0000120</Data> <Data Name="DeviceGuid">{00000000-0000-0000-0000-000000000000}</Data> <Data Name="VendorIdLength">0</Data> <Data Name="VendorId" /> <Data Name="ProductIdLength">0</Data> <Data Name="ProductId" /> <Data Name="ProductRevisionLength">0</Data> <Data Name="ProductRevision" /> <Data Name="DeviceSerialNumberLength">0</Data> <Data Name="DeviceSerialNumber" /> <Data Name="BusType">0</Data> <Data Name="AdapterSerialNumberLength">0</Data> <Data Name="AdapterSerialNumber" /> </EventData> </Event> I've also tried different variations such as creating a brand new NVMe disk (instead of SCSI) and starting the VM in order to format it as NTFS with a Windows 10 ISO, powering it off and then attempting to mount that. So it's not just pre-existing disks, it's also brand new ones that have just been created and formatted with 16.2.2 ~ However if I then format the same disk as FAT32 it mounts, even as writable, just fine using recent versions. I originally noticed this while using Windows 10 1809 but have since switched to 21H2 for both my host and test machines and the issue remains even after trying a virgin install of Windows in a VM and installing the latest VMware Workstation build there so either this will be really easy to reproduce or may be related to something else I haven't thought of yet. I have isolated the driver:"vstor2-mntapi20-shared" as the culprit even though it is (amusingly due to its name) located at "C:\Windows\SysWOW64\drivers\vstor2-x64.sys" By manually stopping it and then reverting to the version shipped in 16.1.2, I can once again mount an old, or even a newly formatted, NTFS drive as writable. So I have my workaround for now but a proper fix would be ideal moving forward!

btmp · ‎01-19-2022

Check the focus image I had attached in my earlier post on this thread and you can see the difference Note you won't be able to reproduce this issue unless you already have Settings > Personalizatio...

Check the focus image I had attached in my earlier post on this thread and you can see the difference Note you won't be able to reproduce this issue unless you already have Settings > Personalization > Colors > Show accent color on the following surfaces > 'Title bars and window borders' enabled and likely wouldn't notice if are not already 'used' to having it enabled. AKA [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM] "ColorPrevalence"=dword:00000001 The version of 16 that 'broke dark mode' without the pref ini entry getting manually added 'fixed' it for me but now it's back to overwriting it with the custom themes in more recent versions again. I got tired of waiting for them so I searched for a fix that can be manually applied if you are familiar with a hex editor. I've done a little testing with it (a few hours so far) and it's working great on my system! This is ONLY for build 16.1.2.8432 aka 16.1.2 build 17966106 of "C:\Program Files (x86)\VMware\VMware Workstation\vmware.exe" with SHA1 08ef59db2175e984e38c04087ce9de1986c4c383 File Name: vmware.exe File Offset: c1389 Original: 8A 00 84 C0 0F 84 Overwritten: C6 00 00 90 90 E9 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This is ONLY for build 16.2.2.20227 aka 16.2.2 build 19200509 of "C:\Program Files (x86)\VMware\VMware Workstation\vmware.exe" with SHA1 62c10ffd00c6bc7da2633add043fd7884f0c34d File Name: vmware.exe File Offset: be8dc Original: 8A 00 84 C0 0F 84 Overwritten: C6 00 00 90 90 E9 This stops vmware.exe from 'overwriting' the title bar with its custom theme stuff and allows the default windows title bar size, buttons, colors and active status to remain and continue to function as "expected" Now we just need an option to 'exclude the title bar' from theme changes to get added and everyone can be happy again!

btmp · ‎09-10-2021

As you mention saving files to your hosts C:\ or D:\ drive is it safe to assume you are doing this via 'Shared Folders' within the VM? If that's accurate is the NAS U:\ also a Shared Folder? I also a...

As you mention saving files to your hosts C:\ or D:\ drive is it safe to assume you are doing this via 'Shared Folders' within the VM? If that's accurate is the NAS U:\ also a Shared Folder? I also assume you're logged in as an Administrator for the file saves via Explorer to the Shared Folders? Update: Moved likely incorrect thoughts to spoiler tags (why is there no delete button for my post!?) /cry Assuming I have even that much right (and I admit I don't have actual experience with this and it may be better if you wait to hear from somebody who does) my first thought would be that it's because most browsers these days run (at least parts) in a reduced integrity mode as part of sandboxes [as they are highly targeted for exploits]. If I'm not already off base this would amount to Explorer running as High Integrity but the Browser (or parts at least) running as Medium to Low or an AppContainer in-between in which case I'm already suprised it works for the C or D saves...but could still be relavent if the NAS drive doesn't allow non admins to write to it? Maybe? Just guessing here... Offhand, maybe it's related to SMB or some such which I cannot help with at all. Sorry if I wasted your time, just typing what came to my mind...Good Luck!

btmp · ‎09-10-2021

The post @wila pointed to does indeed have steps that might resolve the VM failing to start once and for all. I was trying to avoid suggesting anything that would cause anyone to disable the extra s...

The post @wila pointed to does indeed have steps that might resolve the VM failing to start once and for all. I was trying to avoid suggesting anything that would cause anyone to disable the extra security of VBS. I'm not all that keen on disabling "anything" security related just to make "something else work as desired". So long as the user is OK with losing the extra security and understands that following such steps will do so and they just 'want the VM(s) to work' [with the extra CPU virtualization options in this case] then by all means, that's their right and the steps in that post should help get you there!

btmp · ‎09-10-2021

The SYSTEM_SERVICE_EXCEPTION BSOD is a vague error that seems to be popping up here quite a bit recently...starting to think I should create a block of text to copy and paste for it Generally the...

The SYSTEM_SERVICE_EXCEPTION BSOD is a vague error that seems to be popping up here quite a bit recently...starting to think I should create a block of text to copy and paste for it Generally these can be solved by updating everything. According to the pictures your Windows 10 is fairly up to date so all you really need to worry about there is ensuring your other drivers, things like the GPU and Sound Card or Network Drivers are also up to date. Most of all though you're not using the latest version of Workstation 16. If I were you I'd start with downloading 16.1.2-17966106 and update that first. It may do the trick all by itself. Likely not related but the photos also show the install date for the OS as tomorrow (Maybe you're just in a different time zone?) and that the system only has 4GB to start with. I'd double check your VM Settings to ensure they aren't set for something higher than your system can handle. Depending on what you have installed or running on the host it's likely that at least 1-2 GB of that is already in use so unless you want to use a decent size pagefile and deal with a slow VM as things are written to disk constantly you may have to reduce the amount of RAM allowed for your VM (Depending on what its set at)

btmp · ‎09-09-2021

If it fails that quickly I'd expect it to be partition or maybe MFT related but you said you already checked the disk so I'm at a loss. Thanks for the update but sadly I'm out of ideas atm. Please do...

If it fails that quickly I'd expect it to be partition or maybe MFT related but you said you already checked the disk so I'm at a loss. Thanks for the update but sadly I'm out of ideas atm. Please do update us further if you make any progress!

btmp · ‎09-09-2021

I doubt it. That thread is about the Meltdown and Spectre mitigations. bluefirestorm seems to have already given the best solution for that particular issue. The way he phrases it The warning come...

I doubt it. That thread is about the Meltdown and Spectre mitigations. bluefirestorm seems to have already given the best solution for that particular issue. The way he phrases it The warning comes when the Windows host has HyperV enabled or WSL enabled as VMware Player/Workstation will use User Level Monitor (ULM) might make it seem like a similar issue offhand because it occurs while 'HyperV related things are enabled' but instead seems more related to the way VMWare Workstation handles applying those mitigations to the VMs (instead of HyperV 'getting in the way' of the VM starting as it seems to be doing on this thread) while Hyper-V is active. Admittedly it might still be possible to get better performance by removing the HyperV related stuff so that the Virtual Machine Monitor can handle those in the kernel instead. I may even be wrong about parts of things considered on both threads -I'm only going off what little I understand and what I've experienced in the past...but at the same time there should be no harm in testing it so long as the person making use of it understands what they're doing beforehand.

btmp · ‎09-09-2021

Sorry to hear there wasn't any helpful info in the windows install logs =( As you have another copy perhaps you could try deleting the hidden recovery partion entirely? I kind of doubt it will do th...

Sorry to hear there wasn't any helpful info in the windows install logs =( As you have another copy perhaps you could try deleting the hidden recovery partion entirely? I kind of doubt it will do the trick unless there is something rather unique about it but might as well remove whatever possibilities we can, right? If not that, at least, disable the active parition flag on the hidden one now that you have it set on the OS partition...less chances of confusing something that way Short of that I think re-creating a new disk (ideally with the same hardware in case any activations use that) would be the next best step. Then you could transfer 'only' the OS partition files over to the new one...I'd use DISM to capture and apply it myself but most 3rd party backup and restore softwares might do the trick except that we want to 'forget' or leave behind the original disks partition setup to ensure thats not involved somehow. Sounds similar to your 'data copy' attempt but I think it may run into some issues if you're only using Windows Explorer to Copy and Paste it over. Still, Good Luck!

btmp · ‎09-09-2021

It is standard, yes. If you want to remove this behavior you can edit\add a line in your .vmx file but then you won't be able to eject or swap components as easily and will need to shut down the VM ...

It is standard, yes. If you want to remove this behavior you can edit\add a line in your .vmx file but then you won't be able to eject or swap components as easily and will need to shut down the VM to change devices closer to how you might on an actual system. devices.hotplug = "FALSE"

btmp · ‎09-08-2021

Your crash.txt file shows SYSTEM_SERVICE_EXCEPTION which is one of the more vague errors. Generally the best way to solve these is to ensure everything is up to date on your host. In your case this ...

Your crash.txt file shows SYSTEM_SERVICE_EXCEPTION which is one of the more vague errors. Generally the best way to solve these is to ensure everything is up to date on your host. In your case this would mean updating Windows 10 (I do not mean feature updates) up to the LatestCumulativeUpdate and ensuring your current version of Workstation is also on the latest (eg 15.5.7-17171714 if sticking with 15 but even better would be 16.1.2-17966106) along with any device drivers (ex GPU, Network or even a Sound Card) Aside from ensuring everything is up to date on the host you can also check the integrity of your Windows 10 installation. DISM /Online /Cleanup-Image /ScanHealth

btmp · ‎09-08-2021

Normally I'd default to snapshots being a potential issue as you can't usually reclaim much space with even one....your situation seems to involve an actual shortage of HDD space on the host though s...

Normally I'd default to snapshots being a potential issue as you can't usually reclaim much space with even one....your situation seems to involve an actual shortage of HDD space on the host though so my first suggestion would instead be to COPY or Fully Clone the entire VM to a larger drive and open that copy in Workstation and do some cleanup INSIDE the VM. After freeing up space inside (Which you seem to think it already has quite a bit of so maybe you can skip that part of the cleanup phase) you can then try compacting and adjusting it from there via Workstation as I suspect this is just a situation where there actually isn't enough room left on that first HDD (where it's currently stored) for Workstation to do the requested work. Once it's sufficiently trimmed (and tested) you could then move the copy back to the initial location? As for limiting an existing VMs size, I can't say I know of a way to lower its limits springs to mind, only expanding it...sorry!

btmp · ‎09-08-2021

'Access Control' Encryption via Workstation is an outer layer of encryption. Removing that layer, in itself, won't alter the contents (aside from the actual decryption of existing data back to a stan...

'Access Control' Encryption via Workstation is an outer layer of encryption. Removing that layer, in itself, won't alter the contents (aside from the actual decryption of existing data back to a standard 'unencrypted' format) of the VM. As for removing 'this' disk or 'that' disk or editing this preference etc..I cannot say as I do not know your VMs layout or setup internally. I suppose if you are worried about it or do run into issues you could start by disabling SecureBoot inside the VM before doing the rest. Good Luck!

btmp · ‎09-08-2021

As upgrading the existing Win7 to 10 is your primary goal and only starting the upgrade from inside Windows 7 works at this point, perhaps you should start that route again and take a look at the res...

As upgrading the existing Win7 to 10 is your primary goal and only starting the upgrade from inside Windows 7 works at this point, perhaps you should start that route again and take a look at the resulting log files related to the failure that MS saves? It might give you (us) a better idea of WHERE Windblows is choking and a better place to start for trying to fix that route?

btmp · ‎09-08-2021

As it's called 'Access Control' Encryption my first guess would be that you need to decrypt it. That way it becomes a regular VM again which will allow you to edit or reconfigure it normally.

btmp · ‎09-08-2021

Ooh, if it's that critical please be sure to have a backup of the VM or only mess with a full 'clone'!

btmp · ‎09-08-2021

I've never encountered such an issue after a host driver update but if I did my first attempt to resolve it would probably be to boot the VMs into Windows 'Safe Mode' then uninstall the existing VMWa...

I've never encountered such an issue after a host driver update but if I did my first attempt to resolve it would probably be to boot the VMs into Windows 'Safe Mode' then uninstall the existing VMWareTools. Unfortunately the Windows Installer Service that handles MSI packages like the VMTools isn't normally set to be run during safe mode so you'd have to enable that before you can uninstall it in safe mode. Once in Safe mode you could run these via cmd to enable Windows Installer Service there REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\MSIServer" /D "Service" NET START MSIServer ------------------------------------ Then do the uninstall of the VMWare Tools followed by the prompted reboot. After you're back into normal mode (assuming it does the trick) you can clean up the added registry key and value with this cmd REG DELETE "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\MSIServer" /F

btmp · ‎09-08-2021

Can't recall coming across any tool that checks such things in my time with Workstation. You could mount the existing disk on your host and use DISM to capture it to a wim and once you have the wim ...

Can't recall coming across any tool that checks such things in my time with Workstation. You could mount the existing disk on your host and use DISM to capture it to a wim and once you have the wim of the current state you could apply it to the new vmdk (after it has been partitioned and formatted then mounted) That wouldn't carry over the bootloader and such but you should be able to use the Windows ISO to handle that part via the cmd line if need be

btmp · ‎09-08-2021

If you have VMTools installed on the Guest perhaps try uninstalling those, then do the upgrade then re-install the tools? That might only help for the 'in Windows' setup attempts. I've never seen an...

If you have VMTools installed on the Guest perhaps try uninstalling those, then do the upgrade then re-install the tools? That might only help for the 'in Windows' setup attempts. I've never seen an official ISO fail to load due to what any HDD attached held.....is this a custom ISO by chance or a virgin one made by MS?

All

btmp's Posts

Re: Recent 16.x versions can't mount a writeable NTFS Disk

Re: Recent 16.x versions can't mount a writeable NTFS Disk

Recent 16.x versions can't mount a writeable NTFS Disk

Re: Workstation 16 window icons

Re: VMware Workstation Professional 16 Browser inside Guest Operating System Error.

Re: VMWare Workstation Boot Manager - help please!!!

Re: VM Ware Causing My PC Windows to Crash

Re: Workstation Pro 16: Unable to Boot W10 ISO to Upgrade W7 VM

Re: VMWare Workstation Boot Manager - help please!!!

Re: Workstation Pro 16: Unable to Boot W10 ISO to Upgrade W7 VM

Re: Many system devices removable in VM?

Re: VMware Workstation Pro Causing BSOD on host PC

Re: Linux guest - can't shrink virtual disk

Re: VMWare Workstation 16 - how remove one of several encrypted disks

Re: Workstation Pro 16: Unable to Boot W10 ISO to Upgrade W7 VM

Re: VMWare Workstation 16 - how remove one of several encrypted disks

Re: Workstation Pro 16: Unable to Boot W10 ISO to Upgrade W7 VM

Re: VMware Workstation 16 Pro Cannot run Windows Virtual systems after NVIDIA Driver Update

Re: Workstation Pro 16: Unable to Boot W10 ISO to Upgrade W7 VM

Re: Workstation Pro 16: Unable to Boot W10 ISO to Upgrade W7 VM