locked
Process appears to break out of VE RRS feed

  • Question

  • Hi,

    I have created an App-V package for an application, and almost all of it works well except for reporting. When a report is selected, a separate exe is launched (this is part of the same App-V package).

    The application is virtualized to C:\Program Files\<appvendor>\<appname>\, and the report exe is in a subdirectory of the application directory. When the report exe runs, it fails because it cannot find a DLL. Using Process Monitor, I can see that it searches C:\Program Files\<appvendor>\<appname> for the DLL, but the error is that the DLL cannot be found.

    If I launch cmd.exe in the VE I can see that from inside the VE the DLL is in the correct location.

    So it gives the appearance that the application has somehow broken out of the VE and cannot find the files it needs.

    The App-V packages were sequenced on Server 2016 using the latest version of the sequence (from ADK), and are deployed to a Server 2016 machine which has all the latest updates applied.

    Does anyone have any suggestions, either for resolution, or for how I can investigate further?

    Thanks

    James

    Sunday, November 26, 2017 9:04 AM

All replies

  • Since the DLL was not in the folder with Report.exe (but in the folder above it), the Report.exe needs to be able to find it using the system search paths. This should be:

    •   First look in the working directory of the executable. (which is probably the subdirectory)
    •   Then look in the directories in the APPPATH settings for the executable.
    •   Then look in the PATH environment variable directories.

    As you seem to know, if the process is in a VE, App-V will also check the App-V cache locations also. (I am fairly confident that the process was running in the VE).

    While App-V does process a path variable change in the package, I have seen instances when it didn't seem to work. In that case, the solution was to add to your package the AppPath entry for the problem executable. So in your package you create a key like:

      HKLM\SOFTWARE\Windows\CurrentVersion\App Paths\Report.exe

    with a default value of the key set to any PATH variable change made in your package, but definitely including the location of the not found dll.


    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 )



    Monday, November 27, 2017 5:09 PM
    Moderator
  • Hi Tim,

    Thanks for your response. In Process Monitor, I already see the correct location of the DLL searched, but the reply from Windows is that the DLL is still not found, even though when I run a cmd.exe inside the VE I can see that the file is there.

    Because the correct locations are already searched, I don't think it's a PATH issue. It is exactly like the exe cannot see the virtualised locations.

    I will try your proposed solution anyway though, hopefully sometime today.

    Thanks again

    James

    Monday, November 27, 2017 7:38 PM
  • That is the behavior of the bug.  It looks in the right place and you know it's there.  You may need to remove the PATH variable changes with what I mentioned.

    Originally found with packaging ArcGIS, I've seen this crop up with a couple of other apps.


    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 )

    Monday, November 27, 2017 10:56 PM
    Moderator
  • So what's not working is when application.exe calls report.exe. It seems that App Paths is only actioned by Explorer.exe - when i run cmd.exe inside the VE and then try and run report.exe, the App Paths registry key is not examined.

    So what worked for me was create App Paths\Application.EXE registry key, which is maybe what you meant in the first place?

    Thanks so much for providing this solution - it has been on my to-do list for ages and within 24 hours of posting here I have a fix!

    James

    Tuesday, November 28, 2017 12:31 PM