WinXP Pro Microsoft Security Essentials uninstall FAILS

[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?

[JJ]

Greegor <gree...@gmail.com> wrote:
> 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.

[JJ]

Greegor <gree...@gmail.com> wrote:
> 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?

[glee]

"Greegor" <gree...@gmail.com> wrote in message
news:ef7629fc-2255-4a41...@y8g2000yqy.googlegroups.com...

Go here: Uninstalling MSE -
http://answers.microsoft.com/en-us/protect/forum/mse-protect_start/uninstalling-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.
--
Glen Ventura
MS MVP Oct. 2002 - Sept. 2009
CompTIA A+

[Greegor]

On Oct 13, 11:27 am, JJ <jaejunks_at@_googlemail_dot._com> wrote:

> Greegor <greego...@gmail.com> wrote:
> > 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.

On Oct 13, 2:19 pm, "glee" <gle...@spamindspring.com> wrote:
> "Greegor" <greego...@gmail.com> wrote in message

> 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.
> --
> Glen Ventura
> MS MVP  Oct. 2002 - Sept. 2009

> CompTIA A+-

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...

[Greegor]

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.

[Greegor]

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

[glee]

"Greegor" <gree...@gmail.com> wrote in message

news:d784b096-9f5c-4d69...@b6g2000yqd.googlegroups.com...

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?

[Greegor]

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.

[glee]

"Greegor" <gree...@gmail.com> wrote in message

news:eb0ffa47-04c4-4250...@u17g2000yqk.googlegroups.com...

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

[Greegor]

On Oct 17, 4:12 pm, "glee" <gle...@spamindspring.com> wrote:
> "Greegor" <greego...@gmail.com> wrote in message

>
> news:eb0ffa47-04c4-4250...@u17g2000yqk.googlegroups.com...
>
>
>
>
>
> >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...

> 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.

[Greegor]

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?

[Greegor]

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]

MowGreen:

http://www.microsoft.com/security/portal/Definitions/WhatsNew.aspx?Version=1.137.1752.0&Release=Released&Package=AM

Definition change log The version you are searching for is invalid.
Please select a version from the drop down below.

According to the link you posted, the MSE definition
codes I posted are invalid, yet MS Update is
still pushing new definition code numbers
ascending at least hourly.

Fresh install using Windows SETUP.
MSE is first and only malware scanner.

[glee]

"Greegor" <gree...@gmail.com> wrote in message

news:1ab6d8b0-19dc-457d...@m4g2000yqf.googlegroups.com...

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/archive/2010/06/22/troubleshooting-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

--

[Hot-Text]

Mr. Greegor

Why did you need to uninstall,
Microsoft Security Essentials for...?

[Greegor]

http://blogs.msdn.com/b/varungupta/archive/2010/06/22/troubleshooting-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" <hot-t...@news.mixmin.net>
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.

[Hot-Text]

"Greegor" <gree...@gmail.com> wrote in message news:a0ec576e-b2c6-4535...@z2g2000yqj.googlegroups.com...

Uninstall .NET Framework 3.5
then install .NET Framework 4
then upgrade Security Essentials
;)



--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Greegor]

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?

[Greegor]

On Nov 14, 11:43 am, Keith Nuttle <Keith_Nut...@sbcglobal.net> wrote:

> 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?

[Richard]

What exactly is MS Framework used for???

[Greegor]

Today I tried downloading standalone installs of those updates.
One died looking for netfx.msi and file info said it used installer
2.0??
KB2729450 died saying "None of the products that are addressed by this
SW are installed." (When in fact Framework 2.0 SP2 is installed!)

On Nov 15, 9:01 am, Richard <cavel...@earthlink.net> wrote:
> What exactly is MS Framework used for???

http://en.wikipedia.org/wiki/.NET_Framework

The .NET Framework (pronounced dot net) is a software framework
developed by Microsoft that runs primarily on Microsoft Windows. It
includes a large library and provides language interoperability (each
language can use code written in other languages) across several
programming languages. Programs written for the .NET Framework execute
in a software environment (as contrasted to hardware environment),
known as the Common Language Runtime (CLR), an application virtual
machine that provides services such as security, memory management,
and exception handling. The class library and the CLR together
constitute the .NET Framework.

The .NET Framework's Base Class Library provides user interface, data
access, database connectivity, cryptography, web application
development, numeric algorithms, and network communications.
Programmers produce software by combining their own source code with
the .NET Framework and other libraries. The .NET Framework is intended
to be used by most new applications created for the Windows platform.
Microsoft also produces an integrated development environment largely
for .NET software called Visual Studio.

Contents [hide]
1 History
2 Design features
3 Architecture
3.1 Common Language Infrastructure (CLI)
3.2 Security
3.3 Class library
3.4 Memory management
4 Standardization and licensing
5 Criticism
6 References
7 External links


[edit] HistoryMain article: .NET Framework version history

The .NET Framework stack.Microsoft started development of the .NET
Framework in the late 1990s, originally under the name of Next
Generation Windows Services (NGWS). By late 2000 the first beta
versions of .NET 1.0 were released.[2]

Windows XP (including service packs) does not come with any version of
the .NET Framework installed.[3] Version 3.0 of the .NET Framework is
included with Windows Server 2008 and Windows Vista. Version 3.5 is
included with Windows 7, and can also be installed on Windows XP and
the Windows Server 2003 family of operating systems.[4] On 12 April
2010, .NET Framework 4 was released alongside Visual Studio 2010.

The .NET Framework family also includes two versions for mobile or
embedded device use. A reduced version of the framework, the .NET
Compact Framework, is available on Windows CE platforms, including
Windows Mobile devices such as smartphones. Additionally, the .NET
Micro Framework is targeted at severely resource-constrained devices.

Version Version number Release date Visual Studio Distributed with
1.0 1.0.3705.0 02002-02-1313 February 2002 Visual Studio .NET Windows
XP Tablet and Media Center Editions[5]
1.1 1.1.4322.573 02003-04-2424 April 2003 Visual Studio .NET 2003
Windows Server 2003
2.0 2.0.50727.42 02005-11-077 November 2005 Visual Studio 2005 Windows
Server 2003 R2
3.0 3.0.4506.30 02006-11-066 November 2006 Windows Vista, Windows
Server 2008
3.5 3.5.21022.8 02007-11-1919 November 2007 Visual Studio 2008 Windows
7, Windows Server 2008 R2
4.0 4.0.30319.1 02010-04-1212 April 2010 Visual Studio 2010
4.5 4.5.50709 02012-08-1515 August 2012 Visual Studio 2012 Windows 8,
Windows Server 2012

[edit] Design featuresInteroperability
Because computer systems commonly require interaction between newer
and older applications, the .NET Framework provides means to access
functionality implemented in newer and older programs that execute
outside the .NET environment. Access to COM components is provided in
the System.Runtime.InteropServices and System.EnterpriseServices
namespaces of the framework; access to other functionality is achieved
using the P/Invoke feature.
Common Language Runtime engine
The Common Language Runtime (CLR) serves as the execution engine of
the .NET Framework. All .NET programs execute under the supervision of
the CLR, guaranteeing certain properties and behaviors in the areas of
memory management, security, and exception handling.
Language independence
The .NET Framework introduces a Common Type System, or CTS. The CTS
specification defines all possible datatypes and programming
constructs supported by the CLR and how they may or may not interact
with each other conforming to the Common Language Infrastructure (CLI)
specification. Because of this feature, the .NET Framework supports
the exchange of types and object instances between libraries and
applications written using any conforming .NET language.
Base Class Library
The Base Class Library (BCL), part of the Framework Class Library
(FCL), is a library of functionality available to all languages using
the .NET Framework. The BCL provides classes that encapsulate a number
of common functions, including file reading and writing, graphic
rendering, database interaction, XML document manipulation, and so on.
It consists of classes, interfaces of reusable types that integrates
with CLR(Common Language Runtime).
Simplified deployment
The .NET Framework includes design features and tools which help
manage the installation of computer software to ensure it does not
interfere with previously installed software, and it conforms to
security requirements.
Security
The design addresses some of the vulnerabilities, such as buffer
overflows, which have been exploited by malicious software.
Additionally, .NET provides a common security model for all
applications.
Portability
While Microsoft has never implemented the full framework on any system
except Microsoft Windows, it has engineered the framework to be
platform-agnostic,[6] and cross-platform implementations are available
for other operating systems (see Silverlight and the Alternative
implementations section below). Microsoft submitted the specifications
for the Common Language Infrastructure (which includes the core class
libraries, Common Type System, and the Common Intermediate Language),
[7][8][9] the C# language,[10] and the C++/CLI language[11] to both
ECMA and the ISO, making them available as official standards. This
makes it possible for third parties to create compatible
implementations of the framework and its languages on other platforms.
[edit] Architecture
Visual overview of the Common Language Infrastructure (CLI)[edit]
Common Language Infrastructure (CLI)Main article: Common Language
Infrastructure
The purpose of the Common Language Infrastructure (CLI) is to provide
a language-neutral platform for application development and execution,
including functions for Exception handling, Garbage Collection,
security, and interoperability. By implementing the core aspects of
the .NET Framework within the scope of the CL, this functionality will
not be tied to a single language but will be available across the many
languages supported by the framework. Microsoft's implementation of
the CLI is called the Common Language Runtime, or CLR.

Main article: Assembly (CLI)
The CIL code is housed in CLI assemblies. As mandated by the
specification, assemblies are stored in the Portable Executable (PE)
format, common on the Windows platform for all DLL and EXE files. The
assembly consists of one or more files, one of which must contain the
manifest, which has the metadata for the assembly. The complete name
of an assembly (not to be confused with the filename on disk) contains
its simple text name, version number, culture, and public key token.
Assemblies are considered equivalent if they share the same complete
name, excluding the revision of the version number. A private key can
also be used by the creator of the assembly for strong naming. The
public key token identifies which public key an assembly is signed
with. Only the creator of the keypair (typically the .NET developer
signing the assembly) can sign assemblies that have the same strong
name as a previous version assembly, since he is in possession of the
private key. Strong naming is required to add assemblies to the Global
Assembly Cache

[edit] Security.NET has its own security mechanism with 2 general
features: Code Access Security (CAS), and validation and verification.
Code Access Security is based on evidence that is associated with a
specific assembly. Typically the evidence is the source of the
assembly (whether it is installed on the local machine or has been
downloaded from the intranet or Internet). Code Access Security uses
evidence to determine the permissions granted to the code. Other code
can demand that calling code is granted a specified permission. The
demand causes the CLR to perform a call stack walk: every assembly of
each method in the call stack is checked for the required permission;
if any assembly is not granted the permission a security exception is
thrown.

[edit] Class libraryNamespaces in the BCL[12]
System
System.
System. Diagnostics
System. Globalization
System
System. Resources
System. Text
System.Runtime.Serialization

See also: Base Class Library and Framework Class Library
The .NET Framework includes a set of standard class libraries. The
class library is organized in a hierarchy of namespaces. Most of the
built-in APIs are part of either System.* or Microsoft.* namespaces.
These class libraries implement a large number of common functions,
such as file reading and writing, graphic rendering, database
interaction, and XML document manipulation, among others. The .NET
class libraries are available to all CLI compliant languages. The .NET
Framework class library is divided into two parts: the Base Class
Library and the Framework Class Library

The Base Class Library (BCL) includes a small subset of the entire
class library and is the core set of classes that serve as the basic
API of the Common Language Runtime.[12] The classes in mscorlib.dll
and some of the classes in System.dll and System.core.dll are
considered to be a part of the BCL. The BCL classes are available in
both .NET Framework as well as its alternative implementations
including .NET Compact Framework, Microsoft Silverlight and Mono.

The Framework Class Library (FCL) is a superset of the BCL classes and
refers to the entire class library that ships with .NET Framework. It
includes an expanded set of libraries, including Windows Forms,
ADO.NET, ASP.NET, Language Integrated Query, Windows Presentation
Foundation, Windows Communication Foundation among others. The FCL is
much larger in scope than standard libraries for languages like C++,
and comparable in scope to the standard libraries of Java.

[edit] Memory managementThe .NET Framework CLR frees the developer
from the burden of managing memory (allocating and freeing up when
done); it handles memory management itself by detecting when memory
can be safely freed. Memory is allocated to instantiations of .NET
types (objects) from the managed heap, a pool of memory managed by the
CLR. As long as there exists a reference to an object, which might be
either a direct reference to an object or via a graph of objects, the
object is considered to be in use. When there is no reference to an
object, and it cannot be reached or used, it becomes garbage, eligible
for collection. NET Framework includes a garbage collector which runs
periodically, on a separate thread from the application's thread, that
enumerates all the unusable objects and reclaims the memory allocated
to them.

The .NET Garbage Collector (GC) is a non-deterministic, compacting,
mark-and-sweep garbage collector. The GC runs only when a certain
amount of memory has been used or there is enough pressure for memory
on the system. Since it is not guaranteed when the conditions to
reclaim memory are reached, the GC runs are non-deterministic.
Each .NET application has a set of roots, which are pointers to
objects on the managed heap (managed objects). These include
references to static objects and objects defined as local variables or
method parameters currently in scope, as well as objects referred to
by CPU registers.[13] When the GC runs, it pauses the application, and
for each object referred to in the root, it recursively enumerates all
the objects reachable from the root objects and marks them as
reachable. It uses CLI metadata and reflection to discover the objects
encapsulated by an object, and then recursively walk them. It then
enumerates all the objects on the heap (which were initially allocated
contiguously) using reflection. All objects not marked as reachable
are garbage.[13] This is the mark phase.[14] Since the memory held by
garbage is not of any consequence, it is considered free space.
However, this leaves chunks of free space between objects which were
initially contiguous. The objects are then compacted together to make
used memory contiguous again.[13][14] Any reference to an object
invalidated by moving the object is updated by the GC to reflect the
new location.[14] The application is resumed after the garbage
collection is over.

The GC used by .NET Framework is actually generational.[15] Objects
are assigned a generation; newly created objects belong to Generation
0. The objects that survive a garbage collection are tagged as
Generation 1, and the Generation 1 objects that survive another
collection are Generation 2 objects. The .NET Framework uses up to
Generation 2 objects.[15] Higher generation objects are garbage
collected less frequently than lower generation objects. This helps
increase the efficiency of garbage collection, as older objects tend
to have a longer lifetime than newer objects.[15] Thus, by removing
older (and thus more likely to survive a collection) objects from the
scope of a collection run, fewer objects need to be checked and
compacted.[15]

[edit] Standardization and licensingIn August 2000, Microsoft, Hewlett-
Packard, and Intel worked to standardize CLI and the C# programming
language. By December 2001, both were ratified ECMA standards (ECMA
335 and ECMA 334). ISO followed in April 2003 - the current version of
the ISO standards are ISO/IEC 23271:2012 and ISO/IEC 23270:2006.[16]
[17]

While Microsoft and their partners hold patents[citation needed] for
the CLI and C#, ECMA and ISO require that all patents essential to
implementation be made available under "reasonable and non-
discriminatory terms". In addition to meeting these terms, the
companies have agreed to make the patents available royalty-free.
[citation needed]

However, this does not apply for the part of the .NET Framework which
is not covered by the ECMA/ISO standard, which includes Windows Forms,
ADO.NET, and ASP.NET. Patents that Microsoft holds in these areas may
deter non-Microsoft implementations of the full framework.[18]

On 3 October 2007, Microsoft announced that much of the source code
for the .NET Framework Base Class Library (including ASP.NET, ADO.NET,
and Windows Presentation Foundation) was to have been made available
with the final release of Visual Studio 2008 towards the end of 2007
under the shared source Microsoft Reference License.[1] The source
code for other libraries including Windows Communication Foundation
(WCF), Windows Workflow Foundation (WF), and Language Integrated Query
(LINQ) were to be added in future releases. Being released under the
non-open source Microsoft Reference License means this source code is
made available for debugging purpose only, primarily to support
integrated debugging of the BCL in Visual Studio.

[edit] CriticismMore technical concerns and criticism relating to .NET
include:

The garbage-collector, which is integrated into the environment, can
introduce unanticipated delays of execution over which the developer
has little direct control, and it can cause runtime memory size to be
larger than expected. "In large applications, the number of objects
that the garbage collector needs to deal with can become very large,
which means it can take a very long time to visit and rearrange all of
them." [19]
Unobfuscated managed CIL bytecode can often be easier to reverse-
engineer than native code.[20][21] One concern is over possible loss
of trade secrets and the bypassing of license control mechanisms.
Since Visual Studio .NET (2002), Microsoft has included a tool to
obfuscate code (Dotfuscator Community Edition).[22]
Newer versions of the framework (3.5 and up) are not pre-installed in
versions of Windows below Windows 7 (although newer versions are
available via Windows Update). For this reason, applications must lead
users without the framework through a procedure to install it. Some
developers have expressed concerns about the large size of the .NET
Framework runtime installers for end-users. The size is around 54 MB
for .NET 3.0, 197 MB for .NET 3.5, and 250 MB for .NET 3.5 SP1 (while
using web installer the typical download for Windows XP is around 50
MB — for Windows Vista, 20 MB). The size issue is partially solved
with .NET 4 installer (x86 + x64) being 54 MB and not embedding full
runtime installation packages for previous versions. The .NET 3.5 SP1
full installation package includes the full runtime installation
packages for .NET 2.0 SP2 as well as .NET 3.0 SP2 for multiple
operating systems (Windows XP/Server 2003 and Windows Vista/Server
2008) and for multiple CPU architectures (x86, x86-64, and IA-64).
The first service pack for version 3.5 mitigates this concern by
offering a lighter-weight client-only subset of the .NET Framework.
Two significant limitations should be noted, though.[23] Firstly, the
client-only subset is only an option on an existing Windows XP SP2
system that currently has no other version of the .NET Framework
installed. In all other scenarios, the client-only installer will
install the full version of the .NET Framework 3.5 SP1. Secondly, the
client-only framework does not have a 64-bit option. However, the 4
release of the .NET Framework Client Profile will be available on all
operating systems and all architectures (excluding Itanium) supported
by the full .NET Framework.[24]
The .NET Framework currently does not provide support for calling
Streaming SIMD Extensions (SSE) via managed code. However, Mono has
provided support for SIMD Extensions as of version 2.2 within the
Mono.Simd namespace; Mono's lead developer Miguel de Icaza has
expressed hope that this SIMD support will be adopted by the CLR ECMA
standard.[25] Streaming SIMD Extensions have been available in x86
CPUs since the introduction of the Pentium III. Some other
architectures such as ARM and MIPS also have SIMD extensions. In case
the CPU lacks support for those extensions, the instructions are
simulated in software.
While the standards that make up .NET are inherently cross-platform,
Microsoft's full implementation of .NET is only supported on Windows.
The Microsoft .NET Framework is the predominant implementation of .NET
technologies. Other implementations for parts of the framework exist.
Although the runtime engine is described by an ECMA/ISO specification,
other implementations of it may be encumbered by patent issues; ISO
standards may include the disclaimer, "Attention is drawn to the
possibility that some of the elements of this document may be the
subject of patent rights. ISO shall not be held responsible for
identifying any or all such patent rights."[26] It is more difficult
to develop alternatives to the base class library (BCL), which is not
described by an open standard and may be subject to copyright
restrictions. Additionally, parts of the BCL have Windows-specific
functionality and behavior, so implementation on non-Windows platforms
can be problematic.

Some alternative implementations of parts of the framework are listed
here.

Microsoft's .NET Micro Framework is a .NET platform for extremely
resource-constrained devices. It includes a small version of the .NET
CLR and supports development in C# (though some developers were able
to use VB.NET,[27] albeit with an amount of hacking, and with limited
functionalities) and debugging (in an emulator or on hardware), both
using Microsoft Visual Studio. It also features a subset of the .NET
base class libraries (about 70 classes with about 420 methods), a GUI
framework loosely based on Windows Presentation Foundation, and
additional libraries specific to embedded applications.
Mono is an implementation of the CLI and the .NET Base Class Library
(BCL), and provides additional functionality. It is dual-licensed
under free software and proprietary software licenses. It includes
support for ASP.NET, ADO.NET, and Windows Forms libraries for a wide
range of architectures and operating systems. It also includes C# and
VB.NET compilers.
Portable.NET (part of DotGNU) provides an implementation of the Common
Language Infrastructure (CLI), portions of the .NET Base Class Library
(BCL), and a C# compiler. It supports a variety of CPUs and operating
systems.
Microsoft's Shared Source Common Language Infrastructure is a non-free
implementation of the CLR component of the .NET Framework. However,
the last version only runs on Microsoft Windows XP SP2, and was not
updated since 2006, therefore it does not contain all features of
version 2.0 of the .NET Framework.
CrossNet[28] is an implementation of the CLI and portions of the .NET
Base Class Library (BCL). It is free software using the open source
MIT License.
[edit] References1.^ a b Scott Guthrie (3 October 2007). "Releasing
the Source Code for the NET Framework". Archived from the original on
07 September 2010.
http://web.archive.org/web/20100907233621/http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx.
Retrieved 15 September 2010.
2.^ "Framework Versions". http://ben.skyiv.com/clrversion.html.
3.^ "Will the comming [sic] Windows XP SP3 include .Net framework 2.0
or higher?". http://social.msdn.microsoft.com/Forums/en-US/netfxsetup/thread/1b81b7c7-cc43-41a3-9893-ca401bf19ccd/.
4.^ Microsoft. "Microsoft .NET Framework 3.5 Administrator Deployment
Guide". http://msdn.microsoft.com/library/cc160717.aspx. Retrieved 26
June 2008.
5.^ ".NET Framework Service Pack 2".
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=75b0bc1d-c26c-4bac-ac68-2b4d431cabb5&displaylang=en.
Retrieved 4 May 2011. "Windows XP Tablet Edition and Windows XP Media
Center Edition already contain .NET Framework 1.0 Service Pack 2."
6.^ "Scott Guthrie: Silverlight and the Cross-Platform CLR". Channel
9. 30 April 2007. http://channel9.msdn.com/shows/Going+Deep/Scott-Guthrie-Silverlight-and-the-Cross-Platform-CLR.
7.^ "ECMA 335 - Standard ECMA-335 Common Language Infrastructure
(CLI)". ECMA. 1 June 2006. Archived from the original on 14 June 2008.
http://web.archive.org/web/20080614092650/http://www.ecma-international.org/publications/standards/Ecma-335.htm.
Retrieved 1 June 2008.
8.^ "ISO/IEC 23271:2006". Standards.iso.org. 2006-09-29.
http://standards.iso.org/ittf/PubliclyAvailableStandards/c042927_ISO_IEC_23271_2006(E)_Software.zip.
Retrieved 2012-04-17.
9.^ "Technical Report TR/84 Common Language Infrastructure (CLI) -
Information Derived from Partition IV XML File". ECMA. 1 June 2006.
http://www.ecma-international.org/publications/techreports/E-TR-084.htm.
10.^ "ECMA-334 C# Language Specification". ECMA. 1 June 2006.
http://www.ecma-international.org/publications/standards/Ecma-334.htm.
11.^ "Standard ECMA-372 C++/CLI Language Specification". ECMA. 1
December 2005. http://www.ecma-iointernational.org/publications/standards/Ecma-372.htm.
12.^ a b "Base Class Library". http://msdn.microsoft.com/netframework/aa569603.aspx.
Retrieved 1 June 2008.
13.^ a b c "Garbage Collection: Automatic Memory Management in the
Microsoft .NET Framework". Archived from the original on 3 July 2007.
http://web.archive.org/web/20070703083608/http://msdn.microsoft.com/msdnmag/issues/1100/GCI/.
Retrieved 1 June 2008.
14.^ a b c "Garbage collection in .NET". Archived from the original on
25 May 2008. http://web.archive.org/web/20080525165023/http://www.csharphelp.com/archives2/archive297.html.
Retrieved 1 June 2008.
15.^ a b c d "Garbage Collection—Part 2: Automatic Memory Management
in the Microsoft .NET Framework". Archived from the original on 26
June 2007. http://web.archive.org/web/20070626080134/http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/default.aspx.
Retrieved 1 June 2008.
16.^ "ISO/IEC 23271:2012 Information technology - Common Language
Infrastructure (CLI)". Iso.org. 2012-02-13.
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=58046.
Retrieved 2012-04-17.
17.^ "ISO/IEC 23270:2006 - Information technology - Programming
languages - C#". Iso.org. 2012-01-26.
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=42926.
Retrieved 2012-04-17.
18.^ "Microsoft's Empty Promise". Free Software Foundation. 16 July
2009. Archived from the original on 5 August 2009.
http://www.fsf.org/news/2009-07-mscp-mono. Retrieved 3 August 2009.
"However, there are several libraries that are included with Mono, and
commonly used by applications like Tomboy, that are not required by
the standard. And just to be clear, we're not talking about Windows-
specific libraries like ASP.NET and Windows Forms. Instead, we're
talking about libraries under the System namespace that provide common
functionality programmers expect in modern programming languages"
19.^ "Understanding Garbage Collection in .NET".
http://www.simple-talk.com/dotnet/.net-framework/understanding-garbage-collection-in-.net.
20.^ "Reverse Engineering Risk Assessment".
http://www.preemptive.com/images/documentation/Reverse_Engineering_Risk_Assessment.pdf.
21.^ Gartner, Inc. as reported in "Hype Cycle for Cyberthreats, 2006",
September 2006, Neil MacDonald; Amrit Williams, et al.
22.^ Dotfuscator Community Edition 4.0
23.^ "''.NET Framework Client Profile Deployment Scenarios''".
http://download.microsoft.com/download/5/a/a/5aa86d6c-969b-42d8-bc6b-30e02bfeccf0/NETFXClientProfile_DeploymentGuide.htm#_Toc205028507.
Retrieved 2012-04-17.
24.^ "'.NET Framework 4 Client Profile - Introduction'". Archived from
the original on 4 October 2009.
http://blogs.msdn.com/jgoldb/archive/2009/05/27/net-framework-4-client-profile-introduction.aspx.
Retrieved 2 October 2009.
25.^ "''Mono's SIMD Support: Making Mono safe for Gaming''".
Tirania.org. 2008-11-03. http://tirania.org/blog/archive/2008/Nov-03.html.
Retrieved 2012-04-17.
26.^ ISO 9001:2008, Foreword
27.^ "Using VB.NET with the .NET Micro Framework « /dev/mobile".
Christec.co.nz. 2008-04-01. http://www.christec.co.nz/blog/archives/317.
Retrieved 2012-04-17.
28.^ "CrossNet". Codeplex.com. http://www.codeplex.com/crossnet.
Retrieved 2012-04-17.
[edit] External links Wikibooks has a book on the topic of: .NET
Development Foundation
Wikiversity has learning materials about Introduction to
Microsoft.NET

.NET Framework Developer Center
.NET Framework 3.5 (MSDN)
.NET Framework 4.0 (MSDN)
.NET Framework 4.5 (Microsoft)
.NET Framework inheritance hierarchy chart

[glee]

"Greegor" <gree...@gmail.com> wrote in message

news:6fedde6b-1462-4434...@v9g2000yql.googlegroups.com...

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.

[Greegor]

> 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.

It's doing it on 2 of my working systems which DO have
clean installs and never once ran up regedit.

> 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.

I think I'll go one better and do a new install
without any Framework of any version. Ever.

> 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.

Building a clean master with all updates for my
little fleet of 5 identical off lease OEM computers.

[glee]

"Greegor" <gree...@gmail.com> wrote in message

news:d55a1497-2211-4586...@m4g2000pbd.googlegroups.com...

> Glen wrote:
>> 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.
>
>It's doing it on 2 of my working systems which DO have
>clean installs and never once ran up regedit.

Interesting.... nothing has been installed except an stock clean install
of the OS? Is an anti-virus installed at the time of the .NET
installation, and is it active at the time?

>> 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.
>
>I think I'll go one better and do a new install
>without any Framework of any version. Ever.
>
>> 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.
>
>Building a clean master with all updates for my
>little fleet of 5 identical off lease OEM computers.

But why are you installing .NET Framework if you have no software that
uses it? .NET Framework 4 is not pushed on Windows Update, it is an
optional update listed separately. I don't think any .NET flavor is
pushed any longer for XP on Windows Update if it isn't already present
due to some 3rd-party software. I'll have to look at my clean install
on another machine.

[Greegor]

On Dec 1, 2:40 pm, "glee" <gle...@spamindspring.com> wrote:
> "Greegor" <greego...@gmail.com> wrote in message

>
> news:d55a1497-2211-4586...@m4g2000pbd.googlegroups.com...
>
> > Glen wrote:
> >> 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.
>
> >It's doing it on 2 of my working systems which DO have
> >clean installs and never once ran up regedit.
>
> Interesting.... nothing has been installed except an stock clean install
> of the OS?  Is an anti-virus installed at the time of the .NET
> installation, and is it active at the time?

MSE installed and running in the order it was offered up
by the update site.

Update site does not say to turn off virus scanner.

Are problem with installers looking for necessary files in
crazy places with long random character names a
common symptom caused by a virus scanner operating?

It just doesn't seem like the kind of error I would
expect from collisions with an active virus scanner.

> >> 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.
>
> >I think I'll go one better and do a new install
> >without any Framework of any version.  Ever.
>
> >> 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.
>
> >Building a clean master with all updates for my
> >little fleet of 5 identical off lease OEM computers.
>
> But why are you installing .NET Framework if you have no software that
> uses it?  .NET Framework 4 is not pushed on Windows Update, it is an
> optional update listed separately.  I don't think any .NET flavor is
> pushed any longer for XP on Windows Update if it isn't already present
> due to some 3rd-party software.  I'll have to look at my clean install
> on another machine.

Just in case! But not any more.

[glee]

"Greegor" <gree...@gmail.com> wrote in message

news:d2a0554a-76b3-4103...@b4g2000pby.googlegroups.com...

>
>On Dec 1, 2:40 pm, "glee" <gle...@spamindspring.com> wrote:
>> "Greegor" <greego...@gmail.com> wrote in message
>>
>> news:d55a1497-2211-4586...@m4g2000pbd.googlegroups.com...
>>
>> > Glen wrote:
>> >> 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.
>>
>> >It's doing it on 2 of my working systems which DO have
>> >clean installs and never once ran up regedit.
>>
>> Interesting.... nothing has been installed except an stock clean
>> install
>> of the OS? Is an anti-virus installed at the time of the .NET
>> installation, and is it active at the time?
>
>MSE installed and running in the order it was offered up
>by the update site.

I assume you mean the updates were offerred... Windows Update doesn't
automatically offer MSE itself.

>Update site does not say to turn off virus scanner.

No, but it I always do when installing updates to .NET or Internet
Explorer, at the least. AV's vary.... Norton has a history of
interfering, as well as some others (ESET did for a while)... other AVs
don't cause any trouble most of the time.

>Are problem with installers looking for necessary files in
>crazy places with long random character names a
>common symptom caused by a virus scanner operating?

That 'symptom' is usually the uninstaller looking for the original
temporary folder that was used (or recorded as used) during the original
installation. Often those folders are deleted by the installer at the
end of the installation, or by the user during maintenance.

>It just doesn't seem like the kind of error I would
>expect from collisions with an active virus scanner.

No, probably not. It could be a defect in the installer, but if it was,
one would expect to see the issue everywhere, and it is actually not
that common.


> snip

>> But why are you installing .NET Framework if you have no software
>> that
>> uses it? .NET Framework 4 is not pushed on Windows Update, it is an
>> optional update listed separately. I don't think any .NET flavor is
>> pushed any longer for XP on Windows Update if it isn't already
>> present
>> due to some 3rd-party software. I'll have to look at my clean install
>> on another machine.
>
>Just in case! But not any more.

There's no good reason to install any .NET version if you don't have
software asking for it during installation, in order to run the
software.

[Greegor]

That seems to be exactly what is going wrong.
How could a virus scanner like MSE possibly
cause this sort of malfunction?

How could it cause the record of where crucial
code or overlays are, to refer to the WRONG
directory?

I will try to test for this effect, maybe next week.

> >It just doesn't seem like the kind of error I would
> >expect from collisions with an active virus scanner.
>
> No, probably not.  It could be a defect in the installer, but if it was,
> one would expect to see the issue everywhere, and it is actually not
> that common.

> > snip
> >> But why are you installing .NET Framework if you have no software
> >> that
> >> uses it? .NET Framework 4 is not pushed on Windows Update, it is an
> >> optional update listed separately. I don't think any .NET flavor is
> >> pushed any longer for XP on Windows Update if it isn't already
> >> present
> >> due to some 3rd-party software. I'll have to look at my clean install
> >> on another machine.
>
> >Just in case!   But not any more.
>
> There's no good reason to install any .NET version if you don't have
> software asking for it during installation, in order to run the
> software.

I certainly won't.

[glee]

"Greegor" <gree...@gmail.com> wrote in message

news:af9ba75b-2913-4806...@6g2000pbh.googlegroups.com...

I didn't state that an A-V, in your case MSE, would necessarily cause
it. As I stated in my reply, it could be a defect in the installer,
though one would then expect to see the issue everywhere, and it isn't
that common. That said, if an A-V is interfering with an installation,
corruption of the installation could occur in a number of places....
files not copied, or corrupted Registry entries, and so forth.
.NET updates have long been a problem, searching for the myriad causes
of the problems isn't worth the time to me.... it just seems to fragile
for prime time. I look for alternate software that doesn't use .NET
wherever possible. Vista, Win7 and 8 all have some versions built in
now.