KB4517211 causes VMware Workstation Pro 14.1.7 to fail

Good morning,

I have discovered that my installation of three updates on Saturday September 28 2019 has caused the failure of VMware Workstation Pro 14.1.7 to start. On Sunday, when I attempted to run VMware Workstation, it produced a Notification that said "VMware Workstation Pro can't run on Windows". 

Luckily, I was able to find that, when I uninstalled the three updates, it was the uninstallation of KB4517211 that allowed VMware to run.

Now, this morning, KB4517211 has installed itself autonomously - I thought that should not happen any more - and VMware again "can't run".

So, once again uninstall KB4517211, restart and VMware can now run. Microsoft Updates now paused for 7 days.

I would like someone to tell VMware about this: I cannot find a way to do it myself. Even better if Microsoft and VMware can sort this out.

I hope that this post is not unnecessarily duplicating news from others: this is the first time I have posted anything, so don't really know where (or how) to do it.

Happy days, Guy

 

Discussion Info


Last updated October 19, 2019 Views 6,230 Applies to:

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.

Related article:
https://www.tenforums.com/virtualization/141820-vmware-workstation-pro-cant-run-windows-message.html#post1737908

Method 1 usable for Group Policy setting, much simpler than creating & deploying custom shim database.

Oct 8, 2019: Main article updated, regfile method added.

Hi potkan,

Much obliged. I will give that a try in the morning. Guy

same , doesn't work on my surface pro 6, that sucks

It works Potkan. Many thanks for the info.

Best regards

Hi potkan,

Your solution works very well, very many thanks.

For the record, before updating I copied the sysmain.sdb file to my USB stick. Then I updated, found the sysmain.sdb file, went through the procedure for changing its Ownership and Access rights, then renamed it sysmain.old and finally copied the previous sysmain.sdb from the USB stick into the appatch folder.

I noted that the next Windows update for 1903 KB4522738 caused the same problem.

I suspect that future updates for 1903, etc, will cause the same problem. But now I have my trusted sysmain.sdb ready to hand!

Many thanks to all who have replied and helped me through this incident. I think that the least VMware should do is give us a free upgrade to a version that can work with the new sysmain.sdb files.

I also tested it and it looks good, but I have a lot of other problems. I'm not sure if this isn't from the sysmain I exchanged or generally from the latest updates... For example, I can't log in to the office account anymore, the info center doesn't open anymore, etc.

In general this is not a solution, I have 88 computers with VMware 14 here, but since VMware 14 itself runs well, I would say that the sysmain is a little too strongly set from Microsoft. I think the solution must be that Microsoft unlocks the program again.

Hi GuyMeakin, you're most welcome.

Please check also new 3rd method provided by Biohazard, it can be more convenient for you.

Regarding VMware and free upgrade - very good argument you can find at https://communities.vmware.com/message/2890845#2890845 however I don't think it is realistic expectation.

Reverting your operating system (os) to previously build can solve the problem. 

Also prevent the updates causing the problem from reinstalling. 

This can be achieved by using microsoft tool - “Show or Hide Updates” troubleshooter (https://support.microsoft.com/en-us/help/3073930/how-to-temporarily-prevent-a-driver-update-from-reinstalling-in-window)

Source :

1. http://mauricemuteti.info/solved-vmware-workstation-14-1-7-12-5-9-15-5-pro-cant-run-on-windows-version-1903-update-problem-fixed/

2. https://www.youtube.com/watch?v=OrLM7MZd2UQ

Hi azfavorite, Thanks for your help.

You may have seen my post that I solved the problem by replacing the new (after update) sysmain.sdb with the previous version (in my case dated 31 Aug 2019).

I have now found that, after updating with the latest update for 1903, the sysmain.sdb had not been replaced, so I am still using the 31 Aug 2019 version and VMware 14 works.

I guess that the sysmain.sdb has not been replaced by the update because, in the process of replacing it myself earlier, I had to change the Ownership and the Trusted Installer disappeared as an agent that has access to the file: the wonders of Windows!

GuyMeakin : Recent three CUs include the same sysmain.sdb; that is why your sdb remains the same (no reason to override it). If you want, you can restore your backup copy and use some added method to allow VMware Worksation to run.

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.