Vista SP2 RTM - be careful!

Fantastic news Marcos, many thanks for the update. Fingers crossed!


Jim

 

Changed to test mode and it updated the program modules. Are these new versions?

Virus signature database: 4118 (20090601)
Update module: 1028 (20090302)
Antivirus and antispyware scanner module: 1218 (20090601)
Advanced heuristics module: 1092 (20090309)
Archive support module: 1095 (20090525)
Cleaner module: 1040 (20090401)
Anti-Stealth support module: 1012 (20090526)
Personal firewall module: 1046 (20090429)
Antispam module: 1011 (20090114)
SysInspector module: 1212 (20090414)
Self-defense support module : 1006 (20090513)

 

Anti-Stealth support module: 1012 (20090526)
Self-defense support module : 1006 (20090513)

are new and don't seem to be downloaded to those of us without test mode enabled.

 

yap, those two are new. Any improvements?

 

i realised that i need to keep updates on test mode until the regular update catches up because when i disabled it, it reverted the modules to previous version and that dreaded red screen showed up (anti stealth is on). So back to test update again, restart and all is working again

As for the improvements nothing that i can see unless the above indicates that it fixes the permission issue which i think that it does (on a hunch)

 

Thanks mate, I hope ESET will come with full changelog description.

 

I talked to a friend of mine at vistax64 who is a programmer/coder and this is what he says
About the issue, and why it may affect all systems differently, or not all all.
He suspects Eset was being naughty, and attempted to hook opaque non-API functions in the kernel that SP2 then changed.

Patchguard and signed third party kernel code
Microsoft has attempted to exert greater control over approved third party code by introducing
Kernel Mode Code Signing in Windows Vista that mandates digitally signed kernel code, and has
also introduced PatchGuard on 64-bit versions of Windows to limit the modification of kernel code
and data structures. This does not prevent hooking of certain kernel data structures though, most
importantly the objects stored in the object directory (such as device, driver, or port objects) which
still allows kernel functionality to be hooked and file system or network requests and responses to
be modified as desired.



Re: SP2 issue
Hello Rive,

I read through the thread and the Eset KB article, but I don't have any answers for you. I'll think out loud for a bit though...

The Eset KB article does not offer any explanation for what the problem may be - they merely discuss workarounds. However, given one of their suggestions is a rollback to version 3.0 of their product, it's obvious that version 4.0 tries to do something substantially different.

A bit of background:

The kernel offers specialised API "hooks" where AV software can attach itself legitimately. Those functions are meant to be immutable - should a Windows SP somehow change them, that would constitue an MS problem which affects a multitude of AV products from different vendors. That's not the case here though. Instead, what's likely happening is that Eset are getting a bit adventurous and hooking non-API functions to varying degrees in different versions of their products. Many AV vendors do that, usually because they feel constrained by having to use the same APIs as their competitors, so in order to gain an advantage that looks good in a brochure (additional forms of "protection" not offered by their competitors), they'll sometimes run the risk of hooking non-API functions.

The problem is that those functions may change in a hotfix or SP. It doesn't take much for that interface to break down; for example, a function that used to return a dword parameter now returns a quad-word, and that is enough to completely throw into disarray any hooking software which expects a dword. In this case, that's very probably what happened... Eset 4.0 was hooking non-APIs and that's a little naughty. SP2 comes along and sufficiently alters the functions being hooked to cause Eset 4.0 to break down. Eset techs scratch their heads. It takes a week or two for Eset HQ to find their top 2 or 3 development resources and to say "you're on this until it's fixed - TOP PRIORITY!", and even then they don't really know how to fix it until they've analyzed (under a debugger) all of the SP2 modifications to the non-API functions that they've been hooking, and just exactly why their previous assumptions are now broken. Remember that MS is not publishing detailed info about those non-API functions... they are meant to be "opaque".

It's entirely possible that there's more than one underlying cause for the breakdown. There may be several or even hundreds of functions being hooked which now need to be rejigged by Eset devs. That's probably what causes the different symptoms on different computers - some expose multiple problems, some a single one, and some non at all, depending on environmental conditions and the way those machines are used.

There is no way to "troubleshoot" this stuff properly without a debugger/disassembler, a fair amount of kernel-mode knowledge, and lots and lots of time and effort. Hence, it's best to just let the Eset folk do their thing. They'll presumably put out an updated version of their product once they're done re-coding.

Hope this helps

 

Help who? or what? At least it helped me to see that u are so obsessed in trying to solve the problem for the others, but you and i know why u are doing this, don't we? Just forget it and do what ur friend told u, let the Eset folk do their thing.

BTW, the problem seems to be solved with the new test updates, but sometimes there's a problem when installing Nod32, so Marcos, are u gonna release a new build soon?

 

@rive0108

What exactly is your point? This is only speculation and cannot see how your post would help anyone. Eset released a fix to those with test mode enabled and will release the fix for everyone within a few days. I believe a fix from the software delveloper is the kind of help the affected users need/want and Eset released that fix already. As CivilTaz already said a new installer/build is needed as well. Since your post is only speculation it might noe even be accurate so i'm not sure how that information is useful at all. This issue have to be fixed by Eset and information that could possibly be the reason for the problem won't solve anything.

 

I found the post interesting enough to catch my attention for a minute to read it. I'll be a pint of Guinness it'll mysteriously "disappear" though.

 

I believe rive0108 just wanted to give us in-depth "probable cause" what might be the core problem. I see no harm in his post.Maybe over-technical for most users, but not useless.

 

thank you for letting us know

 

i just enabled test mode and updated. hopefully it is fixed now

 

Agreed, he gave a good insight as to what might be causing all the issues.

 

How can this be enabled if using RA 3.x ? Can't found any option in the server.
Activation at the client should not be enough.

regards
mike

 

I have noticed one rather strange thing: as my laptop is password protected, during boot while in logon screen if I type my password immediately then no problems with NOD32. If I however wait at this point (HDD is doing some background activities) and login after about 2 min or something then I get "red icon". I cannot replicate this error with 100%.

Or maybe this is total bull$hit?

Cheers,
Miki

 

Does it happen with the latest update that is supposed to fix the SP2 issue as well?

 

no, regular 4.0.437 version. I don't use test mode.

 

Thanks.


[For those interested in debugging, or even gaining more insight into the individual issues at hand, here is a free MS debugger for BSOD dump files and kernel issues, and instructions on how to use it: http://www.vistax64.com/software/219790-reading-bsod-crash-files.html]

 

I'm pretty much sure I can replicate this "red icon" problem as I described few posts above. Does it mean it is related to those issues rive0108 posted? If Vista loads some drivers/processes before NOD32 conflict emerges?

 

Not that this is very scientific but, over the weekend I tried putting SP-2 onto a Vista 32 Bit business edition box which I had kicking about (it was about to be wiped so I didn't care about trashing it).

Installed SP-2 with EAV 4.0.437 running with Anti-stealth and Self-Defense both turned on....installation had no problems and I haven't had a single error, glitch, BSOD, red Eset icon or any other anomoly.

Not sure if it makes any odds but, the only thing I can think of which might explain why I haven't had any issues is that Vista has both DEP & UAC disabled and has done since Vista was first installed. Not using Test mode either before anyone asks!

~M

 

been couple of days now since i downloaded the updates with 0 problems, hopefully it is fixed now

 

Hello,

Please see https://www.wilderssecurity.com/showthread.php?t=244205 for updated information.

Regards,

Aryeh Goretsky

 

Do I still need to leave test mode checked if I want to avoid reverting back to the old broken modules?