VMware Horizon Community
solgaeDK
VMware Employee
VMware Employee
Jump to solution

Windows 10 Start menu stops working after Windows 10 LTSB 2016 March Cumulative Update

Hello,

Not sure if anyone else is experiencing this, but we are currently using a floating non-persistent pool running Windows 10 LTSB 2016 build (Build 1607). We are running App Volumes 2.12, and using both Appstacks and Writable Volumes UIA+profile template to support certain user-installed apps.

Starting last month, after updating the parent image with the latest cumulative update and creating a test pool to test out the changes with existing appstacks and writables, I found out that the start menu has stopped working altogether. Clicking on the start button doesn't show the menu at all. Curiously, clicking on the Search button does bring up the search menu.

The Event Logs seem to indicate that Microsoft.Windows.ShellExperienceHost AppX Package has been broken, with the following messages recorded on Application event log and Event Viewer -> Applications and Services Logs\Microsoft\Windows\Apps\Microsoft-Windows-TWinUI/Operational log every time I clicked on the start button.

Activation of app Microsoft.Windows.ShellExperienceHost_cw5n1h2txyewy!App failed with error: Invalid value for registry See the Microsoft-Windows-TWinUI/Operational log for additional information.

Activation of the app Microsoft.Windows.ShellExperienceHost_cw5n1h2txyewy!App for the Windows.Launch contract failed with error: Invalid value for registry.

I have already tried to re-register the Microsoft.Windows.ShellExperienceHost and Microsoft.Windows.Cortana AppX Packages, as it seems to be one of the remediation suggestions over the web, but alas, it didn't work. The powershell I tried running under elevated powershell prompt are:

Get-AppXPackage -Name Microsoft.Windows.ShellExperienceHost | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

Get-AppXPackage -Name Microsoft.Windows.Cortana | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

I tried to reset the TileDataLayer database too by stopping the State Repository and Tile Data Model server services, and deleting off the %localappdata%\TileDataLayer folder and let it recreate it, but no luck so far.

Because of this, I am stuck on leaving the Windows 10 build on 14393.693, which is based on January cumulative update. Also, this problem is still present with the recently released April cumulative update.

Anyone else having this problem?

1 Solution

Accepted Solutions
solgaeDK
VMware Employee
VMware Employee
Jump to solution

VMware support has replied back with the following modification that needs to be made on snapvol.cfg.

Basically, you just need to add this line to the snapvol.cfg on your writable template and/or existing writable:

exclude_path=\ProgramData\Microsoft\Windows\AppRepository

For those wondering, the directory includes several System-level AppX (i.e. Windows UWP apps) packages that are required for several windows 10 functionality (yes, there are still some UWP app packages even on LTSB version), and I guess March cumulative Windows Update made changes to the content of that folder. It even lists about resolving a start menu issue on March update according to the KB: https://support.microsoft.com/en-us/help/4013429

I tested this with new writable volumes and existing writable volumes, and it will work on both cases. So assuming you have the same kind for all of your writable volumes, you can use the Update Writable Volume function to update the snapvol.cfg on all existing writables. Otherwise, you'll need to do some editing on a per-writable basis, or delete and re-create the writable.

You can edit the snapvol.cfg of an existing writable if the assigned user has logged in to a desktop and has the writable mounted by browsing to C:\snapvolumestemp\MountPoints\{8e399ec3-0000-0000-0000-100000000000} (or the path where the writable volume is mounted - check the size of the folder on C:\snapvolumestemp\MountPoints to make sure)

From what I could tell, the bolded path might be the same regardless of which writable volume is mounted to the desktop, and since there can be only one writable mounted per desktop at any time, you may be able to script it if you can't use the Update Writable Volume function due to having different kinds of writable volumes deployed. I make no guarantees to that claim though.

Once the snapvol.cfg is modified, you need to log off and log back in before the changes become effective. As long as the start menu isn't broken already, you should be good to go. If it's already broken, then after modifying the snapvol.cfg and logoff&login, try re-registering Microsoft.Windows.Cortana and Microsoft.Windows.ShellExperienceHost AppX packages using the PowerShell commands listed on the first thread to see if you can make it working again. Just make sure to run them on an elevated-privileged PowerShell window.

Obviously, you will want to back up any writable volumes, either via a storage snapshot or a simple copy and paste, before making any modifications.

This is done on App Volumes 2.12, so I can't say if the line is already included on 2.12.1 template. If not, you'll need to update your template and/or any existing writables.

Note that there is no need to modify the snapvol.cfg on appstacks - the line is already included.

View solution in original post

11 Replies
szilagyic
Hot Shot
Hot Shot
Jump to solution

Same exact issue here.  On top of that, for any users that have a Writable Volume that is used with these updates applied, has issues when attached back to the original VMs that do not have these updates.  Problems such as disconnects from the PCoIP session, and inability to re-connect.  Eventually their PCoIP session actually logs itself out.  I opened a ticket with VMware on this, and their solution was to re-create the Writable Volume, and manually copy the user's Windows profile data over.  This is a huge pain and so far we've had to shelf this issue to put out other fires here.

Reply
0 Kudos
solgaeDK
VMware Employee
VMware Employee
Jump to solution

In my case, if I log back to the previous windows 10 desktop pool (i.e. the one where the writable was created from the start), the start menu will start working again. It seems like a well-known issue with Windows 10 start menu due to changes made on how start menu works.

Reply
0 Kudos
szilagyic
Hot Shot
Hot Shot
Jump to solution

Good to know that you do not continue to have issues after you log back in to an older image (without the updates).

Also, we did find out that if we re-create the Writable Volume with the new image (with the updates), the start menu will work.  But, re-creating the Windows profiles and/or Writable Volumes is not an acceptable solution.

I am not sure if the issue is more of a Microsoft problem or something with VMware (App Vol?).

Good luck and let us know if you find a fix, as I would definitely be interested.  We too are locked in to the older version without the updates until this is fixed.

Reply
0 Kudos
Mrcole
Contributor
Contributor
Jump to solution

i have identified that this problem is due to our default domain policy that force the auditing of object access. once I unconfigure it the problem is gone. I have a case open with VMware and there  no workaround for this at the moment.

Reply
0 Kudos
solgaeDK
VMware Employee
VMware Employee
Jump to solution

That is indeed what support has mentioned to me, but unfortunately, we don't have audit object access turned on (by default, not configuring anything defaults to No auditing). We even tested with all auditing settings turned off, but no dice.

I have been updated that the engineering was able to reproduce the issue, and is trying to figure out what's going on.

Reply
0 Kudos
Mrcole
Contributor
Contributor
Jump to solution

I would appreciate it if you keep me in the loop on any resolution. I  stopped the Windows 10 App Volumes rollout here at my company and parked this issue for later review.

Reply
0 Kudos
solgaeDK
VMware Employee
VMware Employee
Jump to solution

VMware support has replied back with the following modification that needs to be made on snapvol.cfg.

Basically, you just need to add this line to the snapvol.cfg on your writable template and/or existing writable:

exclude_path=\ProgramData\Microsoft\Windows\AppRepository

For those wondering, the directory includes several System-level AppX (i.e. Windows UWP apps) packages that are required for several windows 10 functionality (yes, there are still some UWP app packages even on LTSB version), and I guess March cumulative Windows Update made changes to the content of that folder. It even lists about resolving a start menu issue on March update according to the KB: https://support.microsoft.com/en-us/help/4013429

I tested this with new writable volumes and existing writable volumes, and it will work on both cases. So assuming you have the same kind for all of your writable volumes, you can use the Update Writable Volume function to update the snapvol.cfg on all existing writables. Otherwise, you'll need to do some editing on a per-writable basis, or delete and re-create the writable.

You can edit the snapvol.cfg of an existing writable if the assigned user has logged in to a desktop and has the writable mounted by browsing to C:\snapvolumestemp\MountPoints\{8e399ec3-0000-0000-0000-100000000000} (or the path where the writable volume is mounted - check the size of the folder on C:\snapvolumestemp\MountPoints to make sure)

From what I could tell, the bolded path might be the same regardless of which writable volume is mounted to the desktop, and since there can be only one writable mounted per desktop at any time, you may be able to script it if you can't use the Update Writable Volume function due to having different kinds of writable volumes deployed. I make no guarantees to that claim though.

Once the snapvol.cfg is modified, you need to log off and log back in before the changes become effective. As long as the start menu isn't broken already, you should be good to go. If it's already broken, then after modifying the snapvol.cfg and logoff&login, try re-registering Microsoft.Windows.Cortana and Microsoft.Windows.ShellExperienceHost AppX packages using the PowerShell commands listed on the first thread to see if you can make it working again. Just make sure to run them on an elevated-privileged PowerShell window.

Obviously, you will want to back up any writable volumes, either via a storage snapshot or a simple copy and paste, before making any modifications.

This is done on App Volumes 2.12, so I can't say if the line is already included on 2.12.1 template. If not, you'll need to update your template and/or any existing writables.

Note that there is no need to modify the snapvol.cfg on appstacks - the line is already included.

dbrutus
Enthusiast
Enthusiast
Jump to solution

I just would like to say thank you because your post was so helpful. I mounted a writable volume and copied then edited snapvol.cfg with exclude_path=\ProgramData\Microsoft\Windows\AppRepository. I zipped it then used the VMware AppVolumes Manager to update a couple of writable volumes with the updated snapvol.cfg. It worked once they logged off and logged back in. I didn't need to run the powershell script in my case. Thanks again!!!

Reply
0 Kudos
PamAmerican
Contributor
Contributor
Jump to solution

I am having the same issue with my Windows 10 start menu not working.  A case was open with VMware and they provided some information concerning a known issue.  

You are experiencing an issue with the start menu on Windows 10 1607 LTSB. The start menu doesn't work anymore after recomposing your pool.

This is a known issue and it is described in the release notes of the latest Horizon View build 7.1:

After a recompose, refresh, or rebalance operation with a persistent disk, Windows 10 desktops might fail to start, or become untiled from the Start menu. Windows applications can include applications such as Windows Store, native applications, Edge Browser, and Cortana Search. This issue is caused by a characteristic of Windows 10 applications. This problem affects the following desktop types:

Linked-clone dedicated desktops with a persistent disk.

Linked-clone floating desktops with Persona Management enabled that use a persistent disk as a local disk and the Persona Management setting Roam Local Settings Folders enabled.

This issue is not seen with floating or dedicated linked-clone Windows 10 version 1607 desktop pools where user profile is redirected to network share with or without Persona Management enabled. If Persona Management is enabled, the user profile is set to roam with VMware Persona GPO settings.

Release Notes for VMware Horizon 7 version 7.1

http://pubs.vmware.com/Release_Notes/en/horizon-7-view/horizon-71-view-release-notes.html

Also, I got a response from Peter Murphy stating my configuration is not supported and causing the behavior.

My name is Peter Murphy, I am a Technical Support Supervisor in VMware.

We have been speaking with our engineering team and unfortunately there is no way for Windows 10 to work with dedicated linked clones when persistent disks are used.

I would like the opportunity to discuss this with you so please do let me know when you are available.

Kind regards,

Peter

Peter Murphy

  Technical Support Supervisor

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

PamAmerican.

If you are to post answers from support be as kind as to leave the name out of it.. Does seem like a good idea right?

Reply
0 Kudos
Starkz0r
Contributor
Contributor
Jump to solution

solgaeDK

Thank you for your post, your solution of adding exclude_path=\ProgramData\Microsoft\Windows\AppRepository to the snapvol.cfg have fixed the issue our users were experiencing.

Now we need to work on a large scale solution, you mentioned something about scripting so I may go down this avenue

Thanks again :smileygrin:!

Reply
0 Kudos