Dear Uncle Frankie,
Dear Uncle Frankie,
Dear Uncle Frankie,
Happy New Year!
McAfee has developed a SuperDAT remediation Tool to restore the svchost.exe file on affected systems.
Q: What does the SuperDAT Remediation Tool Do?
A: The tool suppresses the driver causing the false positive by applying an Extra.dat file in c:\program files\commonfiles\mcafee\engine folder. It then restores the svchost.exe by looking first in %SYSTEM_DIR%\dllcache\svchost.exe, if not present it will attempt a restore from %WINDOWS%\servicepackfiles\i386\svchost.exe, if not present it will attempt a restore from quarantine. After the tool is run, the machine needs to be rebooted.
Recommended Recovery SuperDAT Procedure
1. From a machine that has Internet access, locate and download the Recovery SuperDAT at http://download.nai.com/products/mcafee-avert/tools/SDAT5958_EM.exe and save it to portable media.
2. Take the portable media to each affected machine and run the tool. If you are not able to run the tool on the affected machine, boot in safe mode
3. Execute the Recovery SuperDAT tool
4. Reboot in normal mode
5. Use the product update to update to 5959
For additional FAQs and information, go to https://kc.mcafee.com/corporate/index?elq_mid=2373&elq_cid=1475603&page=content&id=KB68780 which will remain up to date.
UPDATE #4 (7:38pm US/CDT)
McAfee has published recovery procedures for the following two scenarios:
This information has been posted on http://vil.nai.com/vil/5958_false.htm and will be continuously updated as more information and procedures become available.
UPDATE #3 (2:55pm US/CDT)
Emergency DAT 5959 has been posted and is available at http://www.mcafee.com/apps/downloads/security_updates/dat.asp. This file is available in English and is replicating in other languages. For MORE information, go to the 5958 DAT Report on http://vil.nai.com/vil/5958_false.htm.
UPDATE #2 (12:47pm US/CDT)
McAfee is aware that a number of corporate customers have incurred a false positive error due to incorrect malware alerts. Our initial investigation indicates that the error can result in moderate to significant performance issues on systems running Windows XP Service Pack 3.
The 5958 DAT has been removed from McAfee download servers, preventing any further impact to corporate customers. McAfee teams are working with the highest priority to support impacted customers and plan to provide an update virus definition file shortly. You can view information at https://kc.mcafee.com/corporate/index?elq_mid=2373&elq_cid=1475603&page=content&id=KB68780 (NOTE: system is currently slow) or the McAfee Community at http://community.mcafee.com/docs/DOC-1374/
We will notify you of an emergency update when available, or in 90 minutes.
ORIGINAL EMAIL (11:06am US/CDT)
McAfee is aware of a w32/wecorl.a false positive with the 5958 DAT file April 21 at 2:00pm (GMT +1). McAfee advises NOT to download this DAT. Please disable pull tasks and update tasks.
Well I write this after several frustrating days of attempting to use the Ghost(r) Console to run various different “backup regime” for Dell PowerEdge(r) 2950’s and Dell PowerEdge(r) 2900’s.
Initially I had trouble with the drivers for the R5400 as well as the Optiplex 760’s but working with Symantec I was able to get the appropriate drivers, from them directly, that would work.
Currently after the past 2 days now support was able to recreate my issue. In this I was able to manually load a Broadcom(r) driver for the 5708 NIC, however once the backup completes and the server is rebooted (both the 2950 and the 2900) the server never comes back up.
Here are some thoughts that go through ones head:
1) Q: Perhaps the virtual partition is not releasing?
A: Nope, after running gdisk 32 /status you see what you expect to see with no ghost partition.
2) Q: Perhaps the gdisk32 command is just not showing the virtual partition
A: Lets go ahead and try one system with rebooting by using ghreboot.
Grr! Still not good.
Okay, so now I have two expensive door stops, I have worked with Symantec on some of the NIC issues let’s get started on finding a fix to this issue. After several hours on the phone (you can almost hear all three engineers on their side scratching their head) “Hmm, we can recreate the problem, but we can’t seem to fix it.”
Great, that’s neat … what’s next?
Ticket bumped to internal dev group.
How long do you think I’ll need to wait before getting a reply. … … … …
I’ll let you all know what happens. Off to rebuild my servers.
(Side note: Yup tried to cast back the images … servers and console no longer can see one another. Manual rebuild.)
What are “Page Faults” you might ask.
Well if you were to plug into Google(r) you would find many definitions. All will fall along the same lines.
“An interrupt that occurs when a program requests data that is not currently in real memory. The interrupt triggers the operating system to fetch the data from a virtual memory and load it into RAM.
An invalid page fault or page fault error occurs when the operating system cannot find the data in virtual memory. This usually happens when the virtual memory area, or the table that maps virtual addresses to real addresses, becomes corrupt.” as defined by Webopedia – Internet.com
Or you could go with PC Mag’s version:
“A virtual memory interrupt that signals that the next instruction or item of data is not in physical memory and must be swapped back in from the disk. If the required page on disk cannot be found, then a page fault error occurs, which means that either the operating system or an application has corrupted the virtual memory. If such an error occurs, the user has to reload the application.”
Now to my evening/morning …
“Mike, it appears we have a network problem …”
“Okay, have you verified the settings?” I ask, wondering to myself if OSI now stands for ‘O, see, I… uhh…’
“No.” is the expected and returned response.
“Well, okay. I can go to the client and check settings and run some tests.” already knowing this is going to be a late night, “When will the client be ready for me to take the network down for testing?”
At this point many join in the fray offering up times. I interject that it sounds like 2200CST is a good start time.
We all agreed.
What, low and behold, to my wondering eyes did appear but … millions and millions of tiny page faults increasing by hundreds of thousands did appear! (sorry too close to Christmas, though just recently past.)
Once this process and application were closed everything worked as expected. But what should I hear but many tiny voices, developer’s my dear, cry in agony “No way! It can’t be us this year!”
Okay okay I have to stop. lol simply put, if you see massive unexplainable page faults and you have dutifully followed basic troubleshooting skills (using the OSI model as reference of course) then perhaps you might have an application issue.
I decided we were done. Completed what was needed for today, the client is happy, and the team can all be sent home.
Good night one and all and Happy New Year!
… but does it matter?