Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 10 replies
  • Subscribers 2 subscribers
  • Views 19820 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Reboot issue: SAVservice is causing 15-60 minute delay until CTRL+ALT+DEL becomes available

Darth_Boss

Sometime within the last 72-96 hours we began receiving calls from our network users that their PC's were displaying a "Please wait..." on the monitor.  After a few questions, we discovered that each user had either powered-on or restarted their computer.  It did not matter if the OS was WinXP Pro, Vista Bus., or Win7 the user's experience was the same.  Both 32-bit and 64-bit OS's were responding in the same fashion.

We have witnessed the "startup delay" to last between 15-60 minutes before the CTRL-ALT-DEL prompt will appear.  During this extended-delay period, the computer will not echo a ping.  There is hard drive activity during this 15-60 minute period (although the hard drive light is not steady, only blinking about once every second).

Disabling the "-NoStartupCheck" in the Sophos AutoUpdate registry key did not resolve the issue.

The PC's affected will boot into SAFE MODE normally.

We have been working with SOPHOS support since 2/5/2013.  On 2/5/2013, support determined that the issue involved the SAVservice.  They had us disable the SAVservice and the PC's rebooted normally.  As soon as we reabled the SAVservice the PC's delayed the appearance of the CTRL-ALT-DEL for 15-60 minutes.  We have transmitted them the logs that they have requested, for their review.

To say the least...our users are a little "put out" at this point (as are we).

If anyone has any ideas...we would certainly welcome them at this point.  Thank you.

:37457


This thread was automatically locked due to age.
  • 0

    Thank you for your forum post do you have the case reference? I have seen a similar issue in the past with scripts that run on logon causing a delay, due you have any scripts that run at logon, installs, drive maps etc?

    One test I would suggest would be to remove all GPO's from the machine and reboot, if the issue does not occur start adding them back in one by one to identify which one is causing the issue, we can then take more details and run tests our end to confirm.

    Hope the above is helpful to your issue and the case.

    Scott

    :37461
  • 0

    HI,

    The SAVService performs many functions linked to the different features.  The best thing to do, would be to try and isolate exactly the cause.

    For example, if you disable on-access scanning in the policy does it help?  Does it have to be disabling the service as that disables alof of the functionality?

    Does disabling behaviour monitoring help?

    Maybe set-onaccess to on-read only.

    Does it help to exclude C:\ as a test?

    How about disabling web protection features?

    Not sure if Device or Data control is enabled but does disabling those help?

    If you could narrow it down a bit that would help the focus.

    Regards,

    Jak

    :37465
  • 0

    Hello,
    We aren't using any GP scripts. Also, we are experiencing the same issue on workgroup laptops. Case # is 3675919. Thanks.

    :37467
  • 0

    Hello,
    Support had me do all these same steps yesterday. They had me collect all kinds of logs and uploads to their flp server. I'm still waiting for them to get back to me with an answer...

    :37469
  • 0

    Did any of the options help?

    For example:  If you edit the policy (e.g disable on-access) for a test client, wait for it to comply and then, reboot it, does it take as long?  Did you narrow it down to anything more specific than having to disable the service?

    Regards,

    Jak

    :37471
  • 0

    Support had us disable the on-access scanning in the policy. We rebooted and it took just as long as before the disable to get to the CTRL+ALT+DEL. Support was not able to narrow it down to anything less than disabling the SAVservice (even when they had us exclude C:\). We are waiting for support to decipher the logs we FTP'ed them. No word so far.

    :37473
  • 0

    Update:  2/8/2013

    We are still waiting for support to decipher the logs and get back to us.  We have contacted them multiple times to obtain some sort of estimate as to when their analysis will be complete.  We have received no confirmation as to when we will hear back from the person our case was escalated to.

    The status of this post is tagged as "Solved."  The issue is not solved.  Shutting off the SAVservice is not a solution.  It is an abandonment of using the SOPHOS endpoint software altogether.  We need a resolution to this issue.

    We are suspecting that the data protection policies might have something to do with this.  We are testing our theory.  If anyone has experienced something similiar to our issue then we'd great appreciate your input.  Thank you.

    :37501
  • 0

    A bad data control rule could do this.  Disabling data control would be worth a try, then add each of the rules back in.  Hopefully you can isolate the problem to a particular rule.

    Regards,

    Jak

    :37505
  • 0

    Thank you for your post, I have looked at the case, my colleague Dino Kravariotis emailed on the 8th asking for a time/date to perform a remote session, I have forwarded the email back on to you, could you please reply to this so he can arrange it with you.


    Regards

    Scott

    :37519
  • 0
    To make the community easier to navigate, we've moved this content.
    :53251