locked
AppV 5 - The application failed to launch (error code 0X4FC08204-0000002C) RRS feed

  • Question

  • Have another interesting Microsoft problem; this time with App-V 5.0 SP2 client. We're running Windows 8.1 Ent w/ Update 1 and App-V 5 hotfix 5 on the clients.

    App-V clients seem to publish, download and run the App-V packages fine, initially; however, after, some time of use, users receive this error:

    AppV 5 - The application failed to launch (error code 0X4FC08204-0000002C)

    I did the research on the error and found nothing. Event viewer doesn't yield anything significant nor the app-v debug logs. Deleting the user's profile seems to temporarily resolve the issue until it reoccurs. We previously ran into an issue with Update 1 causing logon user profile service failed error with App-V until installing App-V hotfix 5, which fixes it. Not sure if this hotfix has introduced this problem.

    Anyone running into this issue? Suggestions? Thanks in advance. 

    Monday, September 8, 2014 5:14 AM

Answers

  • As Nicke said calling MS would be a good idea...but any chance you having roaming profiles or anything that could be changing the permissions on the folders?
    Wednesday, September 24, 2014 4:27 PM

All replies

  • We are having the same issue. In our situation it appears that the profile deletion is what causes the issue in the first place. We have a GPO in place to delete profiles that have not been used in 24 hours. This occurs on every restart. (We are computer lab environment at a large university). 

    The only thing that I have been able to do to thus far to fix the issue is rename the U:\Users\USERNAME\AppData\Local\Microsoft\AppV to AppV.old. This then allows the AppV folder to be recreated which allows the application to launch.

    We will be creating a help ticket with MS probably tomorrow.

    Edit: We also had the login issue with Windows 8.1 and your thread was what helped solve that fiasco. Thanks!
    • Edited by nip24ATpitt.edu Monday, September 8, 2014 8:39 PM
    • Proposed as answer by Mike Plichta Wednesday, September 9, 2015 3:42 PM
    • Unproposed as answer by Mike Plichta Wednesday, September 9, 2015 3:42 PM
    Monday, September 8, 2014 8:35 PM
  • Glad I'm not the only one. Kind of strange that a profile deletion would cause the issue. For us, a brand new user profile will not experience the problem; it takes an action to occur (which is what we're trying to figure out) which breaks App-V and throws that error upon app launch. Deleting the user profile and re-creating it temporarily solves the issue. Additionally the problem is isolated to the user's profile account where one user may experience the issue but the other may not. Removing the packages entirely and the appv folder structures as well as uninstalling/reinstalling the client doesn't seem to do any good but an actual profile deletion does. 

    I will try renaming appv folder in the %localappdata% and see what I get. 

    Good luck with MS. I will update this thread as I find things...hope you do the same. Also, glad to hear that my thread helped you.

    Tuesday, September 9, 2014 6:13 AM
  • It appears that renaming the AppV folder in the affected user's %localappdata% allows AppV to create a new folder. From there, pulling down the AppV applications and launching them is successful. Somehow and something in that folder gets corrupted.

    I'm not sure this is a workaround as deleting the profile essentially does the same thing and the problem returned later on (although not immediately).

    Tuesday, September 9, 2014 5:17 PM
  • We are having the same issue. In our situation it appears that the profile deletion is what causes the issue in the first place. We have a GPO in place to delete profiles that have not been used in 24 hours. This occurs on every restart. (We are computer lab environment at a large university). 

    The only thing that I have been able to do to thus far to fix the issue is rename the U:\Users\USERNAME\AppData\Local\Microsoft\AppV to AppV.old. This then allows the AppV folder to be recreated which allows the application to launch.

    We will be creating a help ticket with MS probably tomorrow.

    Edit: We also had the login issue with Windows 8.1 and your thread was what helped solve that fiasco. Thanks!
    Any luck/update on this? Also, any help from Microsoft staff would be appreciated here.
    Monday, September 22, 2014 2:31 AM
  • Hello,

    I would raise a support call with Microsoft regarding the topic.


    Nicke Källén | The Knack| Twitter: @Znackattack

    Tuesday, September 23, 2014 8:29 PM
  • I am seeing the same thing on Windows Server 2008 R2 SP1 using App-V 5 hotfix 4. Renaming the folder works temporarily, but the problem resurfaces the following day. 
    Wednesday, September 24, 2014 4:05 PM
  • As Nicke said calling MS would be a good idea...but any chance you having roaming profiles or anything that could be changing the permissions on the folders?
    Wednesday, September 24, 2014 4:27 PM
  • APPV 5 sp2 HF5

    I have one machine with the same error and behavior.

    The machine is in lab, so not a big deal...

    But just as a preventive measure/troubleshooting I would like to ask if the source of problem was found.

    I had 6 profiles on the box, one of them Domain Admin. v-Apps stopped to work for all profiles.

    I deleted all domain profiles. Logged again with each user name. The same happened again (as mentioned in previous post).

    Yes renaming the folder Users\USERNAME\AppData\Local\Microsoft\AppV to AppV.old does the trick.

    I have computers with multiple accounts (don't think that this matter, but will be more difficult to use the suggested fix)... so want to be ready in case the problem will arise.


    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis

    Friday, February 20, 2015 3:31 PM
  • Calling MS is still a good way to go, but why I asked if roaming profiles are in play is because App-V freaks out if the permissions on the folders are changed -- and there are a lot of 'unusual' permissions set, esp on the COW folders.  I don't know how the client knows, but its not as simple as making the permissions what they should be (or more open) and letting the client publish.  I went through a lot of this before VFS write was enabled and testing Dan Gs workaround.

    Its very hard to know if this is the case without understanding more what happened, what your environment looks like, etc.  I could be way off. 

    Friday, February 20, 2015 5:22 PM
  • native Appv infra: Apv Management, SQL and Publishing servers.

    More than 100 machines using APPV. no problems ....

    Say truth, on problematic machine I tested Remote App for which I deleted profiles. So it is exactly what happed for  other posters. The conclusion: APPV doesn't likes user profile recreation :).... Joke... until somebody will have an answer from MS. I would call in case of multiple failures....


    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis

    Friday, February 20, 2015 7:15 PM
  • If you can recreate I'd be curious if the permissions on the folder have indeed been changed.  Some profile management software (I'm looking at you Persona) do not record/restore folder permissioning and it is assumed under standard practice that a roaming folder will have normal permissions (user as owner with full rights, etc).  Persona can't roam when the permissions are different, and App-V throws errors when the permissions are so that Persona can roam the files.  Its very possible the folder is getting pre-created by something adhering to that 'normal' practice and App-V doesn't like it.
    Deleting the folder and letting App-V create it allows it to create with the permissions it wants.

    I have to look at some of this stuff again in SP3, but I doubt the behavior has changed much in this regard.

    Friday, February 20, 2015 8:23 PM
  • I got your analytical point...

    And YES I will try to recreate the issue. I removed all profiles. And logged in just with 2 existed before names (one of them domain admin). v-App didn't work after login but only after renaming the folder.

    Also, I can log in with a brand new user name to see if it is profile related.


    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis

    Saturday, February 21, 2015 11:38 AM
  • can confirm that the error occurs only for a profiles that were removed and recreated after login.

    Renaming the folder Recreates a new one on starting v-App.

    Log in with newly created account in AD works without any problem.


    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis

    Monday, February 23, 2015 1:28 PM
  • can confirm that the error occurs only for a profiles that were removed and recreated after login.

    Renaming the folder Recreates a new one on starting v-App.

    Log in with newly created account in AD works without any problem.


    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis

    I can confirm that as well. Was this only for testing? Did try this on production workstations and have they been working since deleting the App-V folder?

    Strange because it's not an issue for my desktop users but only my mobile users. The only thing I can think of different is the Wi-Fi, WAN, and VPN client that could be causing that issue. I haven't been investigating this issue as the users affected by this issue don't rely too much on App-V at this point.

    I installed SP3 on a mobile user that was experiencing this issue and will follow up and let you guys know.

    Monday, February 23, 2015 3:24 PM
  • in my case it is Thin (HP T620) in test env. Not appv testing, but found eventually that v-Apps are dead after profile recreation.

    100+identical machines have no issue.


    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis

    Monday, February 23, 2015 5:33 PM
  • in my case it is Thin (HP T620) in test env. Not appv testing, but found eventually that v-Apps are dead after profile recreation.

    100+identical machines have no issue.


    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis

    Confirm that SP3 resolved the issue for one of the mobile users affected. SP3 has been installed on his system for months now although he hasn't used the app-v client much.

    Monday, February 23, 2015 5:43 PM
  • Steps to reproduce:

    1. Log on as admin
    2. Install a AppV package of your choice (we use offline mode)
    3. Log off, logged on as a standard user (no profile ever on this computer)
    4. Run the installed AppV program
    5. Reboot
    6. Logon as admin
    7. Delete the profile for that standard user using the advanced system menu.
    8. Reboot
    9. Logon as the same standard user
    10. AppV program fails to launch Error 0x4FC08204-0000002C

    Details and fixes

    We have AppV5 SP2 with 3 hotfixes installed on our image.  We have the copyprofile flag set in the unattend.xml file to send the administrator profile settings to the default user profile during the first startup.  This causes the following folder to replicate to any user who logs on.  I'm not sure why it causes problems only the second time, but you can fix the problem by removing this folder.  Future profile deletions no longer corrupt AppV.

    C:\Users\Default\AppData\Local\Microsoft\AppV 

    This folder only contains another blank folder inside it so I don't see why there are issues unless some permissions are incorrectly changed during profile creation.  That still doesn't explain why it's only a problem when the user has logged on prior and their profile was deleted.  

    • Proposed as answer by Mike Plichta Wednesday, September 9, 2015 6:45 PM
    Wednesday, September 9, 2015 6:45 PM