Snowizard
Contributor
Contributor

After Win10 Creators update, VMs do not start in Workstation or Player.

Jump to solution

After the Creators Update, I cannot run the suspended player sessions.

Attempting to open a VM eventually generates this error:

Could not get snapshot information: Insufficient permission to access the file.

Module 'Snapshot' power on failed.

Failed to start the virtual machine.

The problem appears to be the vmx.lck and vmsd.lck folders, which I cannot access or delete, even running "as administrator"

edit: the problem is not the .lck folders, they are simply left over with some content open after the error above.

Any help diagnosing this issue would be much appreciated.

1 Solution

Accepted Solutions
mushijima
Contributor
Contributor

Ok, I have confirmed someone else post that it appears to be an "undocumented feature" interaction between VMware workstation 12.5.x, Webroot and Windows 10 build 1709, I haven't traced the cause yet.  But I can tell you this. 

Windows 10 build 1709

VM Workstation 12.5.x  and Workstation 14 (according to other similar threads)

Webroot 9.0.18.34

Tested on Surface Pro 4 and Thinkpad T440p

Hypothesis of Problem: Following upgrade to Windows build 1709, webroot forces VMWare workstation to create temporary locks on files on a "C:\" drive directory, preventing VM to load.

Reported Error is

Could not get snapshot information: Insufficient permission to access the file.

Module 'Snapshot' power on failed.

Failed to start the virtual machine.

Attempted Work arounds:

1. Move VMs to other media - I've used two different external media - USB based drive and SD-Card, both enabled VMs to start up while Webroot was active - Not ideal

2. Turn off Webroot, as soon, as I've done this the lock file condition goes away and VMs startup normally, no reboot required.  But this does disable webroot - Not ideal

3. Attempted to create and exception in webroot for VM directory - did not work

4. Thought this might be some weird interaction with Window's new protected folder system in build 1709, disabled that, added VM applications to it - No effect

My company's IT organization has opened a case with Webroot, I'll advise if I find anything.  Please reply if anyone else learns anything!

View solution in original post

24 Replies
daphnissov
Immortal
Immortal

What version of workstation do you have?

0 Kudos
Snowizard
Contributor
Contributor

Workstation 14 Pro

0 Kudos
Snowizard
Contributor
Contributor

I can still run or create VMs on my 😧 drive, but the ones I used most on my C: drive, or any new VM on the C: drive all get a permission error.

It seems the Windows update either changed some permissions, or something related.  I have tried updating ownership and permissions to the VMWare folder(s) on C: to match 😧 to no avail.

0 Kudos
silverlox
Contributor
Contributor

Hi

I have reverted back to the previous version of Windows 10,1703 as I could not run any VM's in the Fall creators version 1709 after the update.

Unfortunately I needed to run a VM with no delay so was unable to try any changes etc.

Luckily I had used Acronis True Image to make a backup so the restoration was flawless.

Workstation is installed on C, my VM's are on D,E & F.

None would work, Windows said VMware had a problem and must close.

So I'm waiting for a week or so and will try again but first making a copy of the 1703 OS on a separate drive and booting from that one for the Fall Creators update.

Be interested to see if anyone else has this problem

Workstation Pro V14

Windows Fall Creators update 1709

HP Z820, dual Xeon, 64GB ram, running on SSD's mostly

0 Kudos
Snowizard
Contributor
Contributor

Thanks for weighing in, silverlox.

Perhaps the problem is related to SSD usage.  My C: (VMs don't work here) is a 1GB SSD, while my 😧 (VMs do work here) is a fairly slow HD.  I am currently moving my VMs to 😧 so I can work more normally; 2 of 6 have moved and started working.  I have an Acronis image from last weekend, but if this works, I think I will be ok for now.  Hopefully VMWare and MS figure things out soon.

Holding my breath...

Would love to hear from others with the same issue.  Or a fix Smiley Wink

0 Kudos
mushijima
Contributor
Contributor

I am having the exact same issue with my Workstation 12.5.x installation on Windows 10 after creators update.  The best I can tell, is that the creator's update changed C: drive permission handling.  If anybody figures this would be greatly appreciated. 

0 Kudos
epmdev
Enthusiast
Enthusiast

Agreed. Same issue for me after Windows 10 Fall Creators  update.

0 Kudos
epmdev
Enthusiast
Enthusiast

I temporarily moved my VMware image to an external drive and it works. 

Yeah, think you're right.  Microsoft must have done something with permissions on C Drive.  While not necessarily VMware's fault, the Windows 10 Fall Creators Update build has been available in beta for sometime.  Surprised the VMware team didn't run into this issue and come up with an update with a fix.  Disappointing.

If anyone comes up with a work around, please post.  Thanks.

0 Kudos
DCSpooner
Enthusiast
Enthusiast

so far coping to an USB drive is the only workaround. i have open a support case with VMware to see if they can fix this issue fast.

0 Kudos
DCSpooner
Enthusiast
Enthusiast

have you tried to disable your Antivirus products,

i am running webroot and once i disabled it, at the request of VM support and i was able to run my VMs again

they also suggested to create an exclusion to the .\Documents\Virtual Machine\ folder with in my Antivirus software.

I am trying that now to see how that works

0 Kudos
mushijima
Contributor
Contributor

Ok, I have confirmed someone else post that it appears to be an "undocumented feature" interaction between VMware workstation 12.5.x, Webroot and Windows 10 build 1709, I haven't traced the cause yet.  But I can tell you this. 

Windows 10 build 1709

VM Workstation 12.5.x  and Workstation 14 (according to other similar threads)

Webroot 9.0.18.34

Tested on Surface Pro 4 and Thinkpad T440p

Hypothesis of Problem: Following upgrade to Windows build 1709, webroot forces VMWare workstation to create temporary locks on files on a "C:\" drive directory, preventing VM to load.

Reported Error is

Could not get snapshot information: Insufficient permission to access the file.

Module 'Snapshot' power on failed.

Failed to start the virtual machine.

Attempted Work arounds:

1. Move VMs to other media - I've used two different external media - USB based drive and SD-Card, both enabled VMs to start up while Webroot was active - Not ideal

2. Turn off Webroot, as soon, as I've done this the lock file condition goes away and VMs startup normally, no reboot required.  But this does disable webroot - Not ideal

3. Attempted to create and exception in webroot for VM directory - did not work

4. Thought this might be some weird interaction with Window's new protected folder system in build 1709, disabled that, added VM applications to it - No effect

My company's IT organization has opened a case with Webroot, I'll advise if I find anything.  Please reply if anyone else learns anything!

View solution in original post

DCSpooner
Enthusiast
Enthusiast

good mushijima, i tried to open a case with webroot but i have the home edition. so it is a little difficult to open a ticket. 

VMware was not willing to take it any further than the one guy i talked to. he closed the caes

epmdev
Enthusiast
Enthusiast

Wow, very impressive fact finding.  I confirmed this behaviror on my PC.  If I disable Webroot, all is well with VMware.  With Webroot 9.0.18.38 enabled, VMware fails.

I'll see if I can open a support request with Webroot.

0 Kudos
epmdev
Enthusiast
Enthusiast

Everyone: I sent a tweet to Webroot and this was their response.

Our Team is working on a reproduction of the issue right now. Please submit a ticket to stay up-to-date. ~JP

I've opened a ticket.  Will update this discussion when more info comes available.

Here's a link to the Tweet conversationhttps://twitter.com/thinkfdm/status/922647576201056257

0 Kudos
mushijima
Contributor
Contributor

All, We have a response from Webroot:

We have a defect in place for this issue and have a fix tested but we're pending responses from the product teams for information on the release.

At the moment the only work around this issue is to disable Webroot before launching the Virtual Machine.

As mentioned in my previous message, I have added you onto the defect and will update you once the issue has been resolved.

Regards,

Josko

Webroot Business Support”

0 Kudos
tezgnomedia
Enthusiast
Enthusiast

I too have opened a support ticket and am working with support as well. They did confirm that this is a defect that they are working on and provided an alternative to disabling webroot completely. If you go to the advanced settings --> Shields --> and uncheck "Check files for threats when written or modified," this will allow for VMware to launch virtual machines without completely disabling the product.

0 Kudos
epmdev
Enthusiast
Enthusiast

A solid workaround.  Thanks!

0 Kudos
epmdev
Enthusiast
Enthusiast

Can you please post the Webroot support ticket number?  I got a response from Webroot regarding my ticket.  They want me to put a utility on my PC to capture information regarding the issue.  I don't necessarily mind, but I don't want to go through all this back and forth if other support technicians have already identified and documented the issue.  Thank you.

0 Kudos
mushijima
Contributor
Contributor

So my company's IT reached out again, no additional detail yet.  The ticket # is 119489.  Webroot has already run the diagnostic capture on my machine.  They already identified the "defect", but as of yet have not yet issued a fix/patch/update to address.

0 Kudos