Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Layer not activating on startup

Created: 25 Oct 2013 • Updated: 22 Jan 2014 | 17 comments
This issue has been solved. See solution.

I have one layer that has Activate On System Startup checked, yet it does not activate.

How can I correct this?

 

 

Operating Systems:

Comments 17 CommentsJump to latest comment

ksreek's picture

Are you able to activate this layer manually without any errors ? What version of operating system and Workspace Virtualization you are using ? What does the layer contain ? (Any specifics)

 

 

SOLUTION
ayockcelg's picture

Yes, I can activate it without errors.

I am using Workspace Virtualization 6.1 SP7 on Windows 7.

EdT's picture

Does this virtualised application have any dependencies on other applications which may not have completed loading when the layer is started?

As kskreek has already stated, if you are able to start the layer manually without errors once the machine has booted, then it would strongly suggest that the problem is one that is based on the timing of other startup events.

You will need to supply much more detailed information in order for us to have any chance of pointing you in the right direction.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

ayockcelg's picture

I'm using Workspace Virtualization 6.1 SP7 on Windows 7.

 

The application is Google Chrome 65.72.71.  It is the only layer.  As far as I know it does not have any dependencies.

ksreek's picture

Are you saying "The application is Google Chrome 65.72.71.  It is the only layer" , It is the only layer having this problem or all layer exhibit this ?. Have you tried rolling out a 'empty layer' and check its "Activate-on-Start-up" capability ? This kind of helps isolating if its a SWV component or the package that conflicts.

Also i remember 'Edward' was helping me with info that you are trying to push 'activate-on-start-up' flags through 'AltirisSMP' ??. In that case, Could you trigger 'Activate-on-start-up' flag on the local SWV admin tool for a empty layer/Google chrome layer, restart the machine and report the status of activation ?

Other details :

  • How often you see this behaviour ? Random, Always, based on a specific pattern?
  • Have you tried with a SWV newer agent ?

 

ayockcelg's picture

It is the only layer period.  We have created a filter in the Symantec Management Console that imports and activates the layer every time the user logs in, as a work-around. 

The Activate On Startup flag is triggered, yet the problem remains.

We have tried this with SWV 6.1 and 7.5 and experience the same issue.

 

balachandar_manimala's picture

Looks like you have used the "Install application into a virtual layer" feature in Symantec Management Console.

Try creating a layer on clean machine using SWV manually.

After layer capture, deactivate, set the "Activate on Startup" flag, export the layer.

Import the layer to a target machine, reboot and check if that works. If yes, then it could be an issue with SMP not being able to implement this feature.

ayockcelg's picture

I think I've found the issue.  I've installed SWV manually and created an empty layer on two machines; one using Credant Mobile Guardian Shield for Windows, one without.

The one with Credant does not activate on startup, and the one without does.  I've checked but cannot find any Credant policies that look like they could cause this.

Are there any known issues with Credant?

EdT's picture

The SWV filter driver runs at a very low level, as do most if not all antivirus solutions, as both need to intercept disk calls before any other processes. Chances are that the load order may have a bearing on this but I have no idea whether this can be modified. There may also be issues with the session that the drivers are running in - see http://msdn.microsoft.com/en-us/library/windows/hardware/gg463353.aspx

Might be worth checking whether Credant have any updates or are aware of this potential issue.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

ksreek's picture

Right...Adding color to what @ EdT said  it is very much possible that the altitude of these drivers are involved in this issue. Altering the altitude for these driver might help in mitigating . You can quickly take a look @ those order using http://technet.microsoft.com/en-us/sysinternals/bb897416.aspx (Sysinternals Utility) But there are certain altitudes warranted by each driver and anything beyond that is not suitable for the applciation's funcionality.

All this being said, way back in the past we have seen a BSOD issue involving 'Credant' and Symantec 'Streaming' due to driver load order conflict  , if i am not wrong a fix was delivered from Credant to resolve it. Check if you have updated drivers from Credant. If still issue persists ,symantec can get involved in determining the underlying problem.

EdT's picture

@kskreek - thanks for the link to the sysinternals utility. Should be very interesting to test various live builds.

Are you able to disclose the altitude, or range of altitudes, that the SWV filter driver is able to work at ?

 

Cheers

EdT

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

ksreek's picture

EdT, unfortunately i have some limited knowledge about drivers. This is something our driver architects knows better..I will have to check with them on those specs and if it is something that can be disclosed by symantec i will certainly reach out to you with those details :-) Thanks

EdT's picture

Thanks. I hope this information can be put into the public domain as it may offer assistance with any other low level driver conflicts that users experience. :-)

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

ksreek's picture

Interesting..Looks like this info might be already available to us ;-)

Check out - http://msdn.microsoft.com/en-us/library/windows/hardware/ff549689(v=vs.85).aspx
and search for our registered drivers : appstream.sys & reghook.sys, fslx.sys

Alternatively try using the minifilter driver management utility 'fltmc' . It actually reveals the altitude in which the mini filter drivers are loaded in a machine. Hopefully this helps..

 

ayockcelg's picture

After working a bit with Credant, I'm starting to believe that it is encrypting a file that's required for the Activate On Startup to work.  If I could isolate the file being used I could add it to our policy exclusion list.

Is there a complete list of files created by SWV anywhere?

ayockcelg's picture

After working a bit with Credant, I'm starting to believe that it is encrypting a file that's required for the Activate On Startup to work.  If I could isolate the file being used I could add it to our policy exclusion list.

Is there a complete list of files created by SWV anywhere?

 

ksreek's picture

SWV operates files based out of the following directories . If you plan for an exclusion make sure the following are completely excluded

<Installation Directory>\Workspace Virtualization\*.* {Including Sub-directories} --> Operating Files
C:\Windows\System32\drivers\fslx.sys  -->Driver File
C:\fslrdr {Including Sub-Directories}  -->Application Repository

The Activate-on-Startup is controlled by the following value in Registry.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FSLX\Parameters\{RO Layer Number}\ActiveOnStart = 1  (1-Enabled , 0-Disabled)

Good Luck !