On some our client computers (xp pro) users claim there is slow response when performing any task. After looking in Task Manger under the processes tab frameworkservice shows high cpu usage (98%). I have to end the process to enable user to perform task on their computer. Is there a fix for this instead of stopping the process? If I restart the computer everything is fine but eventually same problem arises.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
mcAfee framework service showing high cpu usage 1
- Thread starter zindians
- Start date
-
1
- #2
CingularEPO
IS-IT--Management
Delete the Sitemaplist.xml on the machine and restart the Framework service.. I was having the same problem and that has fixed the problem.. It is not all machines but 1 out 7 that I have upgraded from 251 sp1 to 3.01...
- Thread starter
- #3
CingularEPO
IS-IT--Management
The file is used for locating which repository to get its updates from. Look under the directory where the new epoagent is installed.. In my shop, it is installed in the
C:\Documents and Settings\All Users\Application Data\Network Associates\Common Framework directory.. I spoke with mcafee yesterday and this is a known issue and they are coming up with a superdat to correct this problem.. It delete the sitemaplist.xml file and restart the framework service.. The file is then regenerated and the machine is ok after that.. It has not happened on every machine but enough for me to esculate to them. Another thing that I saw was by looking on the agent detail log, my machines was checking for an update every second.... this is why the framework service is using the cpu so much.... I hope this helps.. If they are anymore questions, let me know.. I have an inside track into Mcafee..
C:\Documents and Settings\All Users\Application Data\Network Associates\Common Framework directory.. I spoke with mcafee yesterday and this is a known issue and they are coming up with a superdat to correct this problem.. It delete the sitemaplist.xml file and restart the framework service.. The file is then regenerated and the machine is ok after that.. It has not happened on every machine but enough for me to esculate to them. Another thing that I saw was by looking on the agent detail log, my machines was checking for an update every second.... this is why the framework service is using the cpu so much.... I hope this helps.. If they are anymore questions, let me know.. I have an inside track into Mcafee..
- Thread starter
- #5
CingularEPO; I believe you meant to say sitelist.xml.
I've had the same problem with frame work and had to finally uninstall and reinstall to get it to work right. So there's even another option. Seems like NT4 servers and work stations were the worst.
Sometimes EPO doesn't install correctly and files get corrupted.
I've had the same problem with frame work and had to finally uninstall and reinstall to get it to work right. So there's even another option. Seems like NT4 servers and work stations were the worst.
Sometimes EPO doesn't install correctly and files get corrupted.
CingularEPO
IS-IT--Management
No the file name is sitemaplist.xml.... That is the file that they have had me delete and then restart the framework service... They have made me a superdat that will accomplish this task.. I have since then created a task to run this superdat once on every machine in my company.... Once a machine gets the new agent it will also receive a task to run the superdat. This is eliminate the problem before it happens.
We too, have seen the framework service pin the cpu on an NT 4.0 server. (The server is also running Goupshield 4.5 for MS Exchange 5.5)
I just recently upgraded this machine to VSE 7.1 from Netshield 4.5.
In doing so, I also installed Alert Manager 4.7.
Groupshield still runs and works great, but I'm a little shy about upgrading to 5.0 after seeing this CPU utilization issue rear its ugly head.
Whenever the CPU gets pinned, I can't even stop the framework service from the task manager or the services control panel. The only cure is to re-boot the server, which always makes me an extremely unpopular person.
We killed EPO (2.5) a year ago in our plant after nothing but repeated problems forced endless hours of babysitting we just couldn't afford.
Is the framework service wholly EPO related? NAI support has already had me remove all EPO traces from this machine, so I just don't get this one.
Would an uninstall and re-install of VSE 7.1 be the ticket? Or should I just try deleting the sitemaplist.xml file, then stop and start the framework service?
Any guidance here appreciated....
Phil
I just recently upgraded this machine to VSE 7.1 from Netshield 4.5.
In doing so, I also installed Alert Manager 4.7.
Groupshield still runs and works great, but I'm a little shy about upgrading to 5.0 after seeing this CPU utilization issue rear its ugly head.
Whenever the CPU gets pinned, I can't even stop the framework service from the task manager or the services control panel. The only cure is to re-boot the server, which always makes me an extremely unpopular person.
We killed EPO (2.5) a year ago in our plant after nothing but repeated problems forced endless hours of babysitting we just couldn't afford.
Is the framework service wholly EPO related? NAI support has already had me remove all EPO traces from this machine, so I just don't get this one.
Would an uninstall and re-install of VSE 7.1 be the ticket? Or should I just try deleting the sitemaplist.xml file, then stop and start the framework service?
Any guidance here appreciated....
Phil
A shortcut to rebooting the server is to send the affected machine a 'Send Agent Install' message from ePO!
This works even when the service cannot be restarted by the services applet.
Alas, it is not a solution as the problem can still randomly recur.
This works even when the service cannot be restarted by the services applet.
Alas, it is not a solution as the problem can still randomly recur.
Thanks sclcomp,
As I mentioned, we are no longer using EPO, so I've gone ahead and tried the above suggestion of deleting the sitemaplist.xml file, then stopping and re-starting the framework service, which does indeed re-build the sitemaplist file.
Time will tell if this works. I hope so.
Incidentally, all of the NT 4.0 and 2000 machines that got upgraded from netshield 4.5 to VSE 7.1 have suffered the high CPU usage dilemma. All have had this fix applied now.
Cheers,
Phil
As I mentioned, we are no longer using EPO, so I've gone ahead and tried the above suggestion of deleting the sitemaplist.xml file, then stopping and re-starting the framework service, which does indeed re-build the sitemaplist file.
Time will tell if this works. I hope so.
Incidentally, all of the NT 4.0 and 2000 machines that got upgraded from netshield 4.5 to VSE 7.1 have suffered the high CPU usage dilemma. All have had this fix applied now.
Cheers,
Phil
in reguards to the groupshield question, 4.5 version was not good, 5.0 is good. No version of groupshield uses framework yet, so this is not an issue. I would say best thing period for groupshield is upgrade as 5.0 is leaps and bounds better.
FatesWebb
if you do what I suggested it is not my fault...
FatesWebb
if you do what I suggested it is not my fault...
Well, I tried the above fix to remedy the CPU usage issue on my 2000 and NT 4.0 machines - unfortunately to no avail.
After being out of the office for 2 days, I returned to find that ALL of the machines I had recently upgraded to VSE 7.1 AND tried the sitemaplist.xml deletion/restart framework fix had their CPUs pinned out by the framework service. All of them. And what's more, when this problem occurs on a server, you cannot stop and start the framework service. You must re-boot the server. (If you are not using EPO - like me - EPO was just another babysitting headache for us.)
My BP is now soaring, since it was on McAfee's advice that I perform this upgrade to alleviate the issue I was having with mcupdate.exe maxxing out my CPUs on these machines under VSE 7.0 and in some cases Netshield for NT 4.0. I've gone from one service causing the problem to another service casing the CPU usage issue.
I'm fast coming to the conclusion that the problems caused by McAfee anti-virus installations on these poor machines are very nearly as bad as actually being infected by a virus!
I'm going to have to use some more of that connect support this week, I guess.
I don't know which way to go now. Perhaps the uninstall/reinstall route. Or maybe move on to a Symantec solution......
Phil
After being out of the office for 2 days, I returned to find that ALL of the machines I had recently upgraded to VSE 7.1 AND tried the sitemaplist.xml deletion/restart framework fix had their CPUs pinned out by the framework service. All of them. And what's more, when this problem occurs on a server, you cannot stop and start the framework service. You must re-boot the server. (If you are not using EPO - like me - EPO was just another babysitting headache for us.)
My BP is now soaring, since it was on McAfee's advice that I perform this upgrade to alleviate the issue I was having with mcupdate.exe maxxing out my CPUs on these machines under VSE 7.0 and in some cases Netshield for NT 4.0. I've gone from one service causing the problem to another service casing the CPU usage issue.
I'm fast coming to the conclusion that the problems caused by McAfee anti-virus installations on these poor machines are very nearly as bad as actually being infected by a virus!
I'm going to have to use some more of that connect support this week, I guess.
I don't know which way to go now. Perhaps the uninstall/reinstall route. Or maybe move on to a Symantec solution......
Phil
Hi.
reading this thread it is noticable that most if not all of us have offered solutions that NAI suggest we try.
The 'suggest we try' part is very worrying.
None of the 'solutions' that I'm aware of actually work, which suggests to me that this is a problem for which NAI has no solution.
Is this fair comment?
Steve.
reading this thread it is noticable that most if not all of us have offered solutions that NAI suggest we try.
The 'suggest we try' part is very worrying.
None of the 'solutions' that I'm aware of actually work, which suggests to me that this is a problem for which NAI has no solution.
Is this fair comment?
Steve.
Hi Steve,
In my view, yes, that is INDEED a fair comment.
What frosts me even more is the fact that we just renewed our support and licenses for McAfee AVD.
Should have shelved it and bought the Symantec product.
If I do find a solution to this that works, I'll be sure to post it here.
Phil
In my view, yes, that is INDEED a fair comment.
What frosts me even more is the fact that we just renewed our support and licenses for McAfee AVD.
Should have shelved it and bought the Symantec product.
If I do find a solution to this that works, I'll be sure to post it here.
Phil
I set the update schedule to update weekly - i.e. every Thursday at 4:30 pm (after the dats come out, usually)instead of daily.
3 weeks have gone by, and I've successfully updated each week without the framework service going nuts and eatin' up the CPU.
I guess I'll just have to watch for any intermediary dat releases and do the updates for them manually.
Phil
3 weeks have gone by, and I've successfully updated each week without the framework service going nuts and eatin' up the CPU.
I guess I'll just have to watch for any intermediary dat releases and do the updates for them manually.
Phil
Vax,
F.Y.I. NAI has an e-mail notification when new DATs are released.
F.Y.I. NAI has an e-mail notification when new DATs are released.
- Status
Similar threads
- Locked
- Question
- Locked
- Question