User Scripts Broken In App-V 5.0 SP2 For Local Accounts

I received a comment on my post Side effects of clomid from someone that was unable to run the script since updating to SP2.  I did a bit of testing in my home lab and found it still worked fine, so put it down to user error and carried on with my day.

Until, that is, I got the very same error working on a client’s system.  I had a UserScript configured to run at StartVirtualEnvironment, but whenever it was launched I saw the following error:

Script error

MSVCR100 error

The error code 534 in hex (1332 decimal) can be looked up here:

1332 (0x534)No mapping between account names and security IDs was done.

As well as the 534 error, I’m getting an MSVCR100.dll not found error. Disabling App-V scripts stops both of these error messages and the application loads correctly.  The second error is a curious one, since by default if you install only the App-V 5.0 SP2 client on a clean machine, you will only have the 64-bit MSVCR100.dll present in C:\Windows\System32.  For some reason, the 32-bit virtual application is being told to use this dll when it doesn’t exist under C:\Windows\SysWOW64. I think this second error is nothing to worry about, being just a curious side effect of the virtual environment not starting up correctly due to the first error.

So after a lengthy troubleshooting session examining the differences between the working and non-working systems, I came to the conclusion that user scripts are broken in App-V 5.0 SP2 for local accounts only. Log on with a domain account and everything is ok.  Whether or not the accounts have admin rights or not makes no difference. The RTM and SP1 releases are not affected by this issue.

Luckily pretty much all live implementations of App-V will be used with everybody logging on with domain accounts, so this isn’t a major issue.  Packagers however tend to sequence and test using local admin accounts, which is where I and others ran into the problem!

10 responses on “User Scripts Broken In App-V 5.0 SP2 For Local Accounts

  1. Dave B

    Nice blog Dan….I struggled for days trying to get my script working before I was aware of this problem. I have also found your App-V 5.0 file permissioning and the UAC manifest work around posts useful. How are you by the way?

    1. I’m very well thanks Dave, glad to be of help!

  2. Simon

    Hi, I just wanted to comment and say that I’ve had this MSVCR100.dll error on applications that I have updated, or unpublished and re-published to the RDS servers. The only way I have got round the error is to delete their remoaing profile. All users are domain users. I’m using SP2 as well.

    1. Next time you encounter this, if you only have the x64 VC++ 2010 Redist installed, try adding the x86 version:

      Seems like the OS or App-V client, which are 64-bit, see that the latest version available is MSVCR100.dll and tell the application to use that. Since the app is 32-bit, it looks in SysWOW64 instead and doesn’t find the dll. If this is what is indeed happening, adding that x86 vcredist should sort it.

  3. U2 Pas

    I also had this error with App-V 5.0 SP2, even with Hotfix 2 and found no way to get rid of it.
    Finally Hotfix 4 fixed it now -> AppV5.0SP2-Client-KB2956985.exe

    1. Thanks, there was no mention of that fix in the release notes, I wonder what else they fixed!

      1. Not sure if SP2 HF4 did in fact fix this, but I can confirm the issue is still present in SP3.

  4. IV

    This issue has been driving me CRAZY for the last two days. Thanks very much for posting this!!

    FYI I am on Hotfix 5 and this issue is still present. Package refuses to launch as a local user on my test machine, but script works fine when I test it on a domain machine. I don’t think it’s been patched.

    So frustrating! How has MS not fixed this yet… are even their test machines always bound to a domain??

  5. Vinod


    I’ve tried to add machine scripts [Add & Remove] results with the same error. But, this worked fine with [Publish & UnPublish].

  6. Dave Fanning

    Hi Dan.
    Thanks for this. I too have been tearing my hair out wondering why this does not work. It looks like it is still in issue in the Win10 Anniversary build native client.

Leave a Reply