dll file is missing on installing the app-v 5.0 sequenced application

All replies

• 

  

  0

  Sign in to vote

  Hello,

  It would probably be recommended, if following Microsoft best practice, to select a different PVAD. As an example;

  c:\program files (x86)\yourappfolder

  ---

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

  Friday, July 26, 2013 7:16 AM
• 

  

  0

  Sign in to vote

  ... and install the app into that Folder during sequencing. Or, as a try, use C:\vApps\yourappfolder and try to install the application into that.

  ---

  Falko

  Twitter @kirk_tn   |  Blog kirxblog   |  Web kirx.org

  • Proposed as answer by znack Sunday, July 28, 2013 7:08 AM
  • Marked as answer by Brandon RecordsModerator Thursday, November 21, 2013 7:53 PM

  Friday, July 26, 2013 3:56 PM

  Moderator
• 

  

  3

  Sign in to vote

  Copy the "missing" DLLs into the directory where your application executable resides.  I've found that with certain applications, when the app places DLLs into SystemX86 it is unable to search for it.  To fix this I have simply been copying the newly created DLLs from SystemX86 to the same directory where the exe resides for the application.

  I've only had to do this with a few applications.  Actuate eReport Designer Pro is one.

  • Proposed as answer by gotsauss Wednesday, April 12, 2017 6:37 AM
  • Marked as answer by CodyLambertModerator Wednesday, April 12, 2017 4:10 PM

  Saturday, May 24, 2014 12:06 AM

  Moderator
• 

  

  0

  Sign in to vote

  Hello Cody. I created a sequenced Actuate 7 eSpreadsheet Designer 10.0.2 with Appv-5 Sp2. I published the package using the Powershell commands, but When I tested the app in this test machine the app never openned. The process eSpreadSheet.exe cosumed the 99% of the CPU and never open the app. I performed a Devirtualization in another machine and it looks work properly, So I think it's a virtualization problem. Do you have any idea how to fix this?

  Note: I created another sequence including all the DLLS detected in SystemX86 in the same directory where the exe file resides for this application C:\Program Files\Actuate7 as you suggested in the last entry but I'm still having the same problem.

  Thursday, August 28, 2014 3:30 PM
• 

  

  0

  Sign in to vote

  The first time I did it, I noticed that what the sequencer said it detected wasn't accurate.  I had to do a comparison of what dlls existed before and after on the sequencer machine to figure out which ones it missed.  I think it was the Visual C ones (older than the Visual C++).

  Friday, September 12, 2014 9:34 PM

  Moderator
• 

  

  1

  Sign in to vote

  Copy the "missing" DLLs into the directory where your application executable resides.  I've found that with certain applications, when the app places DLLs into SystemX86 it is unable to search for it.  To fix this I have simply been copying the newly created DLLs from SystemX86 to the same directory where the exe resides for the application.

  I've only had to do this with a few applications.  Actuate eReport Designer Pro is one.

  Thank you so much. This was the key to getting it to work. I tried copying all the DLL files from the SYBASE folder on the capture machine to SystemX86 and tested. Same DLL error. The fix as you said, was to copy the DLLS (I did the entire SYBASE contents) into the same folder as the EXE resides for the application. Some apps are fine with just the DLLs in the SystemX86 folder. Depends on the App. Cheers!!!

  Wednesday, April 12, 2017 6:40 AM
• 

  

  0

  Sign in to vote

  Thanks for the tip... i've been having this issue with an application I have been trying to sequence. Worked fine when launching on the Sequencer, but once installed the App-V package it failed. ProcMon was showing it was searching for the dll despite having located it once in the SystemX86 directory. 

  As you suggested, I copied the dll's into the directory the application sits in and now works. Thanks again.

  
  

  • Edited by robImartin Wednesday, May 30, 2018 4:10 AM

  Wednesday, May 30, 2018 4:10 AM
• 

  

  0

  Sign in to vote

  Open the FileSYstemMetadata.xml, if the missing DLL is listed in the section of <StaticDependencies> then this is a known issue. all the DLLs in this section need to be injected via mavinject.exe which is not working above 1703, your package should be running fine in 1607 or Win8/Win7 with AppV 5.1

  
  

  Wednesday, May 30, 2018 6:20 PM
• 

  

  0

  Sign in to vote

  Pardon my ignorance, but should this show all dlls, or only certain types of dlls? I checked a few packages, and 1 for example has about 30 global assembly dlls ([{Windows}]\assembly\GAC) but nothing at all listed for static dependencies in the XML.

  I checked a DB2 package and have 6 staticdependencies\executable nodes, each listing 2 dlls.  DB2 is loaded with DLLs, way more then the 2 listed.

  What if an exe inside the .appv requires a dll that only resides on the local machine? 

  If the dll is missing from the XML, is there a recommended approach to fixing it (should we just do what Cody did above)?

  When software can't locate a dll not in the machines PATH variable in some cases I've had luck changing the virtualized PATH variable from the virtualized location (C:\Program Files\Software\) to the non virtualized location ([{AppVPackageRoot}]\VFS\ProgramFilesX86\Software).  Does this make any sense based on what you've said regarding mavinject?

  Thanks

  Wednesday, May 30, 2018 7:02 PM
• 

  

  0

  Sign in to vote

  there are 2 type of DLL-Loading process for AppV, one is before the VE(virtual environment) the other is after. and the ways how virtual process load these 2 type of DLLs are also different.

  - if it is a static dependencies DLL, the DLL would be loaded before the process image code was executed, AppV uses the Mavinject.exe /inject xxx.dll inject these DLLs to the process, because the VE is not started yet. AppV don't know where to find these DLLs, from Procmon, you can see these DLLs are using full path instead of relative path.

  - if this is a regular DLL, it will be searched / loaded during the process run time and VFS mapping is already done, and the process knows where to located the DLL either from mapped package VFS or system %PATH%.

  to answer your question, all PACKAGE specific DLLs should be listed in the XML manifest file, non-package DLL could be loaded by the virtual process as well, such as common CRT Dlls or other system DLLs..

  Wednesday, May 30, 2018 8:26 PM
• 

  

  0

  Sign in to vote

  and to debug these type of DLL missing issues you can use the following tips:

   - if the virtual process complains some particular DLLs are missing, try to enter the virtual bubble by using the CMD /appvve:guid_guid switch and to see if the DLL is really there. this would ensure the VFS mapping is created correctly during the sequencing time.

  - if the DLL can be found in the virtual bubble, it should be a DLL injecting problem, you could use procmon to determine where the DLL suppose to load, copy the DLL from the virtual path to the physical path should solve the problem.

  Wednesday, May 30, 2018 8:33 PM
• 

  

  0

  Sign in to vote

  Very much appreciate your answer!  Its slowly (but surely) sinking into my non-programmers brain. Do you think this could be why certain applications fail to start when directly called, but will run when you first open a cmd window and then run the exe?
  I've had a handful of apps that crash when launching the exe directly, but if I change the shortcut to a cmd.exe which then opens the process it works.  I'll have to remember what package that was and recheck the dll dependencies.

  Thursday, May 31, 2018 3:54 PM