rlcronin

You might check the settings under Control Panel->Internet Options->Connections->LAN Settings and un-check "Automatically detect settings" if its checked (and you don't actually need Windows to try to figure out your proxy settings automatically). I've seen that cause delays like what you mention. -- bc

Forgive the n00b question please. I am new to Smart Security. I installed it today only to discover that I am now unable to connect to a vnc server on my local network through an ssh tunnel that I've got between my PC and the host running the vnc server. I presume I need some special rules to enable that. Can anyone help me figure out how to set that up? -- bc

I've had a similar experience with the last two Windows 10 fast-ring insider builds, although in my case it wasn't all connectivity that was lost, just https connections didn't work until I uninstalled and reinstalled. Maybe related. Maybe not. I don't expect eset to do anything about it in my case since I knowingly opted for the fast ring, so anything that breaks is my responsibility to deal with myself. -- bc

I hadn't tried to manually move the popup. I will try that, although I wish there were a way in Settings to tell nod32 to restore it. Maybe you might consider having it do that when someone clicks "Reset window layout". -- bc

The desktop notifications that popup whenever the signatures are updated used to appear in the lower right corner of the screen. Lately however they're showing up elsewhere. How do I restore the default behavior? -- bc

What am I missing here? The ESET webpage is offering the multi device security product for 6 devices for 1 year for $42.49. It seemingly includes the full NOD32 product (as well as the Firewall and mobile product). Yet if I ask for the price for a 1 year license for NOD32 for 6 devices, I am told it is $149.94. If I get the multi-device product, am I really getting the same NOD32 that I'd have to pay $149.94 for the same number of devices? How does that make any sense? -- bc

Is there any way I can download the .0 spin of 9.0.349 so I can backlevel myself to see if the problem goes away? -- bc

All of a sudden I can't get to https://www.nest.comand login to my account there anymore. nod32 (version 9.0.349.14) blocks it claiming there's some kind of problem with its certificate, but doesn't elaborate other than saying it was "blocked by PUA blacklist". Anyone else seeing this? What do I have to do to get this fixed? Thanks for any help. -- bc

I too find the new GUI jarring, but perhaps its because I don't understand the motivation for the changes. I'm curious why the changes were made. Was there some compelling reason for it, or was it just change for the sake of change? Can you provide any insight into the thought process that led to the new design? -- bc

If the past is any indication of the future, I'd expect a v9 beta in August or so and a general release in late October or early November (although that seems to have been tied more to new Windows releases that anything else, so if the rumors are true about a Fall general availability of Windows 10, perhaps it will be earlier this year). -- bc

Maybe you have a similar issue like the one discussed some time ago in another thread: Delay Update Attempt? There are also useful instructions how to test this, so maybe you should follow the instructions for the "ping test" from @Aryeh Goretsky to find out whether your assumption is true. ... an issue that was never resolved for what its worth. Sigh. -- bc

Alright, that makes sense, but what good does it do to try so quickly only to have it fail because the network card is not fully ready only to have it then not try again for the default 60 minute regular automatic update interval. A lot more could happen in those 60 minutes than would happen in the 6-8 seconds longer you'd be waiting for the network to be ready. -- bc

I can now substantiate SweX's comments with hard data. I have a System event log entry dated 08/22/2014 at 3:59:31 PM recording the PC being woken up. Then in the nod32 log file I have an entry at 3:59:33 from the Update module saying "Server not found". So nod32 is not waiting very long to make the attempt. -- bc

I tried the ping thing but didn't get any useful info. Then I thought of looking in the event log. This is the very first entry in the system event log at the time of wakeup: 09:45:42 The system time has changed to ‎2014‎-‎08‎-‎20T13:45:42.500000000Z from ‎2014‎-‎08‎-‎20T10:04:56.750426100Z. Then in the application event log I saw these two events: 09:45:48 Fault bucket -861546332, type 5 Event Name: WPNConnectionFailure Response: Not available followed by 09:45:51 Customer Experience Improvement Program data was successfully sent to Microsoft. From this I conclude that it took almost 10 seconds from wakeup time for the network to be able to successfully connect to the Internet. How's that? -- bc

I'm not sure how I'd figure that out, but I'll work on it. Thanks. -- bc

Thanks. Iam aware I can have it retry in relatively short order, I was indeed wondering if there were a way to delay the attempt through the ui (or even better, specify that the task should not run if the network connection is not available as one can do with the Windows task scheduler). -- bc

My normal mode of operation is to put my PC's to sleep rather than shutting them down. This is because I have them wake up at various times to perform unattended maintenance tasks. On one of my PC's, nearly every time it wakes up, if nod32 attempts to update the virus signature database "too soon" after the wakeup, it fails because the server can't be found. I am guessing this is because the network interface on that machine is a bit slow in restoring connectivity after resume. On another PC that operates in exactly the same manner, this never happens. The problematic PC has a Marvell network interface. The well behaved one has an Intel network interface. All the drivers are up to date. Anyway, I am wondering if there might be some way to have nod32 wait until the network connection is available before attempting to run the update. Perhaps something similar to the way you can specify that tasks scheduled via the Windows task scheduler should not try to run unless a network connection is available. Or maybe a setting to have the update retried after a failure after a user-specified interval (perhaps defaulting to a minute). Thoughts on this? -- bc

After several days of living with it, it seems the USB selective suspend setting does help, but doesn't completely solve the problem. It still happens on occasion. So an ESET solution of some sort would be appreciated.

Researching this further, I've discovered (and tested) a workaround for this issue. I'm posting it here in case anyone else has the issue and would like to get around it. I'd still like some kind of fix for this in nod32, although since the cause of this is a less-than-ideal Windows design decision regarding how to deal with DisplayPort devices when they get turned off, I'd understand if ESET shrugged it off as a Microsoft issue. Here's the advice I found. It did work for me. However since it turns off USB selective suspend altogether, it can have possibly undesirable side-effects depending on the stable of USB devices you have and whether or not disabling the ability to selectively suspend them would cause an impact for you (e.g. as it might on a laptop running off battery). Why exactly a setting for *USB* selective suspend has an effect on how Windows deals with a non-USB DisplayPort monitor I'll leave to you to scratch your head about what Microsoft was thinking when it did this! Oh and despite the fact that the advice talks about Windows 7, it works for Windows 8.1 as well. Go to Control Panel, Power Options, Edit the plan you use by clicking Change Plan Settings, once here click Change Advanced Power Settings. Once there, go to USB Settings, open the menu by clicking the + open the next menu named USB Selective Suspend Setting and disable it. Once this is disabled Windows 7 will no longer adjust your display setup when a display is turned off.

I didn't intend to imply it was that serious. In the grand scheme of things, I'd classify it as a minor annoyance (and doubleclicking the .reg file I created to apply the fix isn't that much of a burden). But life would be ever so slightly more fun if I didn't have to deal with this, so if sometime there's a rainy day with nothing better to do, maybe someone at Eset could have a wee look at it. Thanks. -- bc

I used to connect my monitor to my PC with a standard (dual-link) DVI cable. I recently switched to a DisplayPort cable. Ever since, when my PC turns itself on overnight to run various scheduled tasks (at which time the monitor is OFF), if a nod32 update comes through during the time it is up, the next morning when I wake the PC up for my work day and another nod32 update comes through, the alert that usually pops up in the lower right corner of the display instead pops up in the middle of the screen (at about the point that the lower right corner WOULD be if the monitor resolution were standard VGA). I presume the display being off at the time the overnight update comes in makes nod32 think the screen is standard VGA and so it adjusts the alert position accordingly. To restore the alert to where I want it I have to edit the registry and set the DesktopAlertPosition1 and DisplayAlertPosition2 to hex ffffffff. I suppose I could avoid it altogether if I were willing to leave the monitor on all the time, but that would waste electricity and I am loathe to do that. This is annoying! It'd be nice if this could be fixed so that it didn't happen in the first place, but if not, it'd be nice if the ResetWindowLayout command could be enhanced to reset the alert position, perhaps optionally (so those who have deliberately put theirs in a non-standard place and like it that way don't get annoyed). -- bc

I found that adding the router's address under Web and Email->Protocol filtering->Excluded IP addresses->Add IPV4 address->Single Address->192.168.1.1 completely fixed the issue for me. I have sent numerous traces to Eset and received promises they'd follow up, but to date there has been none. I suspect there are simply bigger fish to fry, especially as there is such a simple workaround. I still hold out hope that Eset will get around to looking at this on that rainy day when there's nothing better to do. This is definitely a new behavior in V7. I discovered this problem back when I first installed the V7 beta. Reverting to V6 made it go away. I reported it back then and hoped it would be fixed before V7 was shipped. Alas, it was not to be. -- bc

Ditto (except that I am on Merlin's latest, 3.0.0.4.374.35_2). I am happy to help debug this (at least today, I won't have time the rest of the week). -- bc

I do have problems with mt RT-N66U using Merlin. I use Chrome. What browser do you use? -- bc

I found the same, but the question is, WHY? What is the router doing, exactly, that is causing ESET to behave this way? I submitted some wireshark traces of this in response to a request from Marcos during the beta period and never heard anything back. -- bc