Error: 0xFD01F25-0x5 - on package run RRS feed

  • Question

  • Hi everyone

    our environment have the following details

    • Pooled VDI Machines with Windows 7 SP1 Base Image

    • Profiles - Folder Redirected by policy (APPDATA, Desktop, Documents, etc.)

    • App-V Client 5.0 SP2 Hotfix2 (as we saw on TechNet, App-V 5.0 SP2 supports APPDATA redirection.)

    • App-V Client 4.6 SP3 is installed side-by-side with App-V 5.0

    • App-V Server 5.0 SP1 Hotfix4

    up until today we have the same environment but without redirection of the APPDATA and with App-V 5.0 SP1 clients. everything was fine when we ran App-V 5.0 packages.

    now, on the new configuration we experiencing a weird behavior where we can't run App-V 5.0 packages.

    when we try to run any package nothing happens on the GUI level and on the event viewer we see the error:

    Process 8152 failed to start due to Virtual Filesystem subsystem failure. Package ID {ad081fca-0f96-41ae-aec4-af51f7b0c7a1}. Version ID {780420ec-fc0a-406c-8bd3-0994fc7a0023}. Error: 0xFD01F25-0x5

    internet searches don't give me any results about this error number.
    I know there's a lot of information about the error 0xFD01F25-0x7B but it is not the same problem.

    our issue is for all the packages and App-V 5.0 SP2 Hotfix2 is installed and supposed to fix those kind of issues

    we tried to reset the profiles, the app-v cache, the app-v configuration... nothing changes :/

    I'de love to get some new ideas

    Tamir Levy

    Wednesday, April 30, 2014 10:31 AM


All replies

  • Hi Tamirlevy,

    0x5 means access denied (http://msdn.microsoft.com/en-us/library/windows/desktop/ms681382(v=vs.85).aspx)

    Start a procmon trace with a access denied filter and check what happens.

    Check also this link:


    Now sports fans this is not only modify permissions on the redirected appdata folder but modify permissions on the ROOT of the redirected folder share!

    Wednesday, April 30, 2014 11:56 AM
  • Hi try SP2 Hotfix 4 first, which just came out.
    • Edited by Roy Essers Friday, May 2, 2014 3:35 PM
    Friday, May 2, 2014 3:35 PM
  • Hi thanks for your suggestions guys unfortunately, Hotfix 4 didn't solve our problem. Nazim, I read the post you put in your thread which is very interesting, though giving modify permissions on the profiles share for the computer account is not even an option. we use a pooled VDI environment. everytime users logon they get a different machine account and we're not going to give modify permission for "Domain Computer" just because App-V 5.0 doesn't work as expected. App-V 5.0 SP2 Hotfix 4.0 did solve some of our permissions \ network share problems but not this one. if there's another solution, we'll be happy to hear in the meantime we try to open a ticket with MS

    Tamir Levy

    Wednesday, May 21, 2014 11:05 AM
  • Tamir - any luck with this?  We run the same configuration and a subset of users gets that exact message:


    We turned on debug logs, and this shows up:

    Failed to get long path from '\\?\UNC\REDACTEDSERVER\home$\REDACTEDUSER\Application Data'.  Error code: 0xFD01F25-0x5

    Failed to load runtime configurations. Error code: 0xFD01F25-0x5

    Microsoft: Many deployments using Folder Redirection involve anonymous machine accounts (RDS Servers, VDI Desktops) where providing access to the redirected folder is simply not an option given the potential exposure of private data.  This is not a valid solution or workaround in most environments.
    Monday, June 16, 2014 6:48 PM
  • Hey Cookie.Monster

    yes! we managed to solve the issue

    I don't know why but App-V needs the the user will have write permissions on the full path of the appdata share.

    if %APPDATA% = \\Server\Share\Appdata\User\Appdata\Roaming 

    you need to verify you have a write permissions to \\Server\Share\Appdata\User

    we saw on procmon that app-v tried to create a file over there and gets "ACCESS DENIED"

    after we added write permissions we managed to solve it

    we created a powershell script the added the permissions for all the users, but the better solution is to check the permissions of the upper folder! when a new user logs on and the folder gets created it should work fine without any issues

    good luck

    Tamir Levy

    Tuesday, June 17, 2014 8:09 AM
  • Hi all,

    In case it helps, here is the resolution that worked for us:

    • Failing configuration:  Folder redirection configured for \\SERVER\home$\%USERNAME% (this failed regardless of whether AppData was nested one or more layers deep).  5.0 SP2 HF4 did not resolve this issue.
    • Working configuration:  Folder redirection configured for \\SERVER\%USERNAME%$

    Each user has their own share.  So for example, I might have \\SERVER\COOKIEMONSTER$.  With this configuration, the user has permission to the root of the share, and thus this works without issue.

    Wednesday, July 2, 2014 12:40 AM
  • Hi Cookie.

    it shouldn't matter if the security permissions are configured as needed

    and the way you use is harder to manage in a large environment, as it is not enough to create new users via AD, you should also create a share for each new user, instead of granting them permission to create subfolders under \\server\home$\ and then it will be done automatically on first logon

    Tamir Levy

    Wednesday, July 2, 2014 5:45 AM
  • Have you tried HF4 to see if that fixes the issues? MS modified some file access functions, though they haven't explicitely mentioned the redirected APPDATA challenge:  http://support.microsoft.com/kb/2956985/en-us


    Twitter @kirk_tn   |   Blog kirxblog   |   Web kirx.org   |   Fireside appvbook.com

    Wednesday, July 2, 2014 10:05 AM
  • I agree, definitely doesn't make sense.  Unfortunately, nothing else seemed to work, while this resolved the issue.

    On a positive note, there's no manual intervention needed, these individual user shares are created automatically.

    Just to clarify, this didn't work:

    • Target Folder Location - Create a folder for each user under the root path
    • Root Path - \\SERVER\Home$
    • For user Clair, this folder will be redirected to - \\SERVER\home$\Clair\Application Data

    This did work:

    • Target Folder Location - Redirect to the following location
    • Root Path - \\SERVER\%USERNAME%$\Application Data
    • Resulting example - \\SERVER\Clair$\Application Data

    In both cases, Clair has access to home$\Clair.  In fact, not something we would ever do, but granting Full Control to Clair did not resolve the issue.

    Not optimal from my perspective, but I haven't seen any functional alternatives, beyond disabling redirection and attempting to script out the synchronization of files (this isn't my project, and I'm helping someone without strong scripting experience, so that's a big no).

    Wednesday, July 2, 2014 12:52 PM