locked
App-V Application fails to launch on 1703 but works on 1607 RRS feed

  • Question

  • I have an App-V application that fails to launch on 1703 with the following error message.

    The application failed to launch.
    This may be due to a network failure.
    Error code: 0x00001A35-800705B6

    This same application works on 1607 and some of our other App-V apps are working on 1703. There are no OS restrictions on the application. There is nothing useful that I notice in the logs nor are any errors recorded in the logs. Has anyone ever seen this error or can anyone help me decipher it? 

    Monday, May 22, 2017 1:49 PM

Answers

  • Hi,
    I seem to have found a solution to this issue. Open the appv5 package in the sequencer and look at the virtual registry keys.
    If any of these keys exist, highlight them and delete them, save the package and re-import into the appv5 server, the app should now load correctly.

    registry\user\ANY SID
    registry\user\appvcurrentuser\system
    registry\user\appvcurrentuser\Network
    registry\user\appvcurrentuser\Software\Microsoft
    registry\user\appvcurrentuser\software\Classes

    registry\Machine\system

    registry\Machine\software\Microsoft\windows
    registry\Machine\software\microsoft\windowsnt



    Monday, August 21, 2017 10:53 AM

All replies

  • As we're not yet on 1703, no... Although it should work, did you try resequence on 1703? If possible open a case with MS.

    Roy Essers

    Tuesday, May 23, 2017 7:16 PM
  • I didn't resequence it on 1703 but I did try upgrading a 4.6 version of this package using the 1703 sequencer. It did not change anything though. If I could easily resequence this package I would do so. I was hoping that someone would know more about this error message.  Thank you!


     
    Tuesday, May 23, 2017 7:48 PM
  • No sorry, it's not telling me much, could you enable the advanced debug log, and check for a more detailed log.

    Roy Essers

    Tuesday, May 23, 2017 8:44 PM
  • I have exactly same issues with 1703 and my Java App-V applications, java is not loading in IE however they work without a problem in 1607.

    Not much of a help but I can't find anything meaningful that Microsoft changed.

    Tuesday, May 30, 2017 12:43 PM
  • We are receiving similar problems. I work for a University IT Systems team where we are preparing to role out Windows 10 in readiness for the new Academic year. I am responsible for ensuring that all applications previously delivered via App-V 4 can now be provisioned through App-V 5. We have several applications that were converted from App-V 4 and tested successfully on Windows 10 1607 but fail on 1703. The error code received is: 0x0003E05-800F0002.

    Our initial investigations indicate that the problem is related to to Symbolic Junction Points within the packages.  

    Tuesday, June 6, 2017 11:55 AM
  • Did anyone open a case with MS yet?

    Roy Essers

    Sunday, June 18, 2017 9:54 PM
  • I've just tested about 10 converted packages, and can confirm the same issue. If they where sequenced to Q-drive, they will first throw 0x0003E05-800F0002, and running them the second time a 0x00002c35-80070005 error. Converted packages which where sequenced to VFS do not show this issue.
    I've also tested on an insider built 16199, which does not solve anything.

    Could anyone check of they've got the same symptoms? I'll send in a ticket later this week.


    Roy Essers

    Tuesday, August 1, 2017 4:06 PM
  • I've ended up re-sequencing these when they fail post-conversion. 
    Friday, August 4, 2017 4:59 PM
    Moderator
  • That's always a possibility. I still had a couple of appv4 packages, and converted them om a win10 1703 built... still same outcome. I've noticed that not all converted packages facing this issue. 
    I opened a support case with MS, and will update this post as soon as I know more.

    Roy Essers

    Friday, August 4, 2017 7:34 PM
  • I have the same problem.
    Appv 5 packages are running on Win 10 1607.
    My appv 5 packages are not working in Win 10 1703 version.

    My error code is 0x00002C35-80070005

    Packages were made on the Appv 5 Sequencer
    Wednesday, August 9, 2017 1:06 PM
  • I had very similar issue but on 15'something (right before 1607). Packages were previously sequenced on win7 and app-v 5.0. I don't know why but running those applications from shortcuts using compatibility mode (win8) did solved that issue. It was only a test release. Later on 1607 with built in app-v client we did not experienced those errors.
    • Edited by Alex_Bodin Wednesday, August 9, 2017 1:33 PM
    Wednesday, August 9, 2017 1:33 PM
  • I had this similar problem this week, i think 1703 breaks the local cache of the application, the way we fixed it at a client side was to use the APPV 5.0 client GUI and use the Offline Mode to Update and download the Virtual packages, it runs a bunch of Powershell cmdlets and this helped me fix the issue..Worth a try for your case
    Thursday, August 10, 2017 1:59 AM
  • I have a similar problem and am getting the following error when launching some App-V applications after updating to 1703:

    The application failed to launch.
    This may be due to a network failure.
    Error code: 0x00003E05-800F0002

    A reboot does not fix the problem and the strange thing is that after attempting to launch a number of App-V applications and then rebooting, the App-V service is no longer able to start due to the dependency "AppvVemgr" not starting with the error "the system cannot find the file specified".

    Rolling back to v1607 fixes the problem.

    Thursday, August 10, 2017 12:37 PM
  • Only office applications are not working
    Thursday, August 10, 2017 1:30 PM
  • We have the issue only when adding a script during startup, as soon as we added something like 

    <UserScripts>
       <StartVirtualEnvironment RunInVirtualEnvironment="true">
        <Path>wscript.exe</Path>
        <Arguments>[{AppVPackageRoot}]\..\Scripts\hello.vbs</Arguments>
        <Wait RollbackOnError="true"/>
       </StartVirtualEnvironment>
      </UserScripts>
     </UserConfiguration>

    the application fails during startup.

    Removing the script fixes the issue, but it's no solution for us....

    Basically we are unable to add any dynamic script in build 1703.

    Thursday, August 10, 2017 2:29 PM
  • Not sure if all posts with failing packages are related to the same issue.
    My case @MS is still open and they are investigating 1 of my failing packages. I did some more testing, and only a handful of packages are failing. Majority (98%0 works without issues. Those which are failing where previously sequenced on win7sp1 with 4.6SP1 sequencer. They where all converted on server2008R2 in 1 single batch. The strange thing is, that some converted packages still work without issue. I've checked the install location. Some where sequenced to VFS, others to Q-drive, so no real similarity here.
    I've resequened a failing package with a 1607 sequencer, and this one is working fine now, but I'm not happy about the fact that I possibly need to resequence those failing ones (still got the vendor sources though).
    @Palermo765, did you get the  0x0003E05-800F0002 error also, before getting the 0x00002C35-80070005 error code? You did not convert those from 4.6?
    @Alex_Bodin, what's the error code you're getting? Are you able to open the VE of those packages?
    @Justin Varghese, so you just mounted all packages into local cache (that's what the appv5 client gui does). I've also tested this already, and did not solve the issue. Did you also get the same error codes? Where your packages also converted from appv4?
    @Leigh Smith, if you enable the appv debug log, does this tell you why the system cannot find the file?
    @roy_da_king, I've got lots of appv apps with script, those which I tested are working fine on 1703. You did enable EnablePackageScripts I suppose? What error code are you getting?

    Roy Essers



    • Edited by Roy Essers Thursday, August 10, 2017 8:54 PM
    Thursday, August 10, 2017 8:52 PM
  • Thanks for the reploy, EnablePackageScripts points to "1", also checked the registry "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Scripting", dword of "EnablePackageScripts" is set to 1.

    The error code is 0x0DF01725-00000534 - "The application failed to launch.", this may be due to a network failure.

    Works on older machine, I could provide you with an example

    https://productive.cluebiz.ch/fragments2/AspWebForms/Shared/Interface/transferdownload.aspx?transfer_id=f88ea377-eaf5-412a-8457-90951837e3bc&filename=a59b8c0e-335d-4fc9-ad5c-a4f3bdf0a374_DeploymentConfig.zip

    Thanks for your help!

    Saturday, August 12, 2017 12:37 PM
  • Are you sure your workstation is domain joined? Your testpackage (incl userscript) does work on my Win10 1703 domain joined workstation.
    Since 5.0SP2 userscripts are "broken" on non domain joined workstations.... I've never read any official MS statements about this issue. 
    If I run your errorcode through err.exe I get the following outpu:

    The result could suggest that this is the case.


    Roy Essers

    • Proposed as answer by roy_da_king Monday, August 14, 2017 2:42 PM
    Monday, August 14, 2017 9:55 AM
  • Thank you very much, that was basically it. I was testing the package with the local Administrator on a machine that is joined to the Domain. As you stated, the userscripts are really broken when running them with the local machine account. Again, thanks a lot, this solves our issues.

    Still, I have no idea what MS was thinking... Seems to be a bug, but as you stated, it has nothing todo with build 1703.

    Monday, August 14, 2017 2:42 PM
  • Great it solved you issue....
    No update yet on my case, MS is still investigating the testpackages I uploaded.

    Roy Essers

    Wednesday, August 16, 2017 8:47 AM
  • Hello there
    I did the sequence at 5, not 4.6

    MS sent me the link below

    https://blogs.technet.microsoft.com/ausoemteam/2017/04/06/download-windows-adk-for-windows-10-version-1703/

    It was informed that the sequenced office packages on win7 that should be sequenced in 17.03 operating system will not work.

    I will try

    Thursday, August 17, 2017 9:26 AM
  • which version of office are you talking about?

    Roy Essers

    Friday, August 18, 2017 9:09 AM
  • Hi,
    I seem to have found a solution to this issue. Open the appv5 package in the sequencer and look at the virtual registry keys.
    If any of these keys exist, highlight them and delete them, save the package and re-import into the appv5 server, the app should now load correctly.

    registry\user\ANY SID
    registry\user\appvcurrentuser\system
    registry\user\appvcurrentuser\Network
    registry\user\appvcurrentuser\Software\Microsoft
    registry\user\appvcurrentuser\software\Classes

    registry\Machine\system

    registry\Machine\software\Microsoft\windows
    registry\Machine\software\microsoft\windowsnt



    Monday, August 21, 2017 10:53 AM
  • @british_gov, where your broken apps also converted from 4 to 5, or did you sequence them om 5.0/5.1?

    So basically you remove registered classes, which could break the functionally of the application. I resequenced a couple of those who where broken, and they work fine so far. 


    Roy Essers

    Monday, August 21, 2017 7:09 PM
  • Hi Roy,

    These were converted apps.
    We did extensive testing with a lot of apps here, it seems to be some parts of the sequencer application are included in the registry, if you look at the keys referenced in a converted package you will see that none of them are related to the application. The registered classes exist in the machine registry and not inside the user registry.

    Obviously not necessarily an official fix, but this solution worked for multiple applications, including quite large and complex ones, without causing any issues.

    Tuesday, August 22, 2017 8:25 AM
  • Thats great to hear, resequencing complex packages would not be that great.
    The first broken package I just verified contains a FTA, and an app-path... so I'm unable to remove those keys without breaking the package..... anyhow, MS is still investigating my case, and will respond later this week. So for the time beeing, I'm waiting on their response. 

    Roy Essers

    Tuesday, August 22, 2017 9:40 AM
  • You did remember to enable scripting in the App-V client configuration, right?

    Tim Mangan MVP for App-V and Citrix CTP Author of AppV books: "PowerShell with App-V 5 (5.1 Edition)", "The Client Book (4.x)" and "OSD Reference Book" (http://www.tmurgent.com/Books )

    Thursday, August 24, 2017 7:36 PM
    Moderator
  • OK I got an update on the Microsoft ticket about this issue, I can report the following:
    Microsoft confirms that there was a change to the way Virtual Packages Registry will be handled. This could be the cause of this issues in Windows 10 1703. Microsoft is investigating and verifying this. Once the root cause is found they can talk about a solution and or fix.

    Roy Essers

    Friday, September 1, 2017 8:27 AM
  • Thanks for this.  Went to the Microsoft official blog to find more. It's not updated since 06.12.2016.

    Monday, September 4, 2017 11:56 AM
  • Yay - Fixed every single package that exhibited this behavior.  Thanks for digging into the problem and posting this solution.
    Tuesday, October 3, 2017 7:03 PM
  • Pardon but what did you do to solve this?
    Wednesday, October 4, 2017 6:14 AM
  • He resequenced all failing packages with the latest sequencer, which indeed would solve the issue.
    In my opinion though, they should not break in the first place. 
    Anyhow, my ticket is still open.

    Roy Essers

    Monday, October 9, 2017 8:11 PM
  • I understand. We got a workaround by deleting the package GUID in HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\Packages and HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\Integration\Packages. Then the packages launch correctly BUT the error can appear again. If the latest sequencer (Next Win10 Build?) fix this permanently its good but as you say it should not break in the first place.
    Friday, October 13, 2017 9:29 AM
  • I had this problem and I've made a script based on british_gov's solution. Before I ran my script that deletes the registery keys mentioned by british_gov, only about 10% of the converted packages worked in Windows 10 1709. When my script had done it's magic, about 80-85% of the packages worked without further editing!

    You find it here: https://gallery.technet.microsoft.com/Converted-App-V-5-packages-11d78a5e

    Tuesday, November 28, 2017 6:41 AM
  • I wanted to share the following (temporary) workaround:

    MS is planning a hotfix for feb2018, which should solve the issues we're facing with the containerized registry implementation they introduced with 1703. As long as this hotfix is not available, you can create and set the following regkey to disable CReg:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Compatibility]
    "RegistryCompatibilityMode"=dword:00000001

    Reboot your machine (or restart the app-v service), and the issue should be resolved. I had 3 separate issues, all related to the creg change, which were resolved this way. The upcoming hotfix will make the above regkey obsolete.

     


    Roy Essers

    • Proposed as answer by Roy Essers Friday, December 15, 2017 1:07 PM
    Friday, December 15, 2017 1:07 PM
  • I wanted to share the following (temporary) workaround:

    MS is planning a hotfix for feb2018, which should solve the issues we're facing with the containerized registry implementation they introduced with 1703. As long as this hotfix is not available, you can create and set the following regkey to disable CReg:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Compatibility]
    "RegistryCompatibilityMode"=dword:00000001

    Reboot your machine (or restart the app-v service), and the issue should be resolved. I had 3 separate issues, all related to the creg change, which were resolved this way. The upcoming hotfix will make the above regkey obsolete.

     


    Roy Essers

    Works like a charm for me ;-)

    With Kind regards

    Monday, December 18, 2017 7:36 AM
  • I wanted to share the following (temporary) workaround:

    MS is planning a hotfix for feb2018, which should solve the issues we're facing with the containerized registry implementation they introduced with 1703. As long as this hotfix is not available, you can create and set the following regkey to disable CReg:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Compatibility]
    "RegistryCompatibilityMode"=dword:00000001

    Reboot your machine (or restart the app-v service), and the issue should be resolved. I had 3 separate issues, all related to the creg change, which were resolved this way. The upcoming hotfix will make the above regkey obsolete.

     


    Roy Essers


    Worked for us, too!
    Monday, December 18, 2017 8:54 AM
  • Muito Obrigado, estava ficando louco com esse problema :)

    att, Aparecido Deveza

    Tuesday, January 16, 2018 1:46 AM
  • This corrected an issue of a client package not being able to read a certain registry key.

    Is there a KB article we can watch?

    Tuesday, February 6, 2018 8:27 PM
  • Microsoft has released an update today for 1709.

    https://support.microsoft.com/en-us/help/4074588/windows-10-update-kb4074588


    (Please click on Vote as Helpful and/or Mark as Answer, if it has helped you.)

    MVP - Windows and Devices for IT

    app2pack.blogspot.com: app2pack.blogspot.com

    Wednesday, February 14, 2018 4:22 AM
  • for me it is not working, i getting the same error then before the update but also after i installed the kb407458
    These Registry Key was not there, no Compatibility Key was there.

    Windows 1709, 16299.248

    The application was unable to start correctly (0xc0000142).

    The virtual application 'C:\WINDOWS\Explorer.EXE' could not be started because the App-V Subsystem 'Virtual Filesystem' could not be initialized. {error: 0x74300E0A-0x20006}

    These apps was running with 1607 but after the inplace to 1709 there are not running anymore.

    Wednesday, February 14, 2018 4:48 PM
  • Microsoft has released an update today for 1709.

    https://support.microsoft.com/en-us/help/4074588/windows-10-update-kb4074588


    (Please click on Vote as Helpful and/or Mark as Answer, if it has helped you.)

    MVP - Windows and Devices for IT

    app2pack.blogspot.com: app2pack.blogspot.com

    Great, but that update is for 1709 and not 1703, the fix is not listed in the Feb update for 1703.
    Thursday, February 15, 2018 12:31 PM
  • Microsoft has released an update today for 1709.

    https://support.microsoft.com/en-us/help/4074588/windows-10-update-kb4074588


    (Please click on Vote as Helpful and/or Mark as Answer, if it has helped you.)

    MVP - Windows and Devices for IT

    app2pack.blogspot.com: app2pack.blogspot.com

    Looks like they are simply disabling the new registry feature that is causing the problem.  While it is not a fix, it is perhaps an acknowledgement from MS that the problem affects the majority of users.
    Thursday, February 15, 2018 4:12 PM
  • For 1703 CU KB4077528 is released last week which disables cReg by default, and fixes some other app-v issues. For the cReg implementation to work the need to first apply some changes to the core of windows10.... will likely not happen any soon I suppose.

    Roy Essers

    Saturday, March 3, 2018 7:43 PM