All attempts to run any Custom scan returns the following error:
I’m using Windows XPP with McAfee SC 12.8.944, AV 16.8.708 and VS 2.8.716. A fresh downloaded MVT reports no problems found. This is a very recent complete reinstallation using these official procedures: http://service.mcafee.com/FAQDocument.aspx?lc=1033&id=TS101331
I have another freshly built system XPP machine with all final updates applied and only McAfee (same MMI/version/features) installed. Custom scan exhibits the same “98% hang on rootkit stage” I see is well documented and being researched.
I believe the reason for different results is because McAfee does not completely and accurately remove itself. I have already demonstrated this in another thread (don’t have print screens anymore): https://community.mcafee.com/thread/66234?tstart=0
McMPFSvc appears to be a McAfee firewall service; God only knows what else is leftover. When I finish migrating to my newly built system I plan to test the difference between a virgin system preinstall and after McAfee removal, then post the results. Of course this will not reveal obsolete and/or broken leftovers from many years of using McAfee.
Some may question, “Why should this be investigated and remediate”? I believe it is important because McAfee customers may experience this same error and/or further impact even after carefully following the official removal procedures. Some may move on to a different product or use none at all, but McAfee’s leftover changes will remain…however that may or may not affect their system.
Only a clean system and registry without McAfee ever being previously installed (which normally entails rebuild or restore) can guarantee consistent results at this point.
All of this and more indicates a clear lack of best practice development structure. As an assumed trusted and responsible company, McAfee must insure any and all changes made to the customer’s system (including the registry) is completely restored using their official removal process, even obsolete leftovers from years of use. This is the kind of behavior bad software often exhibits.
No, I’m not going to open another SR; it’s just plain common sense. If McAfee doesn’t know what they have changed in the past and are changing now, picking through my machine isn’t going to help the situation. I’m in the process of curing my old McAfee changes by migrating to a clean build; its present and future I’m concerned about now.
Here are the testing results for a fresh McAfee install:
Platform – fresh Win XPP SP3 build with all updates including IE, no previous McAfee
Installer - Downloaded today 04/08/2014 (Master Installer version 6.8.704.2, signature Jan 17, 2014)
McAfee Installed - SC 12.8.957, AV 16.8.708 engine 1882.0 (5/7/2014), VS 2.8.716
MCPR – Downloaded today 04/08/2014 (version 6.8.709.0, signature Aug 12, 2013)
Leftovers Summary after XP full uninstall via Add/Remove Programs (reboot), MCPR tool (reboot) and deletion of all %temp% and system temp files):
One example, McAfee firewall service Registry entry is added but not removed: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\McMPFSvc
No disrespect intended but the dates you are posting are reading April 8 , 2014 not May 8,2014......Just wanting to clarify you are downloading from your online McAfee account and not installing from a cd
MCPR is constantly updated as well so each time you use it you should always download a fresh copy
Thanks K3TG, glad to see someone is actually paying attention!
Yes, my bad (I’m a month behind on everything anyway). But you are correct, all downloads should say May 8th, today.
All those dates look a bit old to me too, especially "signature Aug 12, 2013", is your System Clock accurate? However I doubt the issue will ever be diagnosed here as we all are simply users like yourself.
On another thread I believe, if my memory serves me right, you objected to installing a .net component that something had asked for. Did you ever install it?
This sort of issue is far too technical to be analysed here and I know you don't want to open another SR but you are aware I hope, that you can escalate the old SR to a higher level if you wish. All you have to do is contact TS again and ask for it.
Message was edited by: Ex_Brit on 08/05/14 6:51:42 EDT PM
It’s not that technical at all and I’m not trying to solve it myself, simply bring attention to it so that it will be resolved.
But you verified one of my points: if the system uninstall doesn’t catch everything, the MCPR should. Download it yourself; it hasn’t been updated since Aug 12, 2013. This is not an XP only issue.
No, I never did install .NET (it’s against my religion stemming from over a decade ago). I beg forgiveness from all struggling .NET developers out there. Anyone using Vista will need it, it’s a core part of the OS and one major reason it sucks so much.
The .net has nothing to do with whether or not Vista users need it, all kinds of software relies on it and will act up or simply not work without it. However it's your choice of course, but in my (many) years of experience, a system that has nothing being offered on Windows/Microsoft Updates other than Bing Desktop and a graphics driver or two, is a happy one.
Back to the dates..... that's not what I see. I download MCPR from http://download.mcafee.com/products/licensed/cust_support_patches/MCPR.exe and this is what I get:
Unless it';s sensing XP and winding itself back perhaps???
You are looking at the System properties of a newly downloaded file; check the Digital Signatures tab (Timestamp column) which is independent of the OS file properties or System time.
I just realised that although it says the cert is OK it expired on 31/12/2013 so I will point that out on our next conference call. I don't think it's Earth Shattering so no need to panic over that.