Vista SP2 RC Security Updates crash NOd32

So far so good with the RTM-Escrow build of SP2 vista 64

 

I take that back, errors are back. The typical "Maximum Protection is not ensured" error, and asking to reinstall. Back to v3 til NOD32 can fix this problem.

 

Does anyone know if this has been fixed, and is safe again to install SP2 RC?

 

What do we have to do to get someone from NOD 32 to first A)admit the issue and B) give an ETA on when it will be fixed? This issue has been going on for a few months now, and not one rep has replied to this thread. What a shame.

 

in my experience, no one actually from Eset reads this forum, besides Marcos, and I am not sure if he is Eset employed? he tries, but there is ALOT of threads here....

this forum really is mostly for other users to try to figure things out together, in other words, it is not used properly by Eset, (it would be a valuable resource if they chose to monitor it and and if they actually responded here, they would earn permanent loyalty in users).

bah...

 

Hello,

I just did some testing with the release candidate for the service pack and was not able to reproduce this. Could you send me an ESET SysInspector log from your computer via PM to look through?

Regards,

Aryeh Goretsky

 

Hey bodean...

Chill out man... you are complaining about ESET not working correctly with BETA/RELEASE CANDIDATE VISTA/CRAP.

I'm sure they appreciate your feedback, but your attitude is misplaced...

Expecting them to just drop everything and fix an issue with a BETA SERVICE PACK for VISTA/CRAP is not only a watse of resources, its just plain silly.

Sheesh...

 

First, Vista is not crap and is already used in 25percent of computers(look wikipedia os market share), second this SP2 most of us have is NOT beta. It's not even RC. It's RTM Escrow, means almost RTM.
I also get this problem. Randomly, it seems. The last few times I booted my computer everything worked fine, so I cannot try one thing myself.
And that one thing is trying to disable v4 Self-protection and see if the problem persists.
I suggested this in several topics, but no one seemed to answer. An answer would provide valuable information both for people looking for a fix/at least temporary one and maybe ESET too. Everybody just keeps creating topics with problems..

 

You might want to check your facts. The RTM release of SP2 is now available. It is NOT a beta any more. See the front page of Neowin.net.

 

I'm sure ESET is aware of this, and is trying to make a solid solution. Takes time to work bugs out, and figure out why it happened, and implement a solution that is not half-cocked and will end up breaking more.. That is the main reason I report findings is to get a better product.

 

And that is what in the end, will give you a better product. Kudos my man.

 

+2 points for bradtech

 

I can get a better answer out of our useless politicians these days.


After 4 updates and new builds, the main issue has not been fixed yet, and SP2 is about to hit main MS Update website in very short time.

If you think you have a problem now, wait till half your customers start calling and flooding your mail boxes all at once. That will wake your asses up.

 

It's part of doing business. I am just happy Marcos, and whoever helped him fix my Novell Netware Client crashing issues after providing a Kernel Dump for them to look at. I got a build that was not officially releases a day after he looked at it, and it totally saved my ass, and will help come renewal time. Of course I have criticisms, and recommendations on what I want to see.

 

Hello,

Private Message sent.

Regards,

Aryeh Goretsky

 

I actually have a bigger issue than just the 0x101a error...

- Installing the program at first goes through with no errors
- Upon first update the program will report error 0x101a
- After a manul restart, the error still persists and NOD32 cannot update itself
- The ESET directory is not writeable by any process or user, including Administrator and SYSTEM
- The ESET registry key entries are not writeable by any user, including Administrator and SYSTEM
- Taking ownership of these resources did not resolve the permissions issue
- Upon uninstall:
- MSI will report unable to delete files even if you have ownership and full access to the ESET folder
- manually deleting registry keys after taking ownership will result in "error while deleting key"

The only way to remove all traces of NOD32 is to boot with WinPE, load the local registry hive and remove the offending entries, then proceed to delete files manually.

All this is on a clean install of Windows Vista SP2 6002.18005RTM

 

Unfortunately I have to confim the problem that Kanna reports, in addition I'm getting reproducibly a BSOD upon login. The error occurs in emon.sys. Booting into safe mode I can disable the ESET service and login again normally. However, disinstallation (automatic or manual) of NOD32 is not possible because of insufficient privileges exactly as described by Kanna.

The issue occured first after installing SP2 RTM on a system that ran w/o problems for several months. Now I'm getting the BSOD using Nod32 4.0.424 BE on a clean install of Windows 2008 server x64 SP2 6002.18005 RTM.

 

Same here. During stage 3/3 of the SP install, e.g. the login screen, eamon.sys causes a BSOD. Fantastic.

Oh well, I wanted an excuse to wipe and install Win 7 RC, and guess I just found that excuse...

 

Right, I am getting the same issue here. It will be ok for a few days, then I get the problem with it not starting. I also got a bsod on reboot when I installed SP2 RTM FINAL, but a forced reboot and it installed ok the second time.

The only way to fix it when the issue occurs is to uninstall it and remove all registry keys which is a bloody pain the arse. ESET please give us an indication you are working on this issue. My subscription is up soon, I even convinced my Dad to get a triple licence.

It is very frustrating and seems to be a permission issue, as it causes errors when I uninstall as well.

 

SP2 for Vista has been RTM for a while now.

More importantly....going back to last year, it's been known SP2 for Vista was going to be coming out soon. All those RCs. And Microsoft gives software developers access to it, so that they have time (for those software developers that think ahead and use this time) to get their product compatible with it. This is logical, the better software companies utilize this time to prepare their product so that it's ready and fully compatible with the service pack once it's publically released. Instead of scrambling around after the fact when a bunch of their users call support with crashes.

 

Okay in all fairness here is a good experience. I have Nod AV 4.0.424 running. I installed the RTM of the Vista SP2. Granted it took a long time to install (between 45 and 60 mins....and it might have to do with the fact that i did not disable Nod or it might not have taken as long....will never find out now). After reboot, all is well and no errors whatsoever with Nod or with Vista.

The only weird thing happening to my computer is that it is showing that I have Bitdefender installed as AV (which i had 2 months ago and only for 2 hours). Pretty weird but Nod is running well so am not too bothered about it.

 

I think if you already have nod32 installed before doing the update then you're fine. I just tested it on vista sp1, installed nod32, then installed sp2 afterwards. Going that route worked for me.

 

I find it odd that NOD32 v4 breaks with Vista sp2, yet runs fine in Windows 7 RC (7100)

 

This worked for me 1 day. on the second day i always get the messages posted on the first post in this thread. i have to disable UAC then NOD32 works again.


Nod Antivirus 4.0.417 german on vista ultimate x64

 

Vista32 SP2 RTM (official, not Escrow) gives issues with nod32 4.0.424.0.

After the SP installation it seems to work but on next reboot you have: red eset icon on taskbar, unknown error 0x004 sent by eset and real time protection disabled.

If I scan the C: drive to fix possible errors, on next reboot eset is working properly until following reboots.

It seems something related to permissions with cached drivers that are reset after a disk scan.

I hope to see a solution soon.