none
Certain applications no longer working without new user profile RRS feed

  • Question

  • Hello All,

    I was wondering is anyone has seen this before or could point me in the correct direction. Over the last week a few of our AppV (5.1) Applications have stopped working for some users. Most of them were sequenced months or years ago and have been working fine until last week. For some reason they have just stopped working and we cannot work out why. It's not all applications (so far only 4 out of many hundred) and the funny thing is that it is not for all users. We assume it's some sort of Windows update but we cannot work out what exactly.

    So let me explain what we have found out so far;

    * Some apps fail to load and come up with errors (different depending on the App). So far the major one is SAP GUI.
    * The issue seems to be profile related. The users can work fine on different machines and different users on a problem machine are fine. Recreating a users profile resolves the problem (unfortunately we have so many users it is not practical to do this for everyone).
    * Running with elevated permissions makes the app work (but only for that run).
    * If the machine has the problem it has it for all the faulty applications for that one user. 

    * Not all of our machine are having the problems and we cannot manually break a machine. Although many hundreds of our machines have the problem (including mine).
    So going form this it suggests it is a permissions problem for the individual user, but it makes no sense that recreating the profile fixes it.

    We have tried everything we can think of including removing all Windows updates installed in the last month, giving full permissions to the user profile and registry, reinstalling C++, looking through procmon and nothing seems to be obvious. We have also completely removed the applications from AppV, recreated them and stripped AppV off the machines before reinstalling but with no luck. We have updated our server with the latest patch and have pulled down all Windows updates to the local machines.

    I know without giving full details it will be impossible for anyone to diagnose but I was hoping someone may have seen this before or might be able to point me somewhere. 

    Thanks in advance :)

    Edit - Forgot to say our standard build is W10 1803, we do have some 1511 and 1703 which also have the issue but is seems to be mainly with 1803. W7 not having the problem.
    Tuesday, March 19, 2019 11:35 AM

All replies

  • check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Virtualization\LocalVFSSecuredUsers.
    All sids should point to %USERPROFILE%\AppData\Local\Microsoft\AppV\Client\VFS
    If that's not the case you'll get publishing failures (040000002C)... Is this the issue you're also facing?

    I'm still seeing this issue on win10 (1703/1709/1803)... I've implemented a ConfigManger Baseline with remediation script, which corrects this issue... If interested I can share it with you.

    Other issues I've seen in the past where vReg related but allready fixed last year (just make sure to note use cReg), an other issue we recently where experiencing you can read here.


    Roy Essers

    Tuesday, March 19, 2019 4:34 PM
  • Thanks for the reply. I check in there and everything looks correct and we don't get a publish failure. The Apps are published to the machines fine but when running the apps themselves produce an error (so not AppV).

    A lot of the errors we are getting seem to relate to .DLL or .OCX files, and I can see this was an issue some time ago but Microsoft released several patches and we have them on our machines.

    We don't really use Run Virtual so I don't think it is that.


    Wednesday, March 20, 2019 10:08 AM
  • In the past we had some issues with duplicate user profile folders and App-V. I discovered that there are absolute per user path references in the machine part of the registry. (What I really don't like).

    HKEY_LOCAL_MACHINE\Software\Microsoft\AppV\MAV\Configuration\Packages\<PkgID>_<VersionID>\UserConfigEx\<User SID>\CopyOnWriteMappings

    Maybe the issue is related to those entries?


    Thursday, March 21, 2019 3:43 PM
  • Sorry for the long delay. So after some further investigation we narrowed it down and found out it has something to do with the following reg;

    HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Microsoft

    If we delete or rename the key our software starts working again. Looking at this reg it seems that some information is missing (if we compare to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Packages). 

    So it looks like for some reason the values are not being correctly placed into the virtual store.

    Does anyone know what the hell is going on? As I said most of these applications have been working fine for months or years so we are unsure what has changed to cause this problem. It's not happening to all users but in total we have had about 250 people reporting it. There are also reports form some users that after renaming the problem has come back a few days later.

    As far as I am aware nothing has changed policy side and as I said we do roll out windows updates but not all machines are getting the problem.

    Any help much appreciated.

    Thursday, March 28, 2019 3:44 PM
  • OK so to add even more confusion if we change the ContainerRegistryEnabled key value to 1 in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Compatibility it also seems to resolve the issue.

    So looking at it this is changing the system to use Container Registry instead of Vreg. From what I can see Creg actually caused a load of problems so Microsoft released several patches to push everything back to Vreg. 

    We have never set anything to specifically use Creg and have had the patches applied for a while so not sure this is working. This all seems to point to the same thing though, that for some reason a few of our applications are having problems with the Vreg. 

    If anyone can help it would be appreciated.

    Wednesday, April 3, 2019 10:41 AM
  • Sorry Gary. Not going to help but wondering if you had got any further regards all of this. We are having similar issues. Fortunately for us not quite as frequently as yourself. This appears to be the most similar Forum article content-wise. Same sort of environment and experience and all Event Log Errors point to KB articles that are just not relevant to us. I know the packages themselves are fine and we are resorting to a combination of flushing app / new local Profile but I am keen to get some closure if possible.
    Thursday, June 13, 2019 3:28 PM
  • Have a look at the release notes for  February 13, 2018—KB4074588 (OS Build 16299.248)

    Addresses issue with App-V packages that aren't compatible with registry virtualization using kernel containers. To address the issue, we changed the registry virtualization to use the earlier (non-container) method by default. Customers who would like to use the new (kernel container) method for registry virtualization can still switch to it by setting the following registry value to 1:

    • Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Compatibility
    • Setting: ContainerRegistryEnabled
    • DataType: DWORD

    At the first glance, this issue seems to be related with [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Compatibility]
    "RegistryCompatibilityMode"=dword:00000001.

    which has been discussed in few other topics in here. If this is the root cause of the issue, somebody created a script which automatically fix the broken packages - cannot find the link right now, it's been over a year since I faced this issue. I would not recommend it though. Best approach would be to upgrade to a newer version of Windows 10.

    What's awkward though and it does not make sense to me is Microsoft fixed this in 1803, but you say you're facing this on 1803 too.


    Sunday, June 23, 2019 12:11 PM