WinXP Pro Microsoft Security Essentials uninstall FAILS

  • Thread starter Thread starter Greegor
  • Start date Start date
G

Greegor

In WinXP Pro, using control panel add/remove programs FAILS to
fully remove Microsoft Security Essentials, looking in the wrong
directory for epp.msi (manifest) and leaving it in a state where
MSE can neither be removed nor installed.

0x80070002
0x80070645

MS Fixit for this purpose apparently fails to remove all remnants of
failed uninstall.

I tried the manual cleanup method through regedit but two are
magically protected.

(X) Cannot delete LEGACY_MSMPSVC
Error while deleting key.

(X) Cannot delete Microsoft Antimalware Setup
Error while deleting key.

How are these keys protected in REGEDIT?

I'm not 100% sold that killing MSMPSVC would help but
killing "Microsoft Antimalware Setup" certainly sounds
like what might be botched up.

I noticed that data for some keys was referring
file calls to a @C:(etc) and for some others was
referring to a latin fancy f as the drive letter :

Everything was fine until UPDATE in Sept 2012
tried to push MSE Client Update Package
KB2754296 and it started looking in some
crazy wrong directory for a .msi file.
----------------------------------------
(X) The feature you are trying to use is on a
network resource that is unavailable
---------------------------------------

I somehow made it through ALL of the many Framework
updates that failed with similar referrals to a WRONG
directory, partly through installing MSI 4.5
(KB942288-v3-x86.exe) I think.

But this Microsoft Security Essentials uninstall failure
is STILL looking in some crazy WRONG directory
for the epp.msi manifest and leaving some troublesome
remnant.

Failures on multiple clean installs with no prior
antivirus software remnants interfering.

Updates failing is bad enough, but failing in
the midst of upgrading an antivirus engine
and blocking both uninstall and install
of an antivirus engine seems amateurish,
spectacular and CATASTROPHIC.

How do I kill these apparent remnants like a
"Microsoft Antimalware Setup" key if regedit is
protecting it?

Is killing the LEGACY_MSMPSVC key a bad idea?
 
Greegor said:
In WinXP Pro, using control panel add/remove programs FAILS to
fully remove Microsoft Security Essentials, looking in the wrong
directory for epp.msi (manifest) and leaving it in a state where
MSE can neither be removed nor installed.

0x80070002
0x80070645

0x80070002 is for:
"The system cannot find the file specified."

0x80070645 is for:
"This action is only valid for products that are currently installed."

Seems like the MSE installation registry is badly screwed up.
MS Fixit for this purpose apparently fails to remove all remnants of
failed uninstall.

When an installation is in the "grey" state like yours, the Windows
Installer's generic "Repair" seldom succeed.
I tried the manual cleanup method through regedit but two are
magically protected.

(X) Cannot delete LEGACY_MSMPSVC
Error while deleting key.
(X) Cannot delete Microsoft Antimalware Setup
Error while deleting key.

How are these keys protected in REGEDIT?

The "MSMPSVC" may need to be stopped in order to delete it. You can use
the Device Manager to do both, so open it and enable the "Show hidden
devices from the "View" top menu. In the device category tree such as
"Disk drives", "Keyboards", etc., look for "Non-Plug and Play Drivers"
and expand it. Under it, look for "MSMPSVC" or "Malware Protection" or
similar. When you found it, open its "Properties" dialog and go to
"Driver" tab. Make sure the "Service name" says "MSMPSVC" (if it's not,
then you got the wrong entry. check the others). When you found the
correct entry with "MSMPSVC" service name, uninstall the entry and reboot
when asked.
Is killing the LEGACY_MSMPSVC key a bad idea?

If it's working OK, then it's a bad idea because malwares can exploit it.
But if it's not working OK, then it's a good idea. In fact, it's the only
way to remove it if the uninstaller choked up.
 
Greegor said:
In WinXP Pro, using control panel add/remove programs FAILS to
fully remove Microsoft Security Essentials, looking in the wrong
directory for epp.msi (manifest) and leaving it in a state where
MSE can neither be removed nor installed.

0x80070002
0x80070645

0x80070002 is for:
"The system cannot find the file specified."

0x80070645 is for:
"This action is only valid for products that are currently installed."

Seems like the MSE installation registry is badly screwed up.
MS Fixit for this purpose apparently fails to remove all remnants of
failed uninstall.

When an installation is in the "grey" state like yours, the Windows
Installer's generic "Repair" seldom succeed.
I tried the manual cleanup method through regedit but two are
magically protected.

(X) Cannot delete LEGACY_MSMPSVC
Error while deleting key.
(X) Cannot delete Microsoft Antimalware Setup
Error while deleting key.

How are these keys protected in REGEDIT?

The "MSMPSVC" may need to be stopped in order to delete it. You can use
the Device Manager to do both, so open it and enable the "Show hidden
devices from the "View" top menu. In the device category tree such as
"Disk drives", "Keyboards", etc., look for "Non-Plug and Play Drivers"
and expand it. Under it, look for "MSMPSVC" or "Malware Protection" or
similar. When you found it, open its "Properties" dialog and go to
"Driver" tab. Make sure the "Service name" says "MSMPSVC" (if it's not,
then you got the wrong entry. check the others). When you found the
correct entry with "MSMPSVC" service name, uninstall the entry and reboot
when asked.
Is killing the LEGACY_MSMPSVC key a bad idea?

If it's working OK, then it's a bad idea because malwares can exploit it.
But if it's not working OK, then it's a good idea. In fact, it's the only
way to remove it if the uninstaller choked up.
 
Greegor said:
In WinXP Pro, using control panel add/remove programs FAILS to
fully remove Microsoft Security Essentials, looking in the wrong
directory for epp.msi (manifest) and leaving it in a state where
MSE can neither be removed nor installed.

0x80070002
0x80070645

MS Fixit for this purpose apparently fails to remove all remnants of
failed uninstall.

I tried the manual cleanup method through regedit but two are
magically protected.

(X) Cannot delete LEGACY_MSMPSVC
Error while deleting key.

(X) Cannot delete Microsoft Antimalware Setup
Error while deleting key.

How are these keys protected in REGEDIT?

I'm not 100% sold that killing MSMPSVC would help but
killing "Microsoft Antimalware Setup" certainly sounds
like what might be botched up.

I noticed that data for some keys was referring
file calls to a @C:(etc) and for some others was
referring to a latin fancy f as the drive letter :

Everything was fine until UPDATE in Sept 2012
tried to push MSE Client Update Package
KB2754296 and it started looking in some
crazy wrong directory for a .msi file.
----------------------------------------
(X) The feature you are trying to use is on a
network resource that is unavailable
---------------------------------------

I somehow made it through ALL of the many Framework
updates that failed with similar referrals to a WRONG
directory, partly through installing MSI 4.5
(KB942288-v3-x86.exe) I think.

But this Microsoft Security Essentials uninstall failure
is STILL looking in some crazy WRONG directory
for the epp.msi manifest and leaving some troublesome
remnant.

Failures on multiple clean installs with no prior
antivirus software remnants interfering.

Updates failing is bad enough, but failing in
the midst of upgrading an antivirus engine
and blocking both uninstall and install
of an antivirus engine seems amateurish,
spectacular and CATASTROPHIC.

How do I kill these apparent remnants like a
"Microsoft Antimalware Setup" key if regedit is
protecting it?

Is killing the LEGACY_MSMPSVC key a bad idea?


Go here: Uninstalling MSE -
http://answers.microsoft.com/en-us/...ling-mse/a63b8c4b-58ed-437e-8086-fa08d80725a4

Follow all the instructions starting in the section that begins "The
following was added 5/7/12 based on a reply from Support to address
removal of MSE to resolve issues with a failed upgrade from 2.x to v4"
and continue with the further directions there, as needed.
 
0x80070002 is for:
"The system cannot find the file specified."

0x80070645 is for:
"This action is only valid for products that are currently installed."

Seems like the MSE installation registry is badly screwed up.


When an installation is in the "grey" state like yours, the Windows
Installer's generic "Repair" seldom succeed.




The "MSMPSVC" may need to be stopped in order to delete it. You can use
the Device Manager to do both, so open it and enable the "Show hidden
devices from the "View" top menu. In the device category tree such as
"Disk drives", "Keyboards", etc., look for "Non-Plug and Play Drivers"
and expand it. Under it, look for "MSMPSVC" or "Malware Protection" or
similar. When you found it, open its "Properties" dialog and go to
"Driver" tab. Make sure the "Service name" says "MSMPSVC" (if it's not,
then you got the wrong entry. check the others). When you found the
correct entry with "MSMPSVC" service name, uninstall the entry and reboot
when asked.


If it's working OK, then it's a bad idea because malwares can exploit it.
But if it's not working OK, then it's a good idea. In fact, it's the only
way to remove it if the uninstaller choked up.



Go here: Uninstalling MSE -http://answers.microsoft.com/en-us/protect/forum/mse-protect_start/un...

Follow all the instructions starting in the section that begins "The
following was added 5/7/12 based on a reply from Support to address
removal of MSE to resolve issues with a failed upgrade from 2.x to v4"
and continue with the further directions there, as needed.

JJ and glee (Glen) : Thank you for the pointers.
I will study those further but I made another
discovery related to this problem.

I pulled an entire system out of storage that
had a clean install, all of the updates and MSE.
Version 4.0.1526.0 as reported by the
control panel add/delete programs function.

Having seen a suggestion that the MSE upgrade
might work better if a person uninstalls the old
version manually with the add/delete programs
function, then installing the newer MSE engine,
I tried add/delete programs function.

One thing this revealed to me is that the problem
with uninstalling MSE existed BEFORE MS started
pushing out the new MSE engine.

Failed looking for epp.msi in e:\e2320f5e64257fbee02e4a\x86

(Insane since no such directory ever existed on that drive!)

The epp.msi file it was looking for was in:
c:\Program Files\Microsoft Security Client\Backup\x86

And after operating on that it (STILL) looked for dw20shared.msi
in another insane directory. It was in the same drectory as above,
c:\Program Files\Microsoft Security Client\Backup\x86

After successfully uninstalling MSE I did a full backup,
installed Microsoft Software Installer 4.5 KB942288-v3
and then Windows Update site offered me the Sept 2012
version of MSE KB2754295 10.60 MB so I took it.

The install completed and MSE updated definitions.

I will watch it closer because one report said theirs
installed just fine but then something in definitions
caused it to get partially turned off on a subsequent
day but resumed function by the third day as a result
of another definition update. Had I known of that
when MSE on the broken system stopped. I might
have "rode it out" and updated definitions ONLY for
two or three days to look for new definitions clearing
the problem.

It occurs to me that my aggressive attempt to uninstall
and reinstall MSE ran afoul of the botched MSE uninstall.
(Where it looks for epp.msi and dw20shared.msi files
in some insane directory on a nonsense drive.)

What exactly started this calling to files in some
insane directory on a nonsense drive? The old MSI?

Why isn't Microsoft pushing out MSI 4.5? Or are they now?

I think I'm going to restore the broken system with
this MSE "grey condition" from an image backup.

Then again, this might be a good opportunity to try out
Avast or some other antivirus program...
 
I noticed that MSE worked fine through several reboots
then within mere hours there was a new definition file
being pushed by Windows Update and it caused
MSE to FAIL. Then within mere hours again there
was another definition file pushed by Windows Update
which cleared the failure. It appears that every
other definition update triggers a FAILURE of MSE.

I can understand several batches of definition updates
each day but to have new definitions HOURLY
seems excessive and improbable.

In Windows Update the KB2310138 seems to stay
the same while the definition numbers increase
on an hourly (or less) basis.
1.137.1751.0
1.137.1752.0
1.137.1759.0

Indeed it appears that definition updates cause
MSE to toggle the FAILURE on and off.

What a mess.
 
I noticed that MSE worked fine through several reboots
then within mere hours there was a new definition file
being pushed by Windows Update and it caused
MSE to FAIL.   Then within mere hours again there
was another definition file pushed by Windows Update
which cleared the failure.  It appears that every
other definition update triggers a FAILURE of MSE.

I can understand several batches of definition updates
each day but to have new definitions HOURLY
seems excessive and improbable.

In Windows Update the KB2310138 seems to stay
the same while the definition numbers increase
on an hourly (or less) basis.
1.137.1751.0
1.137.1752.0
1.137.1759.0

Indeed it appears that definition updates cause
MSE to toggle the FAILURE on and off.

What a mess.

Now it appears that MSE definition updates
have slowed down to a more realistic frequency.

KB2310138 is at 1.137.1924.0 at 8:59 AM Central


I went into the broken system and regedit to
delete all references to "Microsoft Security Essentials"
and "Microsoft Security Client". Long and tedious process.
The two keys I mentioned before would not delete of course.

Rebooted and attempted to install MSE (fail).

I installed Avast (free) with no problems whatsoever.

Confirmed that it has MSI 4.5 by finding "KB942288-v3"
in the registry. ( Not the usual method, but good enough for me.)

Some Framework updates were still failing on that
machine so I uninstalled what I could and ran the latest
Framework Setup Cleanup Util (1.0-4.5) from MSDN.

Even that left behind pieces that still showed up
in the add/remove programs list.

I went into regedit on a search and delete operation to
delete all keys matching ".NET Framework".
This was long and tedious again. reboot

Finally the add/remove programs showed no trace
of .Framework. We don't need it.

When MS Update site offered all of the Framework
junk and I just ticked the little boxes for
"Don't show me this again" on them all.

This took 2 or 3 cycles of reboot and Update cite.

The "broken" system now functions well, though
I consider it to be irreversably "contaminated"
because I know that the crude editing of the registry
can cause insidious problems.

Now I'm looking through various truly free registry cleaners.
I haven't used one of those for about 7 years.

http://pcsupport.about.com/od/toolsofthetrade/tp/free-registry-cleaner-programs.htm
 
Greegor said:
Now it appears that MSE definition updates
have slowed down to a more realistic frequency.

KB2310138 is at 1.137.1924.0 at 8:59 AM Central


I went into the broken system and regedit to
delete all references to "Microsoft Security Essentials"
and "Microsoft Security Client". Long and tedious process.
The two keys I mentioned before would not delete of course.

Rebooted and attempted to install MSE (fail).

I installed Avast (free) with no problems whatsoever.

Confirmed that it has MSI 4.5 by finding "KB942288-v3"
in the registry. ( Not the usual method, but good enough for me.)

Some Framework updates were still failing on that
machine so I uninstalled what I could and ran the latest
Framework Setup Cleanup Util (1.0-4.5) from MSDN.

Even that left behind pieces that still showed up
in the add/remove programs list.

I went into regedit on a search and delete operation to
delete all keys matching ".NET Framework".
This was long and tedious again. reboot

Finally the add/remove programs showed no trace
of .Framework. We don't need it.

When MS Update site offered all of the Framework
junk and I just ticked the little boxes for
"Don't show me this again" on them all.

This took 2 or 3 cycles of reboot and Update cite.

The "broken" system now functions well, though
I consider it to be irreversably "contaminated"
because I know that the crude editing of the registry
can cause insidious problems.

Now I'm looking through various truly free registry cleaners.
I haven't used one of those for about 7 years.

http://pcsupport.about.com/od/toolsofthetrade/tp/free-registry-cleaner-programs.htm

Registry cleaners... you are just going from bad to worse.
Did you even read the directions at the link I posted? Why didn't you
create the mseremoval.bat file to remove the entries and files?
 
Glen > Registry cleaners... you are just going from bad to worse.
Glen > Did you even read the directions at the link I posted?  Why
didn't you
Glen > create the mseremoval.bat file to remove the entries and files?

Just for giggles, Glen, I uninstalled Avast on that machine
and MSMPSVC service is still running on it.
It shows up in msconfig but nowhere else.
I ran the batch file you pointed to.
STILL got the 0x80070645 error preventing MSE install.
Rebooted and found that MSMPSVC was still running
and the protected registry keys were still there.
Temporarily stopped MSMPSVC from starting at boot
(msconfig) and rebooted. Not there in this temporary state.
msconfig does not permanently delete an unwanted service however.

Full boot then has the registry entry and service again.

I found this:

http://blogs.technet.com/b/markrussinovich/archive/2012/01/05/3473797.aspx

I was particularly intrigued by the part where he found that
MSE install failed simply because one key was already present!

"an open of the registry key
HKCR\Installer\UpgradeCodes\11BB99F8B7FD53D4398442FBBAEF050F
returned SUCCESS in the failing trace."

It doesn't match in mine.
But that key in mine shows 13 UpgradeCodes which is interesting
since the previous key shows only 12 PRODUCTS.
I can't tell which "UpgradeCode" is the one fouling the install, if
any.

So I looked at an identical system with MSE installed.
MSE is not even listed as one of the "PRODUCTS" previous to the
"UpgradeCode" list.

Notice below the article that a comment asked HOW the code
was left there in the first place, implying that it should not
have been left behind by an install, failed or not.

OK, let's face it, when MS put out MSE, their uninstaller
with it was BOTCHED. MS FIXIT failed as well. AND the
Ingenius BATCH file failed also.

I stand by my actions of the other day which were to
cut my losses, install Avast free and slate this machine
to get an image backup restore of a relatively clean install.
(In a few weeks)

I'm one of those guys who built an Altair 8800B in 1977
and disassembled Bill Gates first product, Altair BASIC.
That tedious monkeybusiness was not a Concorde fallacy.
This issue IS a Concorde fallacy, for me at least.
For Microsoft, persuing this might not be a Concorde fallacy.
(A cleaner that TRULY removes the troublesome
remnants of the old MSE uninstall that was a
BOTCHED JOB might be a good customer service move.)
(Ideally a truly repaired UNINSTALLER for the previous
MSE engine should have been issued along with the
new and improved MSE engine.)
Then there's that definition screwup that caused MSE
to temporarily shut down, which rightly had me taking
the drastic action of uninstalling the broken MSE.
(Which only made things worse because of the broken uninstall.)

It's ironic that the definition screwup triggered
an apparent MSE shutdown, which in turn triggered
me to use the broken uninstall, when the definition
screwup would have righted itself within days.
But I stand by those actions as well.

Failing to swiftly respond to a failed antivirus program
would be downright foolish.

Expecting a failed antivirus program to right itself
within days would be downright insane.

Let's just chalk it up to the combined effect of
two different MS screwups.
The human response sandwiched in the middle
was logical and obvious.

I appreciate your pointer to the article with the
batch file, even though it failed me.

My biggest failing is probably that I couldn't
figure out how to rip out the MSMPSVC service
permanently. msconfig just doesn't cut it.

I was offended at first that I was prevented from
removing certain keys in the registry, but on
reflecting, I can understand why it might be
good or necessary to protect keys regarding
an antivirus product. Is the protection
deliberate or is it incidental and caused
by a running service?

Has Microsoft ever even acknowledged having
put out a bad uninstaller with Microsoft Security Esentials?
(Failing looking for parts in crazy nonexistant directories?)

Shouldn't they have known quite some time ago?
It looks like a similar installer/uninstaller failure
to the one that created problems with Framework
updates last year.

There are lots of scam registry cleaners but there
are probably some good free ones, Glen.
Ironically a registry cleaner might have averted
this mess by finding registry pointers to
nonexistant directories/ files, if that was part
of the MS installer failures.
 
Greegor said:
Glen > Registry cleaners... you are just going from bad to worse.
Glen > Did you even read the directions at the link I posted? Why
didn't you
Glen > create the mseremoval.bat file to remove the entries and files?

Just for giggles, Glen, I uninstalled Avast on that machine
and MSMPSVC service is still running on it.
It shows up in msconfig but nowhere else.
I ran the batch file you pointed to.
STILL got the 0x80070645 error preventing MSE install.
Rebooted and found that MSMPSVC was still running
and the protected registry keys were still there.
Temporarily stopped MSMPSVC from starting at boot
(msconfig) and rebooted. Not there in this temporary state.
msconfig does not permanently delete an unwanted service however.

Full boot then has the registry entry and service again.

I found this:

http://blogs.technet.com/b/markrussinovich/archive/2012/01/05/3473797.aspx

I was particularly intrigued by the part where he found that
MSE install failed simply because one key was already present!

"an open of the registry key
HKCR\Installer\UpgradeCodes\11BB99F8B7FD53D4398442FBBAEF050F
returned SUCCESS in the failing trace."

It doesn't match in mine.
But that key in mine shows 13 UpgradeCodes which is interesting
since the previous key shows only 12 PRODUCTS.
I can't tell which "UpgradeCode" is the one fouling the install, if
any.

So I looked at an identical system with MSE installed.
MSE is not even listed as one of the "PRODUCTS" previous to the
"UpgradeCode" list.

Notice below the article that a comment asked HOW the code
was left there in the first place, implying that it should not
have been left behind by an install, failed or not.

OK, let's face it, when MS put out MSE, their uninstaller
with it was BOTCHED. MS FIXIT failed as well. AND the
Ingenius BATCH file failed also.

I stand by my actions of the other day which were to
cut my losses, install Avast free and slate this machine
to get an image backup restore of a relatively clean install.
(In a few weeks)

I'm one of those guys who built an Altair 8800B in 1977
and disassembled Bill Gates first product, Altair BASIC.
That tedious monkeybusiness was not a Concorde fallacy.
This issue IS a Concorde fallacy, for me at least.
For Microsoft, persuing this might not be a Concorde fallacy.
(A cleaner that TRULY removes the troublesome
remnants of the old MSE uninstall that was a
BOTCHED JOB might be a good customer service move.)
(Ideally a truly repaired UNINSTALLER for the previous
MSE engine should have been issued along with the
new and improved MSE engine.)
Then there's that definition screwup that caused MSE
to temporarily shut down, which rightly had me taking
the drastic action of uninstalling the broken MSE.
(Which only made things worse because of the broken uninstall.)

It's ironic that the definition screwup triggered
an apparent MSE shutdown, which in turn triggered
me to use the broken uninstall, when the definition
screwup would have righted itself within days.
But I stand by those actions as well.

Failing to swiftly respond to a failed antivirus program
would be downright foolish.

Expecting a failed antivirus program to right itself
within days would be downright insane.

Let's just chalk it up to the combined effect of
two different MS screwups.
The human response sandwiched in the middle
was logical and obvious.

I appreciate your pointer to the article with the
batch file, even though it failed me.

My biggest failing is probably that I couldn't
figure out how to rip out the MSMPSVC service
permanently. msconfig just doesn't cut it.

I was offended at first that I was prevented from
removing certain keys in the registry, but on
reflecting, I can understand why it might be
good or necessary to protect keys regarding
an antivirus product. Is the protection
deliberate or is it incidental and caused
by a running service?

Has Microsoft ever even acknowledged having
put out a bad uninstaller with Microsoft Security Esentials?
(Failing looking for parts in crazy nonexistant directories?)

Shouldn't they have known quite some time ago?
It looks like a similar installer/uninstaller failure
to the one that created problems with Framework
updates last year.

There are lots of scam registry cleaners but there
are probably some good free ones, Glen.
Ironically a registry cleaner might have averted
this mess by finding registry pointers to
nonexistant directories/ files, if that was part
of the MS installer failures.


You should NOT disable a service via msconfig. It is only used for
temporarily disabling during troubleshooting, and I don't recommend it's
Services tab even for that. The correct way to disable a service is
through Administrative Tools> Services (Start> Run> services.msc). Find
and double-click the service in the list there, change the Startup Type
to Disabled, click Apply, click the Stop button to stop the service, and
click OK.

Alternately, you can delete the service if you open a command prompt
(Start> Run> cmd) and enter this command:
Sc delete msmpsvc

I have installed and uninstalled MSE on many client machines, and have
only had one that gave me this sort of trouble. It had originally had
Windows OneCare installed and it was not uninstalled (or uninstall
failed), and then had an early or beta version of MSE that wasn't
removed before installing the final version.

I wonder if your system falls into one of those scenarios.

There is a downloadable cleanup tool for Windows OneCare/Live OneCare,
here:
http://download.microsoft.com/download/4/c/b/4cb845e7-1076-437b-852a-7842a8ab13c8/OneCareCleanUp.exe
 
You should NOT disable a service via msconfig.  It is only used for
temporarily disabling during troubleshooting, and I don't recommend it's
Services tab even for that.  The correct way to disable a service is
through Administrative Tools> Services (Start> Run> services.msc).  Find
and double-click the service in the list there, change the Startup Type
to Disabled, click Apply, click the Stop button to stop the service, and
click OK.

Alternately, you can delete the service if you open a command prompt
(Start> Run> cmd) and enter this command:
Sc delete msmpsvc

I have installed and uninstalled MSE on many client machines, and have
only had one that gave me this sort of trouble.  It had originally had
Windows OneCare installed and it was not uninstalled (or uninstall
failed), and then had an early or beta version of MSE that wasn't
removed before installing the final version.

I wonder if your system falls into one of those scenarios.

There is a downloadable cleanup tool for Windows OneCare/Live OneCare,
here:
http://download.microsoft.com/download/4/c/b/4cb845e7-1076-437b-852a-7842a8ab13c8/OneCareCleanUp.exe

Glen Ventura
MS MVP  Oct. 2002 - Sept. 2009
CompTIA A+

Dell GX280 3.4 GHz P4 2 Gig RAM
Installed factory CD Win XP Pro SP2 on August 18 2012
updated online to SP3 and all updates to be current.

I'm pretty sure that Microsoft Security Essentials
did not exist when the restore CD was made.
MSE was downloaded and installed on that machine
in August of 2012. Before I tested the uninstall of MSE,
it had 4.0.1526.0 which had the BOTCHED uninstall.
(Choking, looking for epp.msi and dw20shared.msi in
some wild nonsensical directory names AND on
a DATA drive!) Too recent to be anything like a beta.

Microsoft Software Installer 4.5 had been installed.

On the test machine ONCE I helped the uninstall find
epp.msi and dw20shared.msi, it uninstalled fine and then
I downloaded and installed MSE 4.1.522.0 .

On the BROKEN machine, failing to help the uninstall
find those two files was disastrous, leaving the system
in the "grey state" mess which could not be corrected.

REVO uninstaller could not clear the conflict to
allow MSE to install.

The registry cleaner CCLEAN has uninstall functions
which I pointed at MSE to uninstall. It removed some
junk and removed the MSMPSVC service.
MSE still would not install, but I was happy to have
MSMPSVC stop eating resources.

I put Avast back on it and soon it will get an image backup.

If you do a Google search on: uninstall MSE epp.msi
and you will get at LEAST ten hits on this exact problem.

I'd like to know WHY the uninstall is looking for the
two files in some insane randomized looking
directory on my DATA drive, when it should have
been looking at:

C:\Program Files\Microsoft Security Client\Backup\x86\
for epp.msi and dw20shared.msi files it needs.

Why didn't the uninstall look there in the first place?

Didn't that RASH of Framework update failures
this last summer have similarly stupid installer failures?

Updating to Microsoft Software Installer 4.5 helped
overcome part of those update installer problems.
 
I checked out another system that was in storage.
Went to Control Panel add/remove programs and
uninstalled MSE 4.0.1526 which worked flawlessly.
The active MSI.DLL was
Version 3.1.4001.5512 Created Aug 4, 2004.

After rebooting I went to MS Update Site and
got the newer MSE, 4.1.522.0 but noticed that
it was offering KB2754295 whereas it had
offered KB2754296 to me on systems
with MSI 4.5 installed.

After MSE was installed and definitions brought current,
the MS Update Site was offering a MSE definition update
only minutes later! WTF?

So now I'm concluding that an OLD uninstall
works better under an OLD MSI than it does
under the new MSI.

Why is the new MSI not backwards compatible??

That compatability issue is why the update site
offers two different KB's depending on which
Microsoft Software Installer is installed?

And here's the kicker:

Since I got the KB file 2754295 for the old
installer, that makes me suspect that if
I update MSI to 4.5 on that machine, then
try to uninstall what I just installed, it
would fail, looking for two files in some
absurd directory on a DATA drive.

It appears that KB2754295 is in MSI 3.1.. format
and KB2754296 is in MSI 4.5 format and if you
try to unistall an old 3.1 formatted program using
MSI 4.5 it can lead to disaster.

This probably explains the rash of Framework
install problems 6 months ago.

Why did Microsoft not write MSI 4.5 to be
backward compatible and able to correctly
process uninstalls formattted for MSI 3.1?

How can I tell what other installed programs
have uninstalls that would FAIL under MSI 4.5?

Can anybody else confirm that MSI 4.5 is
unable to properly use uninstall information
formatted for MSI 3.1?

Causing uninstall or an install to point to a
nonsensical directory for a necessary file
and coughing, creating a "grey" state?

If Microsoft FAILED to write MSI 4.5 to be backward
compatible with existing uninstallers, that would
be a real disgrace.

Is it true?
 
I tested and documented a Windows install
from the OEM WinXP Pro SP2 CD.
I added latest model specific OEM drivers and
a downloaded (local) SP3 install and about
160 updates pushed by the MS Update site,
all the way up through the Framework updates.

Even in a relatively clean situation like this, the
Framework 4 Client which has to be done ALONE
still fails to install!

I resolved this update install failure on an identical
machine under identical circumstances months
ago by installing MSI 4.5 on those systems.

THIS time instead of using MSI 4.5 to overcome the
install malfunction I left intact whatever version of
MSI came with the install CD or SP3.
( Going to the C:\Windows\System32 directory
and hovering over MSI.DLL reveals:
V 3.1.4001.5512 8/4/2004 )

I found a downloadable .EXE installer for
Framework 4 Client that installed locally just fine.
Requires installer 3.1 or later, go figure!

dotNetFx40_Full_x86_x64.exe 48.1 MB Published 2/21/2011

http://www.microsoft.com/en-us/download/details.aspx?id=17718

Then the update site pushes 6 updates to that.
 
Greegor said:
I tested and documented a Windows install
from the OEM WinXP Pro SP2 CD.
I added latest model specific OEM drivers and
a downloaded (local) SP3 install and about
160 updates pushed by the MS Update site,
all the way up through the Framework updates.

Even in a relatively clean situation like this, the
Framework 4 Client which has to be done ALONE
still fails to install!

I resolved this update install failure on an identical
machine under identical circumstances months
ago by installing MSI 4.5 on those systems.

THIS time instead of using MSI 4.5 to overcome the
install malfunction I left intact whatever version of
MSI came with the install CD or SP3.
( Going to the C:\Windows\System32 directory
and hovering over MSI.DLL reveals:
V 3.1.4001.5512 8/4/2004 )

I found a downloadable .EXE installer for
Framework 4 Client that installed locally just fine.
Requires installer 3.1 or later, go figure!

dotNetFx40_Full_x86_x64.exe 48.1 MB Published 2/21/2011

http://www.microsoft.com/en-us/download/details.aspx?id=17718

Then the update site pushes 6 updates to that.


Interesting....
I don't know if any of this is useful to you, but I pass it along:

Troubleshooting .NET Framework 4 Install failures - VarunGupta - Site
Home - MSDN Blogs
http://blogs.msdn.com/b/varungupta/...hooting-net-framework-4-install-failures.aspx

Products or updates may not be installed correctly when Microsoft .NET
Framework 4 or updates for Microsoft .NET Framework 4 are installed
after the other product or update installs and a restart is pending
http://support.microsoft.com/kb/2473228
 
http://blogs.msdn.com/b/varungupta/...hooting-net-framework-4-install-failures.aspx
Products or updates may not be installed correctly
when Microsoft .NET Framework 4 or updates for
Microsoft .NET Framework 4 are installed
after the other product or update installs and
a restart is pending

http://support.microsoft.com/kb/2473228

Thanks Glen, but that is behavior I would have
anticipated, which is why I am bench testing
this stuff even though I don't think we run anything
that uses any version of Framework anyway.

I'm more or less studying what options I have
when Microsoft stops creating new updates for
WinXP-Pro SP3 or perhaps even shuts off access
to the updates already created.

It'll be interesting to see if MS also stops creating
Microsoft Security Essentials definitions which
pertain to WinXP-Pro SP3.

Will Microsoft shut off WGA validation as well?


From: "Hot-Text" <[email protected]>
Date: Sun, 28 Oct 2012 00:04:05 -0500
Subject: Re: WinXP Pro Microsoft Security Essentials uninstall FAILS

HT > Mr. Greegor
HT > Why did you need to uninstall,
HT > Microsoft Security Essentials for...?

Necessary to upgrade Security Essentials
from 4.0.1526.0 to 4.1.522.0 or if a virus does
manage to get around that and shut off MSE.
Apparently an MSE definition caused MSE
to either be or appear to be non-functional
which triggered me to attempt an uninstall
which failed.
 
This morning on a machine that was clean installed
and had been fully updated (except for MSE defs)
for weeks reported 7 new updates, the big Wednesday
update drop, I imagine.

KB2761226, KB2727528 and KB890830 (Malicious SW removal tool)
all updated just fine, but

FOUR Framework updates failed, AGAIN!

KB2737019 to replace KB2656405 old FW 4 update 0x66A (version
conflict?)
KB2698023 to replace KB2656353 old FW 1.1 update 0x64C
KB2729450 to replace KB2633880 old FW 2.0 update 0x645
KB2729449 to replace KB2633870 old FW 4 update 0x66A

After discovering that all four were to replace OLD updates,
I tried to use add/remove programs facility to UNINSTALL them.
The first two are listed in the add/remove facility but FAIL to
uninstall.

The attempt to uninstall KB26656405 yields "Product does not apply".
The error seems non sequitur since UPDATE SITE apparently
thought that it did. I saw no version conflict.
Is MS UPDATE trying the 64 bit versions of these updates by mistake??

The attempt to uninstall KB2656353 yields "The feature you are trying
to use is on a network resource that is not available". While this
accursed error is VERY familiar to me, this time it doesn't point to
totally rediculous directory in it's search for the missing file.
It's looking toward a TEMP directory which is less insane than
previous experiences with this error message.

The other two OLD updates do not even appear
in the add/remove facility but they each appear
6 times in the registry.

I also tried uninstalling FW 2.0 SP2 which failed yielding the
"network resource that is not available" error.

Now, this is a clean install machine where none of the
uninstall files have been deleted!

Why do we bother keeping the huge pile of uninstall files
around if the f'n things aren't going to work??

I haven't gotten around to looking for downloadable
standalone versions of these updates, yet.

Is there a facility to recheck all updates/programs
for VALID uninstall information files?
 
Why is it necessary to have four versions plus SP's of the Microsoft
.Net Framework?   Does Microsoft need to hire better programers.  All
other programs only have one version.

They only do that on XP.

Newest systems get Framework 4.5 alone.

The next question is whether they made it backward compatible
with all of the early vrsions or if it's simply a collection of
all of the earlier versions kluged together in one big file.
For me it is nothing but a
problem keeping them updated and running. On my desktop I had to do a
complete reinstall because one version of .Net Framework never installed
properly.

I had good luck with a utility that ripped
out all trace of every version of Framework
and then start over installing Framework.
I may have to do that to solve the problem above.

The system I referred to above has MSI 3.1xxx on it and
I have resisted placing MSI 4.5 on it, because
I suspect that there is a version conflict between
two different MS Software Installers having to
do with failed uninstalls and therefore failed UPDATES
through their web site.

Oddly, I just checked and the same updates that
failed on the above system with a 3.1 installer are
already installed on the system with MSI 4.5.

Even more peculiar is that the 4 OLD updates aren't
fully gone from the system after their replacements
got installed. The OLD keys still show up 5 or 6
times each in the registry.

They're probably just disused registry keys but
imagine if EVERY tiny updated part of Windows
leaves behind such trash in the registry!

Many MS loyalists scoff derisively at registry cleaners
and lots of them are scams, but the demand is
there because of sloppy work at MS.

I set every option to show me hidden and system files
but still Windows file search won't show me all of
the msi.dll files on my operating windows drive.
If I search an identical CLONE of my system drive
on an upper partition search shows me 5 hits.
I don't mind that backups of 3.1 and 3.0 are still
on there when I have 4.0 installer installed.
Searching a CLONE image of the drive shows them.
How is Windows concealing those files from search
on the operating system drive?

Is there a way to force the search indexer to
see absolutely ALL of the system files?
 
Greegor said:
They only do that on XP.

Newest systems get Framework 4.5 alone.

The next question is whether they made it backward compatible
with all of the early vrsions or if it's simply a collection of
all of the earlier versions kluged together in one big file.


I had good luck with a utility that ripped
out all trace of every version of Framework
and then start over installing Framework.
I may have to do that to solve the problem above.

The system I referred to above has MSI 3.1xxx on it and
I have resisted placing MSI 4.5 on it, because
I suspect that there is a version conflict between
two different MS Software Installers having to
do with failed uninstalls and therefore failed UPDATES
through their web site.

Oddly, I just checked and the same updates that
failed on the above system with a 3.1 installer are
already installed on the system with MSI 4.5.

Even more peculiar is that the 4 OLD updates aren't
fully gone from the system after their replacements
got installed. The OLD keys still show up 5 or 6
times each in the registry.

They're probably just disused registry keys but
imagine if EVERY tiny updated part of Windows
leaves behind such trash in the registry!

Many MS loyalists scoff derisively at registry cleaners
and lots of them are scams, but the demand is
there because of sloppy work at MS.

I set every option to show me hidden and system files
but still Windows file search won't show me all of
the msi.dll files on my operating windows drive.
If I search an identical CLONE of my system drive
on an upper partition search shows me 5 hits.
I don't mind that backups of 3.1 and 3.0 are still
on there when I have 4.0 installer installed.
Searching a CLONE image of the drive shows them.
How is Windows concealing those files from search
on the operating system drive?

Is there a way to force the search indexer to
see absolutely ALL of the system files?


The errors you are seeing are due to some registry information being
missing, or some files that have been corrupted, from the original
installation of the .NET Framework.

No telling what caused the damage (the registry cleaners you use to
'fix' things can cause errors like this), but you need to use Aaron
Stebner's tool to remove all .NET Frameworks on XP, and then manually
download and install only what you need.

Why are you installing .NET Framework 4.x? Do you have software that
requires it? Don't install it if you don't need it.

If you need only .NET 2.x or 3.x, just download and install .NET FW 3.5
SP1... it includes the v.2.x runtime. Don't install .NET FW 1.x unless
you have older software that specifically insists on it only.
 
Back
Top