Hello all;
This is a continuation of my previous post in that I have been able to isolate down the cause of why the package is failing to launch and all the other issues. (Thank you to all that looked at this and helped my understanding.)
To jump right into it. The application I have packaged is yet again SoftLabMic. There are 2 DLLs that are not being found by the package when it is launched. These DLLs are "controllib.dll" and "conlib.dll". "Conlib.dll" does not flag as an issue until "controllib.dll" is corrected by placing it in the below mentioned sandbox location.
My findings have been this...
1. The DLLs are present in the package and are in the same location as they would be with a full install (C:\Program Files\SoftComputer\SoftLabMic\4.0t\***.dll); confirmed with the cmd.exe entry point.
2. The package will not run on any Windows OS nor will it run on the capture machine containing the full install.
3. Log Monitor entries show the below as the only path being looked too for these DLLs at the launch of the package. Every entry in the Log Monitor always lists out this locaiton.
NtQueryAttributesFile* ObjAttrib=18a0c8h (RootDir=0h SD=0h SQoS=0h Attribs=40h OBJ_CASE_INSENSITIVE Name=18a188h (Len=128 Buffer=5fd038h [\??\I:\SoftLabTst2\bin\Thinstall\SoftLabTst2\SKEL\controllib.dll])) -> st=C0000034h ( failed) [Native: "\??\I:\SoftLabTst2\bin\Thinstall\SoftLabTst2\SKEL\controllib.dll", "\??\I:\SoftLabTst2\bin\Thinstall\SoftLabTst2\SKEL\controllib.dll"]
4. If I do a manual copy and paste of these files to the Sandbox location (bolded above) the package will launch without issue.
5. Based on the modification dates of the files copied to this location compaired before and after package launch no changes are made to these files. This would be why they are not copied to the Sandbox to begin with, correct?
6. I have confirmed that in the virtual registry entries made by the application at install and ones located under HKLM\FS are all correct.
I feel this issue is caused to some attribute that is being applied by default by the Capture Wizard (or at least that is my hope) or other switch\switches that I have not identified yet. I have tried the "fix" for SxS DLLs found in the ThinApp Community with no change to where the package searches for these files. I have gone through the different User\Development\Version manuals and was not able to find the correct entry in the Package.ini. I have gone as far as setting all of the Directory folder attributes to "Merged" in an effort to identify a possible isolation issue. Again this did not adjust the problem. Lastly, I have repackaged the application using C:\ as the install location in place of C:\Program Files.
Can someone please let me know if they have run into this type of issue, and what they feel could be a fix for the issue? I am tring to avoid adding a vbscript that would just copy these files to the sandbox when the package launches being that this does not seem to the best solution but more of a "bandaid" fix.
Thank you all for looking over this wall of text. Please let me know if I need to provide any more information.
ThinApp Version: 4.6.2
Capture Machine: Clean, Non-updated WinXP sp2 machine with no Antivirus\Firewall
Compression: None Used