Windows 2000 computer crippled by 3435 update

Add us too, mulitple systems crapping out due to it.

So far only Windows 2000, Windows 2000 Serve rna dXP machiens are being affected, but not ALL of the XP machines, just some.

I'm mildly suspecting a conflict with the GDI+ update MS just release (KB938464) but uninstalling that KB doesn't fix it.

BS for sure.

 

Same here on XP Pro SP3, totally locked up Windows, have update 3435.
This is ridiculous I have wasted so much time.

 

Update 3435 seems to have been taken back . Currently 3435 is not available for download .

Earlier today I was at clients and didn't notice any problems on computers running XP and Vista - can't confirm if they all had 3435.

 

I'm doing remote support for a customer running 3.0.657, about 45 workstations, almost all XP SP2. 3435 stopped all non-MS applications on their systems, especially AutoCAD, which is their whole business. By the time I was able to respond, Brian had found that stopping the NOD32 services got them functional again.

Pushing 3.0.67whatever freshly downloaded from ESET through the console is fixing the issue, though the users we've tested so far are complaining of slower performance compared to earlier today.

This customer got hit hard by the last bad batch of updates as well, and Brian is giving me a hard time about the "so-called great antivirus" we sold them with the latest batch of servers. I know that perfect is too much to expect, but this cost them at least $3k worth of productivity this afternoon plus the cleanup costs. I really, really don't want to go back to Symantec or (shudder) CA, but neither of their products has ever completely shut down one of my networks like this incident.

Pulling my hair out on this one, guys.

-kms

 

Updated from 3.0.657 to 3.0.672 as many have reported working. However virus definitions now report the signature database to be 3373. When an update is attempted it reports "The installed virus signature database is current."

huh? It is dated 2008-08-21... Not sure why this wont update to the latest definitions on any of our systems that have been upgraded. Out of date, but at least no longer crashing, not sure which is worse, because neither are better.

 

They pulled definition 3435 from the update servers and it incorrectly reports as being up to date instead of giving an error.

 

Actually , as 3435 has been pulled out , 3434 is the very latest , so it correctly reports you are up-to-date

 

Currently have 600 computers at 21 branches, without admin rights, at version 6.0.650 with 3435, mix of XP and 2000. No reported problems yet.....

 

So, has everyone else tried rebooting to solve the issue? if so, any success after reboot?

 

Although I have been unaffected by this (apparently because all my machines are at 3.0.669.0 or higher), I must say that this is unbelievable! IMO, I don't see how they can give any excuses. Eset must know that since they do not have mandatory version updates (and I'm not saying they should), they should always test new definition updates on older versions.

If they don't get some method in place to deal with this type of situation, how will situations like this not cost them business? Instead of growing their business through trust, they seem to be burying it. Imagine what the cost of today's boo boo is for all their affected customers.

I'm not planning to change from Eset in the near future. But things like this make me want to look around for alternatives...

 

Yet another reason to be so happy I have 99% of my clients at 2.7.

 

No problems here with 3.0672.0 and defs #3435 on XP Home SP3 boxes (or Vista Home Premium SP1 either).

 

We have been hitting the systems from remote via Windows computer Management and disabling the EKRN service, then getting someone near it to reboot, that at least fixes it in so much as it prevents Eset from running.

I'm also now pushing .672 (via Active Dir) just in case.

 

We are resellers of ESET and do not plan on recommending ESET in the future. Additionally we will probably be changing to something else at the end of our licenses. This is ridiculous. The fact that they did not re-issue an older definition as a new definition (like 3434 as 3436) is beyond me. We know the issue is in the newest definition, so why not revert to an old one?

"In no event shall ESET, spol. s r. o. and/or its respective suppliers be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortuous action, arising out of or in connection with the use or performance of information available from the services."

Sadly their license agreement shows that they are not liable for crippling your client's network.

We have had numerous problems that ESET turned out to be the culprit
1) We have had numerous server crashes due to an incompatibility between ESET's real-time scanner and DFSR. (loss of productivity and money)
2) There was an Adobe file that was mis-flagged back in May causing a great deal of trouble. (loss of productivity and money)
3) ESET's bad 3435 update (loss of productivity and money)

We are now operating with real-time scanning turned off while emails with virii are probably pouring in with absolutely no protection. The gross negligence of ESET is costing us all a great deal of grief, productivity, and money. Yet, still, 4 hours after the initial problem, ESET has not addressed this forum. We were forced to call to verify it was an ESET problem. How many techs are still troubleshooting this problem and have yet to discover the problem was in their antivirus and not a virus itself?

 

It was starting to show up here too. XP SP2 computers. The manual disable of AV checking allowed the computer to run. Update 3.0.672 pushed with the console and PC is working again. BUT - it shows 3373 for the database back from 8/21. But it is working.....

THANK YOU ALL FOR BEING OUT HERE - I WOULD NOT HAVE FOUND THE PROBLEM OTHERWISE. Read all your stuff while on hold with ESET. Never did talk to a support person.

 

v3.0.657.0 virus database 3435 same crash problem first I thought was a virus
I opened a discussion I can't imagine my problem was so common!
https://www.wilderssecurity.com/showthread.php?t=220204

 

Basically, I have an entire manufacturing plant down. WE JUST GOT THROUGH A HURRICANE and didn't have this many problems. My server is inaccessible. I can no longer login to it. It is a Win2kserver. Rebooting seemed to fix a few XP Pro systems while others seemed to just get randomly different problems. I have been an eset fan for quite a while but this is ridiculous. Where is a fix?

 

My XP clients who login to the domain seem severely effected even though they are local administrators. Once the problem begins logging out and logging in as the Administrator user I see the problem persist. However if I reboot them and login as the local Administrator user the problem doesn't come up.

 

Temporary fix disable real time protection lol

 

Somehow this is permission related. How a "virus update" could have caused such havok is beyond me. Ultimately you seem to need to not only be a local system admin, but a domain admin as well. Vista seems unaffected from what we could tell. First time Vista has been better than XP since its launch. Oh and my Mac is also unaffected, lol.

 

Four hours and a missed lunch later, our small office (40-45 clients) was back up and running, but tons of residual issues from the mess in getting 3.0.672.0 to install remotely.

I'm not sure where ESET is with this as I didn't even bother to contact them yet, but I can assure you that I crippled the mirror server's ability to download new definitions overnight -- I don't like not having the latest protection but it's a better option than either no protection or a crippled network on Friday morning.

Also, all of our 3.x systems were affected by this and very few of the logged-on users were running as local administrators (or domain administrators).

All that I know for certain is someone has some explaining to do, and there hasn't been a lot of it thus far... ESET is only able to shield themselves from direct liability. There isn't much they can do when a contract renewal or potential referral comes along and the business slips out of their hands -- they might want to take that into consideration before this happens a fourth or fifth time.

ESET's reputation is quickly becoming inadequate for covering up their glaring problems.

 

Defs Update 3436 has been released.
Hopefully this will fix the problems.

I'll post also in the Update Alerts forum-section here at Wilders.

 

yesss seem fixed!

 

I wonder if they'll share what caused this with us and how they hope to avoid such situations in the future.

 

Weird, It DID affect my home computer which is Vista Ultimate 32-bit (NOD 3.0.657).

But only slightly, it's actually 'affecting' it now, but Vista got one 0xc0000022 error, and IE complained I didn't have access the first time I launched.

But it worked this time, and I also just managed to go disable real-time protection without incident. That tells me that Vista DOES do a better job of preventing rouge programming errors from killing the system.

I made the mistake of telling AD to 'uninstall' 657 before installing 672, made a bit of a mess, so I reverted them all to the 657 install again, which rolled back the updates. Next reboot (tomorrow) they'll install 672 again, only an over-top install instead, which works fro the three test machines I used.

Whatever, it's under control now, I'm not ready to jump ship or anything like these other nay-sayers. I got a personal message here from Marcos like two hours after it was a problem, with a patch, without even calling them -- and I'm sure I'm not the only one he PM'd.