With VIPRE installed laptop comes out of hibernation and starts up by itself

I would thing that auto updates and scans would be a default scenario. If that somehow causes a powered off computer to come back on, I think that would be a serious problem. ( Delete or Edit)

Hibernation. Which writes memory to disk and powers off laptop, so not like it has any power going to the laptop. By design, I could even remove battery and it would remain in hibernation state. ( Delete or Edit)

That's fine, but does it not register to anyone that by not advising your customers of this problem, and this workaround in a proactive way, you are putting them at unnecessary risk? This behavior is so stealthy that the average customer, who probably won't read this forum in detail, let alone this specific thread, and will not have a clue what happened to his precious laptop when he discovers that the battery has been completely drained, or overheated and was perhaps damaged in transit. I will most likely not be nominating Sunbelt for any good citizenship awards in the near future. ( Delete or Edit)

3.1.2315 does not resolve the problem! I purchased Vipre today, put my laptop in hibernation (so it would be ready to go back to work when I turned it back on, rather than having to start up my 8-12 normally active programs) and came back to it about 5 hours later. I found that when I opened it up, it appeared to be coming back from standby mode - I did not have to press the power button to start it back up. When I logged in, I had an icon in the system tray indicating that Vipre had logged an error. When I checked the error log, I had three failed attempts to update definition files due to Internet connection problems.

I purposefully put my laptop in hibernation instead of sleep mode because I carry it around in a closed laptop case with paper next to it and I don't want it overheating (or draining the battery for that matter).

Besides the overheating and battery draining issues, there is a security issue as well. I have connections set up to a number of different wireless networks with automatic connections and passwords set up. These are generally secure networks, but if I'm in another location and someone happens to use an identical name on an unsecured network, I believe my machine might automatically connect and then transmit the update request across the unsecured network. If I'm personally turning on the machine, at least I can watch for the connections, but this doesn't work if a program is turning on the machine automatically.

I can actually see where the auto on feature can be helpful in the case where someone wants to turn their PC off at night, but have it come on to do a scan. However, turning on to check for updates is pretty useless. The proper behavior would be to have a check for updates performed when the computer is turned on if a scheduled check has been missed. While the machine is in hibernation, nothing is going to get into it, so there isn't a real need for updates. If the update is performed as part of the startup when a scheduled update has been missed, then any new threats can be recognized immediately once there is a possibility of risk. Since checking for updates doesn't take long, this shouldn't be a big problem time- and resource-wise. As far as the scans go, there should be an option on the scheduled scan setup to allow one of four choices in the event the computer is off or in hibernation at the time scheduled:
1. Skip the scan
2. Wake up the computer if possible and perform the scan
3. Perform the scan when the computer is next turned on
4. Notify me that a scan has been missed and give me the option of performing it then (this can also be a follow-up to option 2 if the computer is not successfully awakened)
These could also be options for the automatic updates, although I think they are much less useful in that case. In all cases where the computer is awakened, it should be returned to its previous state after the scan (or other activity) is performed.

Now that I've described what I think is proper behavior, I should acknowledge that at least some of these are probably issues with how the operating system and the computer implement scheduled events. I'm sure Sunbelt is using something in the operating system (in coordination with the computer hardware/firmware) to schedule these activities. That means that telling the computer to only perform the scheduled activity if the computer is on, but not if it is hibernating (or in standby or off) may be difficult. Also, determining what the power status was before the scheduled event was called and returning to that status automatically at the completion of the event may both be things that are not supported. I do think that if Sunbelt cannot find a fix for this problem, they at least need to put warnings on the scheduled scans, automatic updates, and corresponding installation pages to tell laptop users about these problems.

For Sunbelt's reference, I am using an HP Pavilion dv6000 laptop, dual bootable with XP SP3 and Vista SP1. I have installed Vipre in both environments, under the assumption that whichever one is booted will load it up. The processor is an AMD Turion 64 x 2 Mobile Technology TL-60. I don't know the BIOS information off-hand. ( Delete or Edit)

Oweno2, 2315 is not the update for the hibernation issue. That update is still slated to come out this month.

The rootkit option is not available for 64-bit systems. Current rootkits that have been written for 32 bit systems, including the infamous Sony music CD rootkit, don’t work in the 64 bit OS. That’s because when updating the kernel code for the 64 bit version, Microsoft programmers took the opportunity to include a “patch guard” – code that is part of the kernel makes it impossible to install a patch in a running kernel (which kernel mode rootkits do on 32 bit systems).

Likewise, processor vendors had an opportunity, in making the new 64 bit processors, to include security mechanisms. Both AMD and Intel include code in their 64 bit products to prevent the exploitation of buffer overflow and buffer underrun conditions.

In other words, rootkit security is already built in to 64-bit systems so they guard against it instinctively. So in your case you will not need this option in CounterSpy v3 or Vipre. ( Delete or Edit)

I sincerely hope it IS coming, and soon!
The lack of pro-active warning to your present customers is inexcusable.
I'm sure you've cost countless users money for unnecessary battery replacements.
Maybe there have been damaged PC's or even fires caused by overheating when the PC turned itself on while in an enclosed space, in which case Sunbelt is liable for damages. Have you even consulted your lawyers on the enormous potential for liability you have exposed yourselves to here?
I smell class action law suit.

- Neil ( Delete or Edit)

Any idea when the Enterprise version will be released? I have 500 seats that I can't deploy because of this bug. ( Delete or Edit)

Got the Enterprise link emailed to me this morning. Thanks! ( Delete or Edit)

Edward,

If you have the 'Wake from sleep on scheduled scans' option enabled, it will wake your computer from any form of unconscious state to run a scheduled scan. For desktop computers, VIPRE will wake the computer for updates, then return it to it's previous state no matter what this option is set at. For laptops, it will disable the scheduled scans as well as the updates if you have the second option enabled. I'll see what we can do about phrasing this better, or explaining it differently.

Regards,
Jason Layman ( Delete or Edit)

Alan,

This is something I have suggested a few times. I'll see what we can do about changing some of these settings around. We just need enough people backing up this idea. ;)

~ Jason ( Delete or Edit)