Virtualization

There is overhead with virtualization no matter what but installing directly to Q:\<asset folder> rather than C:\ is the primary cause as well as not pre-caching the sequence. Another common cause I see is if you have a dll that is not registered in the registry so the application looks in several wrong places first before finding the DLL. You can speed that up by putting a copy of the dll in the first place the application searches. Another slowdown is that the application looks for COM information in the wrong area of the registry first USER\Classes then MACHINE\Classes. This one I usually don't fix because it is fairly involved to fix and it is rare to see an app pull up a bunch of DLLs and follow this registry access pattern. Also the more virtual registry activity and the more virtual file system activity that an application performs the more likely you will notice performance degredation.

kkaminsk stated: ... Another common cause I see is if you have a dll that is not registered in the registry so the application looks in several wrong places first before finding the DLL. ...
Is SoftGrid not sequencing optimally (spelling?)? Is this built this way by design or an oversight in programming? Just curious.

I don't think you can blame virtualization for this though I have virtualized the odd app that couldn't find it's own DLLs but I think that running as a seamless application in Citrix might have contributed to the problem because you never load a full shell when running as a published application. I got some info on this when I made this post.

http://www.brianmadden.com/Forum/Topic/73763

Rick Mack: One very common reason for published aplications failing to run is that quite a few applications have their components (DLLs and OCX etc) in several directories, kind of a dispersed application. I can't think of any specific examples at the moment, but generally in this scenario the application will be installed into c:\program files and there will be extra components in c:\program files\common files etc.

The way this is handled is that the installer creates a key for the executable under HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths, eg AppName.exe. Under that key is the default value which points to the executable, and a Path value that includes all the search paths for that application, eg c:\program files\MyApp; c:\program files\common files\MyApps.

When you're running a full desktop session, and start the application, the explorer shell checks the Path value and appends the additional paths to the system PATH.

When you're running a published application without windows explorer, the App Paths value doesn't get used.

You can check this fairly easily with the Dependency Walker from the windows server 2003 resource kit or with the NT file monitor (www.sysinternals.com).

If a dispersed application is the problem, you've got a several possible solutions.

The easiest one is to go to the additional directories defined in the Path value and simply copy their contents into the main executable directory. Or you could append the additional directories to the system PATH (don't do this though 'cause it gets messy).

The last way is to download the application compatibility toolkit from Microsoft, and use the application compatibility administrator to apply the SearchPathInAppPaths fix to the appllication. This intercepts call to the SearchPAth API and modifies the command to also search the application's App Path directories.


Here is some more info from MS as to how DLLs are located.

Search Path Used by Windows to Locate a DLL
http://msdn2.microsoft.com/en-us/library/7d83bc18(VS.80).aspx

With both implicit and explicit linking, Windows first searches for "known DLLs", such as Kernel32.dll and User32.dll. Windows then searches for the DLLs in the following sequence:

The directory where the executable module for the current process is located.
The current directory.
The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
The directories listed in the PATH environment variable.


For XP SP1 and Windows 2003

http://msdn2.microsoft.com/en-us/library/ms972822.aspx

DLL Search Order Has Changed
No longer is the current directory searched first when loading DLLs! This change was also made in Windows XP SP1. The default behavior now is to look in all the system locations first, then the current directory, and finally any user-defined paths. This will have an impact on your code if you install a DLL in the application's directory because Windows Server 2003 no longer loads the 'local' DLL if a DLL of the same name is in the system directory. A common example is if an application won't run with a specific version of a DLL, an older version is installed that does work in the application directory. This scenario will fail in Windows Server 2003.

The reason this change was made was to mitigate some kinds of trojaning attacks. An attacker may be able to sneak a bad DLL into your application directory or a directory that has files associated with your application. The DLL search order change removes this attack vector.

The SetDllDirectory function, also available in Windows XP SP1, modifies the search path used to locate DLLs for the application and affects all subsequent calls to the LoadLibrary and LoadLibraryEx functions by the application.

Well I do expect a delay due to the overhead. But, it takes a simple app like Acrobat Reader five seconds to launch after I virtualize it. Not sure our uses will like that.

It takes a machine here that's just been imaged with no extra junk on it and running reader locally about 7 seconds to open a 600k pdf from a network drive. If they're going to complain about 5 seconds on a virtual app, then you have other issues to contend with than virtulization slowness. :)

I've noticed launch delays too. Especially those are noticeable during first launch for the day on a given computer, no particular correlation to the size or complexity of the package. For example, a package containing a single exe inside may take 20-25 seconds to produce GUI the first time, and only 1 second during subsequent launches the same day, whereas some of the packages containing 1000+ files open right away. Packages relying on Java or .Net Framework seem to be affected the most, but I suspect there may be some web update check routine adding to the problem.

Speaking of slowness, has anyone noticed issues with 4.1.1 Sequencer, "Sequencing blocks" phase? I am seeing dismal performance degradation when application size exceeds 1.5-2 Gb... I am talking 25-30 hours of 100% CPU usage by SFTSequencer.exe process doing "Sequencing blocks", right after the application launch monitoring finishes. I do not recall observing the same behavior in the 4.1 version of the Sequencer. And no, we are not using substandard hardware for sequencing, no extra processes/services/applications, plenty of unused HDD space and RAM.

Actually, a user complaining about an application launch time going fron instantaneous to 5 seconds is quite a resonable complaint, partcularly with a rather busy user communitly. And in your example, it would even double the launch time of opening that document. Softgrid has great potential. But that kind of performance degradation isn't going to fly here. I am not seeing this delay with other virtualization products. Although, the others do not appear to be as good as Softgrid. I'm just looking for suggestions in case others have experienced the problem.