[AppV 5.1] During a session apps can't be started anymore, 0x55900D02-0x501 and 0x7A602510-0xF RRS feed

  • Question

  • Hi,

    strange issue: I've got a customer for which we host a few application in AppV, published on user-level. From time to time users start complaining they can't start applications anymore, and the feared AppV 'nework error' pops up. All these packages reside in a connection group. In this specific example only one of all those packages can't start anymore. All the others work fine. However, when the user logged in this morning it worked fine, and he has not logged out since. During his (or someones) session something happened which breaks a package. We have RDS servers with several users of the same customer on there. None of them can start that specific application anymore on that RDS, but people that still have the application open can work in it just fine. When I drain that RDS and have them login to another RDS there is no problem, so my assumption is something breaks at RDS level. I haven't got a clue what though. In the past I've fixed this by removing the connectiongroup and logging in with a user again so the connectiongroup and the related registry builds up again. It works perfecntly fine then for another week or so before it happens again one one of the RD servers.

    The evenlog shows two entries per 'error':

     application from package ID {c755dc0b-2fcd-4203-9063-d2a94a9eb545} failed to launch. process ID 29028, error 0x7A602510-0xF.
     application from package ID {c755dc0b-2fcd-4203-9063-d2a94a9eb545} failed to launch. process ID 29028, error 0x55900D02-0x501.

    I don't recignize both error numbers. How to troubleshoot this? As this seems to be on RDS level and doesn't roam with the user (we use roaming profiles) I think it's on the RDS. However, all packages and registry that do NOT roam with the user is per definition in HKLM or on disk where users don't have modify permissions. Ofcourse the AppV client has permissions but still I don't know why it breaks.

    Anyone with tips / hints?

    Thursday, April 14, 2016 1:58 PM

All replies

  • So basically there's just 1 packages which breaks (breaking the conneciongroup too). Or is this just an example, and you experience this issue with random packages?

    What does your procmon tracelog tell you? How do the permissions on your appvinstallation root look like (SYSTEM should be owner).

    Check out this website, on how to troubleshoot the appv5 eventlog.

    Roy Essers

    Saturday, April 16, 2016 2:24 PM
  • I've not looked into this for a while. Permissions are fine, they should be otherwise I would have all other sorts of issues as well. But yes, this is ONE connectiongroup failing because of this issue. All others work perfectly fine. I haven't been able to look into this with procmon as the users can simply not work with the connectiongroup anymore at all bringing their business down. As I cannot reproduce at will it's harder to get the time to really investigate, although we will have to do that at one time.

    By the way enabling all debug logs is a thing I had to do several times before in 5.0, but now in 5.1 I don't get much additional logs... have to look into that as well.

    Wednesday, June 22, 2016 9:41 AM
  • Hi,

    it happened again a few times the last days. The weird thing seems to be now that I don't need to do any repairs or remove connectiongroups or anything, when all uses that use that application have logged of from that server it starts working again on that machine by itself. The errormessages in the AppV logs are still the same though.

    Wednesday, June 29, 2016 7:14 PM
  • Another update: I've managed to create a snapshot of a machine when having the issue. I can now sort of reproduce, in the sense that I can revert that snapshot and start the application with the error as long as I keep the users logged in. There is one specific user in this case that 'locks' it, when I log that user out the issue is gone. I've enabled debug logging and this is the only error in the servicelog:

    2016-Jun-30 16:27:20.177 - VirtualizationManager: [2204].[2336]: ERROR: AppData download task failed. Error 12330893182463574018; user S-1-5-21-<SID>; package c755dc0b-2fcd-4203-9063-d2a94a9eb545.
     [AppV::Client::Virtualization::VirtualizationManager::HandleVeCreated; 810]

    The operational log shows two errors:

     application from package ID {c755dc0b-2fcd-4203-9063-d2a94a9eb545} failed to launch. process ID 28932, error 0x7A602510-0xF.

     application from package ID {c755dc0b-2fcd-4203-9063-d2a94a9eb545} failed to launch. process ID 28932, error 0x55900D02-0x501.

    Thursday, June 30, 2016 2:39 PM
  • I have this VERY strange behavior now. Same behavior and same event error code.

    We have tried most things we can think of, but we can't get much closer to the issue than this error message.

    Did you ever solve this or get any closer to understanding why this happens?


    With some help from some amazing people in the community I was pointed at this ars thread - I am putting it here in case some lost soul sysadmin stumbles across this horrendous bug.

    TL;DR: Upgrade to Server 2016 - bug exists 2003-2012R2.


    • Edited by Pål Røtnes Wednesday, February 7, 2018 9:09 PM new info
    • Proposed as answer by Pål Røtnes Wednesday, February 7, 2018 9:09 PM
    • Unproposed as answer by Robert Gijsen Wednesday, February 7, 2018 9:35 PM
    Tuesday, February 6, 2018 5:58 PM
  • Unfortunately that's not a fix, but a very bad workaround. Now we are actually moving to 2016 farms with all their bugs and terrible designchoices, but still for 2008r2 we haven't ever fixed this specific issue.

    Any hints to a fix still welcome.

    Wednesday, February 7, 2018 9:38 PM
  • Standard Windows error code 0xF indicates INVALID DRIVE, and 0x501 is 

    1297 (0x511)

    A privilege that the service requires to function properly does not exist in the service account configuration

    Off hand this sounds like a problem with roaming profiles/home drives/etc.  For the App to launch the App-V client service must impersonate the user to write COW data, typically directed to one of those areas in an RDS scenario.

    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (http://www.tmurgent.com/Books)

    Friday, February 9, 2018 3:26 AM
  • While I haven't run into this for a while anymore, as we are moving to RDS2016 (so far no issues on THAT part...) I had a though about Tim Mangans post, about network drives not available, and a possible relation to at least our environment. We have some AppV apps that actually run from a mapped network drive from within the virtual environment. Recently I've had two seperate cases were we had issues on mapped drives. Not the users' homedrive, but another mapped drive, that seemed to get disconnected for a very brief period after a seemingly set time.

    It turns out we had the drivemaps in GPO set to 'replace', rather than 'update'. It turns out that when the user policy refreshes, which is every 90 minutes per default (https://technet.microsoft.com/en-us/library/cc975932.aspx), that causes a brief disconnect. We've updated all our GPO's to reflect 'update' on drive maps, and those reconnect issues are gone.

    Pål Røtnes, any chance you have drives mapped with the replace / create option?

    Tuesday, March 20, 2018 7:58 AM