McAfee DAT 5958 Update Issues

Published: 2010-04-21
Last Updated: 2010-04-21 21:08:19 UTC
by Guy Bruneau (Version: 3)
19 comment(s)

McAfee's "DAT" file version 5958 is causing widespread problems with Windows XP SP3. The affected systems will enter a reboot loop and loose all network access. We have individual reports of other versions of Windows being affected as well. However, only particular configurations of these versions appear affected. The bad DAT file may infect individual workstations as well as workstations connected to a domain. The use of "ePolicyOrchestrator", which is used to update virus definitions across a network, appears to have lead to a faster spread of the bad DAT file. The ePolicyOrchestrator is used to update "DAT" files throughout enterprises. It can not be used to undo this bad signature because affected system will lose network connectivity.

The problem is a false positive which identifies a regular Windows binary, "svchost.exe", as "W32/Wecorl.a", a virus. If you are affected, you will see a message like:

The file C:WINDOWS\system32\svchost.exe contains the W32/Wecorl.a Virus. 
Undetermined clean error, OAS denied access and continued. 
Detected using Scan engine version 5400.1158 DAT version 5958.0000.

McAfee released an updated DAT file, and an "EXTRA.DAT" file to fix the problem. An EXTRA.DAT file is a patch to just fix the bad signature. McAfee's support web sites currently respond slowly and are down at times, likely due to the increased load caused by this issue.

Several readers reported that this procedure worked to recover:

1 - Boot the system in "Safe Mode"
2 - copy extra.dat in c:/program files/common files/mcafee/engine
3 - reboot.

If you lost "svchost.exe", then you need to copy it back to c:/Windows/system32/svchost.exe while in safe mode. This fix has to be applied locally at the workstation. However, it may be possible to do this remotely if your workstations support Intel's "vPro" technology. We should have a link to instructions shortly.

Our reader Jim wrote in about how he managed to get some systems back remotely, as long as svchost.exe was not deleted or moved. In this case, the computer will be in a reboot loop. Here is what Jim wrote:

I created a batch file to run the following command:

echo f | xcopy.exe {server}netlogonextra.dat 
   "c:program files\common files\mcafeeengine\extra.dat" /R /Y

I put this batch file and the extra.dat in the netlogon folder.

I then set the computer configuration>windows settings>scripts>startup to run this command in a GPO that gets applied to all computers.  Then link the GPO to the domain root, or wherever is appropriate.

Upon reboot the computers process this command and so far we seem to be good to go, "mostly".  There have been a few cases where the files end up missing.


ISC reader Linnie wrote in and indicated this method works as well:

- Copy the EXTRA.dat file to c:program files\common files\mcafeeengine
- copy the svchost.exe to c:windows\system32
- Reboot, everything is back to normal.


Additional information from McAfee:
McAfee Knowledgebase Article:

THANKS TO ALL THE CONTRIBUTORS! We got too many to mention here. Please keep it coming using our contact page: . I haven't counted the submissions, but they may be at a hundred now. Some report about networks with thousands of down machines and organizations who had to shut down for business until this is fixed.

NOTE: We do have some journalists who would like to talk to someone whose network got affected. In particular, if the network was large. Let us know if you are willing to talk about this in public. We will not forward your contact information unless you specifically ask us to.



Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org

19 comment(s)


It deletes the svchosts.exe. So that mean no networking when the machine comes backup. So roll back is going to involve a USB stick and a new pair of shoes after walking to 1000 hosts :(
We're seeing this issue as well. Only SP3 so far. We were able to stop the spread of the bad DAT file with our ePO server and were able to push out the old DAT that helped some of our machines. We also had some laptop users get the DAT file from home or while coming into the office.

One fix is to delete the bad DAT file the client at "C:\Program Files\Common Files\McAfee\Engine". Delete any av*.dat. Then reboot and the old DAT should be grabbed.

We now have about 100 machines that are in a reboot loop. It looks like the svchosts is in quarantine.

I can remember such poisonous update about 10 years ago and we had flushed McAfee right there and then for Symantec
Took out almost all of our 600 users in head office and call centers.. What a mess....
Having to touch each machine to get it back...
We have a fix for this issue
you can find it on my blog post at
I just configured our policy to exclude "svchost.exe" for virus scan to avoid this problem.

We have not been affected yet. Do you think this will work?
I just configured our policy to exclude "svchost.exe" for virus scan to avoid this problem.

We have not been affected yet. Do you think this will work?
None of our XP SP3 machines seemed to be affected it by it yet. All but 12 are now at the 5959 level and I dropped the extra.dat in the EPO repository as well.
We have an evaluation group of systems set-up to receive dats before rolling out to production. Model has served us well.
Update toi the fix I originally psoted on my blog. There appears to be a 'safer' way to recover the svchost binary. While it is a less convenient method, it is probably the best way. More at:

Diary Archives