Signature update problem on SBS2003 server

My SBS2003 server has today started having problems with it's signature update. The error means nothing to me, hopefully there is someone here that can explain.

The error message is.

Undocumented serious error (0x101a)

 

PM sent.

 

I'm also receiving this error message on one of the workstations on our network. Is there a way to fix this?

 

Workstations can be easily fixed with a reboot. If you absolutely cannot reboot a computer, then there's an eset reset tool you can download/run on the computer that may fix the problem as well.

 

I've cleared up a few instances of this by going in to the advanced setup menu and using the Clear Update Cache before forcing it to check again, but more often then not a reboot does the job.

I've seen that triggered by the C: volume being completely full, so check for that just in case.

 

I work at a small IT company and we have installed NOD32 at several clients' offices. I have been having this problem on many workstations. I first noticed it a few months ago and followed the instructions at this KB article, but it has become more and more frequent. Clients call me up saying they have an undocumented serious error and I have to tell them to clear the update cache and reboot. I have yet to see it on a server like the OP did, but even some people do not want to reboot. I wonder if they are working on a permanent fix for this and why is it still called "undocumented serious error" when so many people have a problem with it. I hope they did not just leave the fix at the KB article and tell people that is the only solution like I have seen on several other posts about this same topic.

 

If you're seeing that error on a standard workstation, it's worth doing some followup hardware diagnostics. Bad ram, bad processor, or a failing hard drive can all generate that error when updating on desktop class hardware which you typically don't see on proper servers with redundant storage and ECC/Registered ram.

 

If it is a hardware issue, why would clearing the update cache and rebooting fix the error? If that were the case, then the problem would appear again eventually on that workstation. Now I can't be certain on this, but any workstation where I have cleared the cache and rebooted, the error has not yet shown up again. It has been a few months since I first saw it come up here at the office, which was where we installed ESET for the first time. I'm not saying that it couldn't be a hardware issue, but I would assume if it was, the error would have shown up again on one of the workstations I applied the fix to 5-6 months ago. I would just like to know if ESET is working on a permanent fix for this so I would not have to go to those individual workstations and clear the problem. I know it is a simple fix, but that requires me to go out on a service call for a problem that takes 10 minutes to solve.

 

It also happens when you install Windows Updates, but have not rebooted yet.

 

Differing amounts of thermal load can cause CPUs and capacitors to fail at some times but not others, bad sectors on a hard drive can be dynamically remapped without notifying the user resulting in subsequent update attempts to succeed after the cache is flushed, and different programs using memory, aggressive caching in today's operating systems, and ASLR might result in your application code not being loaded in the same failing address every time causing inconsistent behavior.

Consumer-grade hardware doesn't always have set working or failed states that are easy to diagnose at a glance. Hardware failures can often cause intermittent issues that only manifest themselves under certain situation and are written off by the user as normal system instability. I would estimate that in 3/4 of the times where I have seen a client reporting a failure to update or initialize the AV engine, sending a tech out to run a full hardware diagnosis results in a failing component being found.