Windows 7 - How to determine programs that require .net on XP?

Asked By aeroloose
08-Jan-12 12:20 PM
I have all versions of .net on my machine.  Reading other
posts, it occurred to me to consider trimming or removing
.net.  But, I may have existing programs that require it,
and I may not know they do :)  Any suggestions on ways to
audit my PC for programs that use .net (and which version of
.net)?

Aero
Microsoft .NET Framework
(1)
Windows XP
(1)
Visual Studio 2005
(1)
Windows Media
(1)
Visual Studio
(1)
Microsoft Office Microsoft Silverlight
(1)
Silverlight
(1)
Office
(1)
  Jo-Anne replied to aeroloose
08-Jan-12 01:33 PM
I do not know the answer, Aero, but I can tell you that after having lots of
trouble with .NET Framework updates, I uninstalled it--and found out that my
Dell computer would not start properly without it. Every time I booted the
computer, I got an error message about SecureUpgrade that I had to click out
of. I also could not use Filehippo, a program that checks for updates to
programs installed on the computer. I finally broke down, cleaned out all
the old .NET Framework files (with lots of help from Microsoft Support), and
reinstalled the latest version and all its updates.

Jo-Anne
  Mayayana replied to aeroloose
08-Jan-12 02:15 PM
| Any suggestions on ways to
| audit my PC for programs that use .net (and which version of
| .net)?
|
There may not be any simple way to check,
other than trying them or posting a list here to
get feedback from others.

Since the runtime is so big, most software authors
will not be anxious to tell you that their software requires
.Net. A couple of times I have downloaded something that
tried to go online and install the .Net Framework without
even asking permission. Microsoft encourages that
behavior. (There was a time when all software downloads
would list the download size and the requirements. In many
cases now they no longer list either.)

There could be issues with some printers or other
hardware. If you have something like that requiring .Net
you might have difficulty removing it, though you may
still only need v. 2. Other than that I do not know of
many Windows programs that use .Net. The two that
Jo-anne mentioned seem to be some kind of DRM
http://www.wave.com/products/esc.asp
and a shareware program that looks for software updates.
Generally, small shareware is the most likely to require
.Net. The code is relatively slow; the dependencies are
gigantic; and since it is not actually compiled software, .Net
programs can be decompiled. Those are all qualities that
commercial software authors try to avoid.

The basic library that all .Net programs need, as far as
I know, is mscoree.dll. If you try to run .Net software with
no .Net you probably will not see an informative error message.
You'll just get a message that "mscoree.dll is missing". That's
the giveaway. You might be able to test by temporarily
renaming mscoree.dll and then running your software, but if
you have System File Protection enabled it might not let you
do that.

There is a very useful program named depends.exe that you
can use to find out what libraries a program needs:

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

The website for download seems to be currently down. I
have several SDKs and found that depends.exe is included
*at least* in the Win2003 Server DDK. So you should be able
to get depends.exe or its equivalent one way or another.

Depends lists libraries and which functions are being used
from those libraries. It does not always manage to find all
dependencies for all EXEs, but it should something like
mscoree.dll.

Java is a similar problem to .Net. Most software does not
need it, but occasionally some website functionality might
need it. OpenOffice needs Java for something or other...
I do not know what.... but I was able to find a Java-free
OO installer that is worked fine for me.
  Bert replied to Mayayana
08-Jan-12 07:23 PM
They'd be foolish not to tell you, since their product is worthless
without it.

--
bert@iphouse.com	St. Paul, MN
  Mayayana replied to Bert
08-Jan-12 02:52 PM
| > Since the runtime is so big, most software authors
| > will not be anxious to tell you that their software requires
| > .Net.
|
| They'd be foolish not to tell you, since their product is worthless
| without it.
|

Did you read down in my post? it is not unusual
for the installer to sneak online and download the
Framework with nothing more than a brief message
flying by during the install process. So you end up
saddled with 1/2 GB for what you thought was a
small trinket program, but most people "will not know
what hit them", so that approach is actually a
clever strategy. If they were honest they'd show a
message saying, "This software will take up as much
room as 1/2 of your total operating system. Do you
still want to proceed?" But that would not win many
converts.
  Paul replied to aeroloose
08-Jan-12 03:19 PM
Best answer so far, was this.

http://www.devfish.net/articles/clrver/article_CLRVer.htm

http://www.devfish.net/downloads.aspx

http://www.devfish.net/.%5Cdownloads%5Cfiles%5Cclrver.zip

Scans clean (not a guarantee it is not malware)...

http://www.virustotal.com/file-scan/report.html?id=a6a831edfdbb8c5856b706d9d997550241fab6fea39353c77f097c7acf258dce-1326052342

*******

Now, if I unzip the file, and pull out CLRver\bin\Release\CLRver.exe
that seems to be all that is needed. I can then, test the program on itself
(as the program also requires dotnet to work).

In a command prompt window, while cd'ed to the directory holding that
single extracted file, I tried

clrver clrver.exe

and the answer was

clrver.exe=v2.0.50727

I would then consult a table of CLR version versus dotnet
release, to figure out what version of dotnet would have
to stay in place. In my case, it is probably .net 2.0 , as
that is all I am likely to have installed.

*******

On the dotnet side of things, Stebners blog has a few tools.

https://skydrive.live.com/?cid=27e6a35d1a492af7&id=27E6A35D1A492AF7!376

it is possibly "netfx_setupverifier_new" that includes a tool
with dialog, which will list the dotnet layers installed,
and allow them to be tested. That's to allow a user to verify
their version of dotnet installation, is working. It might
also be used to point out, what library versions remain installed.

Once you have removed all your dotnet, I presume a tool like
that would throw a wobbly :-) I would expect most tools
used for dotnet, would have their own dotnet dependency
(which is why I did my "clrver clrver.exe" test case, to
demonstrate that).

Have fun (playing whack-a-mole) :-)

Paul
  000-111-000 replied to aeroloose
09-Jan-12 11:47 PM
If not broking,
do not Fix it...

For old software needs Old .NET,
like the old Games software you have,
New Software like XP Sp3 and up,
need new .NET to run!

--
User-agent: *
Disallow: /
  Mayayana replied to 000-111-000
10-Jan-12 09:12 AM
|
| For old software needs Old .NET,
| like the old Games software you have,
| New Software like XP Sp3 and up,
| need new .NET to run!
|

It does not work that way. There is no .Net needed
by XP SP3. .Net has no direct connection to Windows.
(Though some framework comes pre-installed on Vista/7,
so it is possible that Microsoft has installed a .Net applet
or two on Vista/7.)

When .Net came out there was v. 1 and 1.1.
.Net v. 2, which is already 10 years old now, eventually
became the standard version because later versions
are very big and therefore difficult to distribute. So a lot
of .Net software written now is .Net v. 2. Some is v. 3 or
later.
  Ken Blake, MVP replied to 000-111-000
10-Jan-12 01:42 PM
Sorry, but that is not at all correct. Neither Windows XP (SP3 or not)
nor any other version of Windows needs .net.

The .net framework (note its full correct name) is needed by some
*application* programs (again, not operating systems). And what
version of the .net framework the application program needs depends on
what version of .net it was written with.

--
Ken Blake, Microsoft MVP (Windows Desktop Experience) since 2003
Please Reply to the Newsgroup
  Paul replied to Paul
10-Jan-12 02:43 PM
I tried writing some scripts, to scan my hard drive to see what versions
of dotnet were used by the programs on there.

Occasionally, I was seeing an error like this from CLRver.exe .

R6034 "attempt to load the C runtime library incorrectly"
http://img853.imageshack.us/img853/1742/dotnetruntimeerror.gif

So in fact I could not make the script run to completion, without
having to dismiss about 21 of those dialog boxes.

It seems to involve 64 bit executables which happen to be sitting
in install folders here and there. Almost like, attempting to
analyze a 64 bit executable on a 32 bit OS, is some how compromised.

The CLR (common language runtime) version printed out by CLRver,
can be decoded with this table.

http://en.wikipedia.org/wiki/List_of_.NET_Framework_versions

This is what my script recorded.

V2.0.50727 occurred 156 times
-2 occurred 21 times"

and the -2 corresponds to each instance of error R6034.

So it looks like my old Windows Media Encoder package depends on
dotnet version 1.0. While most of the other junk on my hard drive,
is looking for dotnet version 2.0 . Some of the files captured,
are part of the dotnet installation itself, which means you have to
go through the list of detected files, to find files actually
in the Program Files folder structure.

Paul
  Char Jackson replied to Paul
10-Jan-12 04:33 PM
Regarding your last point, could not you just point the script at the
Program Files tree and have it walk through that tree to completion?
  Bill in Co replied to 000-111-000
10-Jan-12 04:35 PM
Come again?


Eng 099 still recommended, Hot Text.    :-)
  Paul replied to Char Jackson
10-Jan-12 05:17 PM
I could, but as a first effort, I wanted to scan everything to
check for "surprises" or things I had not thought about. Executable
code is thrown all over the place. For example, my 10GB C:\Xilinx
folder, is not in Program Files as it should be. When a project
gets too big for its own good, it tends to end up in its own
little world.

Paul
  aeroloose replied to Paul
10-Jan-12 08:57 PM
I appreciate the info, but yikes!  Quite a bit more
complicated than I was hoping for :)  I did hear somewhere
that Process Explorer might also be a way to get the
answers, but I think it still boils down to checking each
program individually.  Not sure the effort is worth the
cost, at this point.  Perhaps another poster has a simpler
way ...
  Char Jackson replied to Paul
10-Jan-12 09:13 PM
Understood, thanks. I have been known to do the same thing.
  Tester replied to aeroloose
10-Jan-12 09:14 PM
There is no other way to determine this except to rename the folder that
contains .Net files and then trying to run each and every program one by
one.  If the program does not find the .Net files, it will complain and
you will know that program requires .Net files.

Now if you have 1,000 programs then just take one week off from work and
try this method during that week.

Good luck.
  Paul replied to aeroloose
10-Jan-12 10:16 PM
One reason I did not go into the details, is the method is not refined
enough for duplication.

After looking at the results of my little experiment, it still looks
like a custom bit of code would do the job best. A script is not going
to do it. For one thing, the method I was using was too slow - it took
about 1 hour 50 minutes, to scan C: :-) There is got to be a better way...

Paul
  Paul replied to Tester
10-Jan-12 10:23 PM
Actually, some .net programs do not complain intelligently.

All you see is a complaint about "mscoree.dll". And from that,
using your all-powerful intuition, you are supposed to figure out
what is missing.

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

Paul
  Mayayana replied to Paul
11-Jan-12 12:24 AM
| One reason I did not go into the details, is the method is not refined
| enough for duplication.
|

It looks like the gist of what you want is this:

http://it.toolbox.com/blogs/coding-dotnet/net-portable-executable-file-11836

http://www.simple-talk.com/community/blogs/simonc/archive/2011/03/16/100839.aspx


they describe a CLR header near the start of a PE file.
If one had the details of that header it would be simple
to write something like a VBScript that goes through
a list of installed software (the Registry App Paths keys)
and reads the beginning of each executable to see
whether it is .Net, and what version it is. In a few minutes
of searching, though. I did not come across a clear mapping
of the header and its location in a PE file.
  Paul replied to Mayayana
11-Jan-12 12:44 AM
I have seen enough variations, while scanning my C: drive, to
not attempt to write my own C: code. I am not finding the
magic string value "BSJB" in all the files I have looked at.
And the offset of that string, varies a bit. it is not static.
The format seems variable, calling for parsing according
to some recipe. On some files this program identifies as
.net, I am not finding BSJB anywhere in there. This program
uses hints inside a file, rather than the file extension,
to identify things. it is a port from Unix/Linux world.

http://gnuwin32.sourceforge.net/packages/file.htm

The thing is, I am not confident if I used a hacker approach
to this, my coverage would extend to 100% (i.e. using a hex
editor and making my own recipe). I'd likely get it wrong,
unless I use the docs for parsing PE and Net assemblies.
I may not have enough code samples here, to get all the
variations right.

As far as distributing solutions to others, giving out binaries
is not a very good idea (the trust problem). Giving out source,
then nobody knows how to compile it. (I use DJGPP for some
things here. Don't have any Microsoft tools installed.) If I use
a scripting language, then it is possible for others to follow
along, using the same downloads I am using. But so far, my
results are not good enough.

I have a copy of "ildasm" here, but I have not been able to get
the questionable files through ildasm for a look.

Paul
  000-111-000 replied to Bill in Co
11-Jan-12 09:08 AM
In good working older

You maybe right


it is people like Ken Blake, Microsoft MVP,
Why Microsoft do not do NNTP,
News Groups no more,



--
User-agent: *
Disallow: /
  Mayayana replied to Paul
11-Jan-12 09:26 AM
| The thing is, I am not confident if I used a hacker approach
| to this, my coverage would extend to 100% (i.e. using a hex
| editor and making my own recipe). I'd likely get it wrong,
| unless I use the docs for parsing PE and Net assemblies.
| I may not have enough code samples here, to get all the
| variations right.
|

Also, one cannot always depend on online information.
The articles I was seeing last night seemed to be from
people who half-understood PE structure and only knew
rumors of .Net addititions to the PE format.

The PE file format is dependable, but it is not all at
predictable offsets. There are a lot of pointers used:
4 bytes at offset XYZ might tell you the offset of the
4 bytes that tells you the offset of the beginning of the
table you are looking for.... That kind of thing. And in some
cases offsets are listed for the loaded image in memory
rather than as file offsets.

Documentation of PE format is out there, but one
would also need dependable information about how
the CLR Header is set up. In the pages I saw there
was not even agreement about what the header is
called.  ... I began to see myself digging in for 2 days
on a project that I have no personal interest in... and
that very few people are ever likely to use. Vista/7
has .Net pre-installed, and most people have no
interest in, or even concept of, a clean system. So
the audience would be tech-sophisticated XP users
who do not typically install the sort of fluff shareware
that is likely to be .Net. (Jo-anne wanted to keep .Net
so that she could have FileHippo!) ...Who want their
PC lean... and who also do not allow Microsoft to pile on
updates willy nilly. Sounds like a small group.

I myself do not even have access to a PC with .Net
software on it.
  000-111-000 replied to Ken Blake, MVP
11-Jan-12 09:24 AM
You not a good Professional when it came to Microsoft...

So you do not run Microsoft Office,
on a XP... Do you ....
.net framework 1,2 and 3 is need by Windows XP operating systems,
to run, Microsoft Office, Microsoft Silverlight, and Visual Studio..

If the .net framework is on a [OP] operating systems,
it need by his XP, to run his Microsoft Windows XP Softwares,

If it is not On you operating systems it not needed,
if it on your operating systems do not F**k.
with it, [if it working in good Order].....

Sorry, to correct you!

--
User-agent: *
Disallow: /
  000-111-000 replied to Mayayana
11-Jan-12 09:42 AM
So it a For Microsoft Office,
v. 1 is for old VS6,
v. 2 is for old VS7,8

do I need to go on..............

--
User-agent: *
Disallow: /
  Mayayana replied to 000-111-000
11-Jan-12 10:26 AM
| So it a For Microsoft Office,
| v. 1 is for old VS6,
| v. 2 is for old VS7,8
|
| do I need to go on..............
|

Suit yourself. I cannot make any sense out of
what you are saying.

| it is people like Ken Blake, Microsoft MVP,
| Why Microsoft do not do NNTP,
| News Groups no more,

There is no need to make it personal. Microsoft
does not do newsgroups anymore because they
cannot control it. They switched to web forums
staffed by MS employees, where people get "medals"
for giving approved answers -- like small children in
a classroom being awarded cute animal stickers in
exchange for good behavior.

If you look at the list of web forums you will see that
MS did not just move to forums. They actually
restructured the whole thing in order to create a
marketing venue and block open discussion
where criticism or unapproved ideas might crop up.

Microsoft is trying to gradually move away from the
scenario where they provide a platform for use by
programmers, and move into something more like
what Apple does: Provide a product that is tightly
controlled, with limited, controlled access by only
a few programmers who will play along with Microsoft's
commercial plans and give them a cut of software proceeds.
(Metro apps for Windows 8 are sandboxed trinket software,
like phone apps, from which MS takes a 30% cut of sales.)

One part of that transition was to take control of the
discussion between programmers, corporate administrators,
etc.
  Ken Blake, MVP replied to 000-111-000
11-Jan-12 10:53 AM
Microsoft Office, Microsoft Silverlight, and Visual Studio are
*application* programs. They are *not* part of Windows XP.


--
Ken Blake, Microsoft MVP (Windows Desktop Experience) since 2003
Please Reply to the Newsgroup
  000-222-000 replied to Ken Blake, MVP
12-Jan-12 10:02 AM
Look if a OP put the *application* on his Windows XP,
it become part of his Windows XP..

Maybe not you XP but His............................


--
User-agent: *
Disallow: /
  000-222-000 replied to aeroloose
12-Jan-12 10:16 AM
Mr. aeroloose

if you are running

Microsoft Windows XP
Media Center Edition

it have to have all the .NET
the run right!

For know one here ask you,
the Software you are running,
and that do not seen care!


--
User-agent: *
Disallow: /
  Ken Blake, MVP replied to 000-222-000
12-Jan-12 11:05 AM
So you apparently have no idea what the words "application" and

Or are you just trying to excuse your obvious error by misusing the
terms?

--
Ken Blake, Microsoft MVP (Windows Desktop Experience) since 2003
Please Reply to the Newsgroup
  Mayayana replied to Paul
12-Jan-12 03:22 PM
Curiosity got the better of me and I ended up writing
a VBScript to test for .Net. For anyone who is curious,
it is here:

http://www.jsware.net/jsware/test/dotnetv.zip

Drop any file onto the script and if it is .Net the version
required will be reported. I have tested a number of files
and this script seems to be dependable. It parses the
PE file header directly, thus not requiring .Net or any
other software. (As is typical, the script was not so hard
to write, but finding accurate information was difficult.)

I will package it up into an HTA, so that people who want
to scan their systems can just enter a path and have all
EXEs, DLLs on that path checked.
  Paul replied to Mayayana
12-Jan-12 06:25 PM
I altered my script, to call "ildasm.exe", an official MS tool
from one of their SDKs.

After my test run, the ildasm.exe threw five runtime errors
(versus the twenty using CLRver.exe off the 'net). So
the damn script would not run, without dismissing error
dialogs on the screen. I am going to work on that in a bit.

Using CLRver, my scan got

V2.0.50727 occurred 156 times
-2 occurred 21 times"

Using ildasm, the latest scan got

'v4.0.30319' Version String occurred 2 times
'v2.0.50727' Version String occurred 215 times
'v1.0.3705' Version String occurred 13 times

so it would appear the CLRver approach of loading the assembly,
will also fail when a program has a version of dotnet, which
is not installed on the machine. Apparently I have two programs
which call for .net 4.0 and I do not have that version installed.
ildasm is capable of reading that out, without throwing a wobbly.

it is also a bit puzzling, how the MS tools got 215 of the .net 2.0
executables, while the CLRver got 156. That might correspond to
x64 executables that would not load in CLRver (on my x32 OS).

In all cases, the ildasm program detected

Metadata Header Storage Signature: 0x424a5342

which is hex for "BSJB" (only backwards due to endianness).
So that appears to be a pretty consistent theme. The gnuwin32
and there was no BSJB string present. The ildasm never seemed
to log anything that did not have that present.

This is the ildasm output blob which I used for logging the strings.
There did not seem to be variation in this, and only the Version
String line is the one that changes from instance to instance.

// Metadata Header
//    Storage Signature:
//              0x424a5342 Signature
//                  0x0001 Major Version
//                  0x0001 Minor Version
//              0x00000000 Extra Data Offset
//              0x0000000c Version String Length
//              'v2.0.50727' Version String
//    Storage Header:

The "Version String Length" was still 0c or decimal 12, even for
the short string v1.0.3705. It almost seems like a "max length" of
some sort.

Anyway, good fun for a "something to do" kinda project.

Paul
  Mayayana replied to Paul
12-Jan-12 08:40 PM
|
| so it would appear the CLRver approach of loading the assembly,
| will also fail when a program has a version of dotnet, which
| is not installed on the machine.

Interesting point. it is typical of .Net that one has to
build a Rube Goldberg automated shovel to scoop a
spoonful of ice cream. Loading the runtime just to parse
file headers is not ideal, even if it did work well.


| In all cases, the ildasm program detected
|
|    Metadata Header Storage Signature: 0x424a5342
|

Yes. it is all documented. There is a CLR Header, AKA
CLI Header, which has a pointer to the metadata, which
starts with BSJB. Once one knows the system it is very
dependable because the header has to be set up correctly
to work. But it is hard to find this kind of info. and it is
tricky dealing with offsets and pointers because most of
them are meant to be applied to a file loaded into memory.

|         // Metadata Header
|         //    Storage Signature:
|         //              0x424a5342 Signature
|         //                  0x0001 Major Version
|         //                  0x0001 Minor Version
|         //              0x00000000 Extra Data Offset
|         //              0x0000000c Version String Length
|         //              'v2.0.50727' Version String
|         //    Storage Header:
|
| The "Version String Length" was still 0c or decimal 12, even for
| the short string v1.0.3705. It almost seems like a "max length" of
| some sort.

it is padded to a 4-byte multiple. it is not important,
anyway. The string starts at offset 16 (17th byte) in
the metadata and goes until one hits a null. So there is
no need to have the string length.

I am curious about one thing: If you or anyone else reading
this has a chance to try my script on win64 I'd be interested
to know the results. I do not have easy access to a 64-bit
system, and it is hard to prevent Explorer crashing on XP32
if I let it "look" at a 64-bit file.
  Paul replied to Mayayana
12-Jan-12 09:55 PM
I may get around to running yours eventually.

Right now, I have extracted a file from the "paint.net" package
(PaintDotNet.Native.x64.dll), which appears to be 64 bit native
(is reported as PE32+) and yet it does not have BSJB in the file.
I tested on the 64 bit laptop, and it fails on ildasm and clrver
programs. And yet the gnuwin32 "file" program, says the
file is dotnet. And I have no reason to suspect it is not,
as paint.net is a "poster child" for dotnet usage.

I am still very much at the "mysteries" stage here.

Right now, I am off, to shovel snow...

Paul
  Mayayana replied to Paul
12-Jan-12 10:45 PM
|
| I may get around to running yours eventually.
|
| Right now, I have extracted a file from the "paint.net" package
| (PaintDotNet.Native.x64.dll), which appears to be 64 bit native
| (is reported as PE32+) and yet it does not have BSJB in the file.

I tried downloading Paint.Net as a test sample,
and I unpacked the installer. But I do not think
anything in there is actually the program. It seems
to be a "oneclick" installer package, designed to
go online and download the real program.

| I tested on the 64 bit laptop, and it fails on ildasm and clrver
| programs. And yet the gnuwin32 "file" program, says the
| file is dotnet.

I downloaded the gnuwin32 source but it is a lot more
code than I want to deal with on a wild goose chase.
You do not need any of that stuff. it is all explained in
the comments of my code. (You do not have to trust me.
it is a VBScript. The code is plain text.) If you prefer to
research it yourself you can find a lot at these links:

http://www.simple-talk.com/community/blogs/simonc/archive/2011/03/15/100802.aspx
http://www.thehackerslibrary.com/?p=377
http://www.vijaymukhi.com/documents/books/metadata/chap1.htm
  000-222-000 replied to Ken Blake, MVP
13-Jan-12 08:45 AM
If you are in the process of uninstalling / re-installing Malwarebytes - it
should be assumed that *any* registry values (and / or keys) that
specifically contain the name "Malwarebytes" ,  "MBAM" or the path to the
Malwarebytes software's location on the hard-drive, can always be safely
deleted.

However, this is also assuming that you are given to caution when editing
the registry and that you would double-check that which you are about to
delete (as regedit has no "Undo" function)!!

If you want to know more about backing-up the NT registry (NT / 2K / XP /
Vista / W7) you could do worse than download the following [freeware]
program, that, together with reading it is accompanying documentation, will
give you an insight on how to backup / restore the registry in differing
scenarios.

Download the [free] program ERUNT [772 KB] :
http://www.aumha.org/downloads/erunt-setup.exe

==

Cheers,    Tim Meddick,    Peckham, London.    :-)

P.S.  Rather than multi-post you should direct your news-mail to more than
one group in the "Newsgroups" or "Send to" field (cross-post).
  Char Jackson replied to 000-222-000
13-Jan-12 10:37 AM
If you are in the process of uninstalling / re-installing Malwarebytes - it
should be assumed that *any* registry values (and / or keys) that
specifically contain the name "Malwarebytes" ,  "MBAM" or the path to the
Malwarebytes software's location on the hard-drive, can always be safely
deleted.

However, this is also assuming that you are given to caution when editing
the registry and that you would double-check that which you are about to
delete (as regedit has no "Undo" function)!!

If you want to know more about backing-up the NT registry (NT / 2K / XP /
Vista / W7) you could do worse than download the following [freeware]
program, that, together with reading it is accompanying documentation, will
give you an insight on how to backup / restore the registry in differing
scenarios.

Download the [free] program ERUNT [772 KB] :
http://www.aumha.org/downloads/erunt-setup.exe

==

Cheers,    Tim Meddick,    Peckham, London.    :-)

P.S.  Rather than multi-post you should direct your news-mail to more than
one group in the "Newsgroups" or "Send to" field (cross-post).
  Mayayana replied to aeroloose
13-Jan-12 11:18 AM
--




Hi,



During the summer I had a problem installing Net.Framework update
(KB2539631) It would install but then show up again as not being installed.
I contacted Microsoft



http://support.microsoft.com/select/?target=assistance . (This service was
free.)



and a tech got back to me in a day. The response is below. What he had me do
was uninstall Net.Framework completely then reinstall Net.Framework 3.5 and
its service pack. From then on the updates and security patches have been
installing OK. If other remedies do not seem to work it may be worth a shot
at this recipe.





Response from MS Tech:





From your description, I understand that the update KB2539631 cannot be
installed. It can be found in Add or Remove Programs. If I have
misunderstood your concern, please do not hesitate to let me know.



I understand the inconvenience you have experienced. Please be assured that
I will do my best to help you.



This issue can be caused by a damaged .NET Framework component. Based on its
current status, I suggest trying the following troubleshooting steps.



Step 1: Remove .NET Framework using removal tool

================================

1. Please download the tool from the following link:

http://cid-27e6a35d1a492af7.skydrive.live.com/self.aspx/Blog_Tools/dotnetfx_cleanup_tool.zip



2. Please save the zip file (dotnetfx_cleanup_tool.zip) from the above link
to the local Desktop and extract it.

3. Double click cleanup_tool.exe to run the tool.

4. Please follow the instructions given.

In the "Product to cleanup:" box, please select ".NET Framework - All
versions".

5. Click "Cleanup Now" button.



Note: Once we removed .NET Framework, some application which needs .NET
Framework runtime database could lost its function. It is just a temporary
issue. The function will be back after reinstalling .NET Framework.



After removing .NET Framework components, let us reinstall .NET Framework 3.5
Service Pack 1 and its update.



Step 2: Manually downloading and installing Microsoft .NET Framework 3.5

=======================================================

Please note: The size of Microsoft .NET Framework 3.5 and .NET Framework 3.5
Service Pack 1 is a little big. Your patience to download the update is much
appreciated.



1. Click the following link:



Microsoft .NET Framework 3.5 and .NET Framework 3.5 Service Pack 1

http://download.microsoft.com/download/2/0/E/20E90413-712F-438C-988E-FDAA79A8AC3D/dotnetfx35.exe



2. When the file download window appears, please click "Save", and follow
the directions to save it on the Desktop. After downloading the Microsoft
.NET Framework 3.5 setup file on your Desktop, double-click to manually
install it.







Jan Alter
bearpuf@verizon.net
  000-222-000 replied to Char Jackson
13-Jan-12 04:26 PM
Yes Jan Alter this is 100% right a good Info.
;)



--
User-agent: *
Disallow: /
  Char Jackson replied to 000-222-000
13-Jan-12 04:39 PM
Thank Microsoft and try Bing Translate... and it not in  English,
but old U.S.A language...

--
User-agent: *
Disallow: /
  000-222-000 replied to Char Jackson
13-Jan-12 05:00 PM
I give up. I guess we cannot communicate. No common language.
  000-222-000 replied to aeroloose
13-Jan-12 05:26 PM
You need too,
for there is no Translator,
for old U.S.A language..
But English will get you 85%,
of the Translation,
with no understanding,
of the meaning thereof.

But you all,
will not be able,
to put a foot,
in to the meaning,
of language,
that is in USA English,
Dam Translate.
;0

Vous devez aussi,
Il n'y a aucun traducteur,
pour les vieux U.S.A langue...
Mais l'anglais vous obtiendrez 85 %,
de la traduction,
sans aucune compr?hension,
le sens celui-ci.


Mais vous tous,
ne sera pas en mesure du faire,
pour mettre un pied,
dans le sens,
de la langue,
C'est en anglais USA,
Barrage de traduire.


--
User-agent: *
Disallow: /
  Mayayana replied to 000-222-000
13-Jan-12 09:17 PM
Comment:  instead of special backup software I recommend
simply copying to another drive (so that any software can later
read or copy it.)   Proprietorial backup software was invented
when hard drive space was scarce and expense, which is no
longer true:  and there is no compatibility between one company's
special backup software and anyone else's.

--
Don Phillipson
Carlsbad Springs
(Ottawa Canada)
  aeroloose replied to Mayayana
13-Jan-12 09:50 PM
Some video card drivers come with "WHQL Certified" on the download page.
I can find both uncertified and certified drivers on the Nvidia site
for example. it is unclear what convinces them to certify some and not others.

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

Paul
  aeroloose replied to aeroloose
14-Jan-12 02:31 PM
I ran it, with interesting results.  I have 8 programs that
use it (not counting the v2 and v3 Frameworks themselves).
I did not expect to see Firefox and Thunderbird show up, but
they did.  The others were Silverlight, PDF995, Filehippo
Updater, Wireshark, SyncToy and Installshield (the only v1
reference).

I did have problems running the HTA script.  I tried the
finally ground to a halt.  After killing and restarting, I
tried with "c:\program files."  I still had lots of
click-throughs, but it finally completed.  I do not know if
this is a function of the age of my machine, IE7, or
something else.

Thanks for the reco.
  BillW50 replied to aeroloose
14-Jan-12 02:59 PM
I too had similar results.

--
Bill
Gateway M465e ('06 era) - Thunderbird v3.0
Centrino Core Duo T2400 1.83GHz - 2GB - Windows XP SP3
  Mayayana replied to aeroloose
14-Jan-12 04:00 PM
| I did not expect to see Firefox and Thunderbird show up, but
| they did.  The others were Silverlight, PDF995, Filehippo
| Updater, Wireshark, SyncToy and Installshield (the only v1
| reference).

I am surprised about FF and TB, too. Maybe there are some
kind of plugins? I have FF3.6 with no .Net. And since FF is
OSS it is hard to imagine anything inherent to the browser
that requires .Net. Silverlight, Filehippo and SyncToy are
not surprising. Installshield is something I also have. There are
.Net files, but it does not need .Net. IS just stores a lot of
junk on any PC where IS installers have been run.

|
| I did have problems running the HTA script.

Does the readme.txt file have a version number near the
top?   v.  1.13.12.2
I made a slight tweak. That's the latest version. The first
version was based on some faulty info. It will work fine and
will find the vast majority of .Net files, but I discovered
that it will not find some MS files that have an unusual format.


|  I tried the
| "c:\windows" path first, but after clicking through many
| "Program is slowing. Stop this script?" error messages, it
| finally ground to a halt.

Ahhh. That's a pain in the neck. See here:

http://www.jsware.net/jsware/scripts.php5#ie7prob

The download there is a small script that changes a setting
to stop that behavior. IE asks whether you want to keep
letting a long script run, but then it does not listen to your
answer. It just asks over and over!

Thanks for the feedback. I will release this to the public
but these kinds of things are hard to test extensively
by myself. (Maybe I will also include a copy of the script
to fix the IE nags. I did not think of that, but I think a lot
of people run into that problem, and the solution is obscure.)
  BillW50 replied to Mayayana
14-Jan-12 04:07 PM
I seem to recall during at least one Firefox update (I skipped that one)
that dotnet was automatically installed. There was a huge outcry in the
Mozilla community about Microsoft forcing it on them. But I do not think
it was all Microsoft doing. As I think Mozilla was somewhat responsible.

--
Bill
Gateway M465e ('06 era) - Thunderbird v3.0
Centrino Core Duo T2400 1.83GHz - 2GB - Windows XP SP3
  aeroloose replied to Mayayana
14-Jan-12 04:28 PM
For FF9 and TB9, it is the same file, in the root folder of
both programs: msvcm80.dll.  DAGS shows linkage to MS Visual
Studio 2005.  TB does not seem to have plug-ins, and I do not
have a common add-on between the two programs.  Perhaps it is
a Mozilla inclusion, not specific to FF or TB?


Yes, that is the version in the readme.


I will try that.  However, I wonder if it will still eventually
lock-up; I just will not see the script nags?


YW :)
  Paul replied to aeroloose
14-Jan-12 05:16 PM
Could you use DependencyWalker to check what is going on ?

I do not know, when a DLL is stamped with .NET, whether that
guarantees it has to load all that stuff when accessed. I have
some software here, that only includes a subset of the msv**90
stuff, so maybe the file is not used ? Perhaps if you use
DependencyWalker, the information will be there.

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

to know every run-time dependency without disassembling or
executing the program."

If the program itself loads dotnet, then you would  likely see a reference
to mscoree. But if some DLL is doing that, I do not know if the same
would (eventually) show up somewhere in the dependency tree.

I am still trying to find a file that I know for absolutely sure,
is x64 and .NET, to try as a test case. I tried Mayayana's script
for a quick check, but I am still looking for enough code samples to
make some good tests. I backed up my x64 laptop, installed paint.net, but the
executable there was PE32 and not PE32+, so will not make a good test
case for me. And in Googling to see if anyone made a set of test
executables, I was not able to convince the search engine to find
something relevant along those lines.

Paul
  Mayayana replied to aeroloose
14-Jan-12 05:40 PM
| For FF9 and TB9, it is the same file, in the root folder of
| both programs: msvcm80.dll.  DAGS shows linkage to MS Visual
| Studio 2005.

Interesting. That's the VC++ 8 managed runtime.
There is another one called mfcm80.dll. I think those are
both installed with the VC8 runtime, as one of several
files, in case anyone wants to write C++-CLI software.
(I do not think anyone actually does. Writing managed
C++ defeats the purpose.)

In other words, it means that they installed the VC++8
runtime, which is not surprising as most people writing
C++ software on Windows use Visual Studio, and VS
software always requires a runtime. As long as no other
.Net files are in the program it does not use .Net. I will have
to add a note about that to the utility.

| > Ahhh. That's a pain in the neck. See here:
| >
| > http://www.jsware.net/jsware/scripts.php5#ie7prob
| >
| > The download there is a small script that changes a setting
| > to stop that behavior. IE asks whether you want to keep
| > letting a long script run, but then it does not listen to your
| > answer. It just asks over and over!
|
| I will try that.  However, I wonder if it will still eventually
| lock-up; I just will not see the script nags?
|

No, it is just that it takes awhile to process so many files,
and IE has a default time limit. In other words, it is not
locked up. it is just busy. I have had that problem in the past
with HTA scripts that do extensive operations. That's how
I know about the Registry setting. If IE did lock up you
could use Task Manager to kill it, but in this case it is just
that IE normally expects scripts that run for a fraction of
a second, so it just assumes there is a problem. That's not
so bad. But then Microsoft messed up by programming it
so that IE ignores your response to the message window.
So a slightly helpful feature is instead a hair-pulling bug.

I am glad you asked about all this. Now that I have written the
utility I can see it being very useful when cleaning up other
people's machines -- as a quick way to see whether .Net can
be removed.

I just uploaded another update. it is not really significant,
but it did recognize an oddball file in Open Office 3 (even
though OO does not need .Net) that the last version did not
pick up.

Technical explanation, for anyone who is curious:

I wrote the original version on the basis of information I'd
found that the .Net header in a PE file starts 8 bytes into
the .text section. It turned out that was wrong. Apparently
.Net software written in Visual Studio is like that, so 95+ %
of .Net files will be like that, but I later found a couple of MS
files that have the table later in the .text section. Then I
decided that maybe I should not even assume the .Net header
is in the .text section at all. And wouldn'cha know it....
Turns out the OO people wrote such a file. :)
It may be the only such file in existence for all I know, but
the latest version of the utility was worth doing just in case.
it is more "robust", as the geeks like to say. Now, if it finds
.Net header info. in a file, it makes no assumptions about
where in the file that header will be located.
  Mayayana replied to BillW50
14-Jan-12 05:42 PM
| I seem to recall during at least one Firefox update (I skipped that one)
| that dotnet was automatically installed.

See my resonse below. it is just a file that is included
with the VC++8 runtime, but is unlikely to be used by
anything. (If FF actually needed .Net there would be
.Net DLLs as part of FF itself.)
  BillW50 replied to Mayayana
14-Jan-12 06:16 PM
I am still very fuzzy about what the deal was. But some of it came back
a bit afterwords. And that was if you had some versions of Firefox and
did an automatic Windows update, it added some Firefox add-on that I
thought (maybe incorrectly) had something to do with dotnet.

I did a quick Google search and this might have been what I am thinking
of and it has nothing to do with dotnet like I first thought. But still
noteworthy nonetheless.

Microsoft hides mystery Firefox extension in toolbar update
http://arstechnica.com/microsoft/news/2010/06/microsoft-slips-ie-firefox-add-on-into-toolbar-update.ars

--
Bill
Gateway M465e ('06 era) - Thunderbird v3.0
Centrino Core Duo T2400 1.83GHz - 2GB - Windows XP SP3
  aeroloose replied to aeroloose
15-Jan-12 11:49 AM
FYI.  I cannot get to your links above via IE.  Ironic, yes?
The browser I need to run the file, will not let me fetch it
cannot download ...  IE was not able to open the site.  The
requested site is either unavailable or cannot be found.
Please try again later."  When I switch to FF, it works
fine.  I tried this several times during the day, with same
results.

Thought you should know.  it is probably my settings, but
this message is unfamiliar.
  Mayayana replied to aeroloose
15-Jan-12 05:07 PM
| FYI.  I cannot get to your links above via IE.  Ironic, yes?
|  The browser I need to run the file, will not let me fetch it
| :(.  I get the following (abridged) error message:  "IE
| cannot download ...  IE was not able to open the site.  The
| requested site is either unavailable or cannot be found.
| Please try again later."  When I switch to FF, it works
| fine.  I tried this several times during the day, with same
| results.
|
| Thought you should know.  it is probably my settings, but
| this message is unfamiliar.

Thanks. I do not think I have ever seen such a message either.
It does not sound like a DNS issue, since it is not a 404 error.
Rather, it sounds like IE is not getting a response from the
server. I do not know how that could happen for one browser
and not another.

I wonder if it might be IE security, trying to open an index
page at the URL rather than directly accepting binaries. That
does not really make sense, either, but it is the only explanation
I can think of. (The test\ folder has no pages. Just a few
ZIP files.)
  000-222-000 replied to aeroloose
15-Jan-12 07:47 PM
Downloading
For most of the software here you can just download the "EXE" installer file and double-click it to install the software.

Download Difficulties?
. Problems Specific to Internet Explorer  - If you use Internet Explorer you might see a warning that the download may not be
more explanation and ways to stop being nagged by spurious IE "security" warnings.)

In some cases when using Internet Explorer, your download may even be blocked "for your safety". That behavior can be adjusted
if you want to keep using IE. (See link above.) We recommend that you just switch to using the Firefox or Opera browser instead.
Fixing the increasing nags, restrictions and security problems with Internet Explorer is not an easy endeavor. It requires that you
familiarize yourself with the convoluted IE security settings and that you adjust undocumented Registry settings.


--
User-agent: *
Disallow: /
  Motor T replied to Mayayana
15-Jan-12 11:01 PM
I clicked the link this morning. Opened in my default browser (Opera)
but got a'invalid image' message of some sort. This message
disappeared immediately however, and the 'download to:' window opened.
The script downloaded fine. I extracted and simply hit the
DotNetChecker.hta app. and it ran fine. Don't know how or why it
worked this way and I do not care. All I know is it worked just fine.
Thanks for doing this.
--
--
Ed Mc
Nam Vet  '66-'67
Semper Fi
  Mayayana replied to Mayayana
15-Jan-12 11:23 PM
I found this:

Tools menu-> Internet Options-> Advanced tab
Go to the Security section all the way at the bottom.
Clear the check on the "Do not save encrypted pages to disk"

Apparently in some cases if a link to a binary is put
into the IE address bar (rather than coming from an
in-page link) it is treated as an encrypted webpage?
If so, that is got to be about the most misleading
error message I have ever seen!
  aeroloose replied to Mayayana
16-Jan-12 10:47 AM
Drat!  Mine was already unchecked.  I think you are on to
something, but I do not know where to look next.
  aeroloose replied to 000-222-000
16-Jan-12 10:53 AM
Thanks, but I did not see these message types.  it is more of
the "cannot find it" problem, not the "it is not safe" problem.
  Mayayana replied to Paul
16-Jan-12 06:00 PM
| I am still trying to find a file that I know for absolutely sure,
| is x64 and .NET, to try as a test case.

I have not been able to test this yet, but I did find one
thing different: The 64-bit Directory Table is different.
The 1st 2 bytes of the optional header indicate a 32
or 64 bit PE file. For 64-bit there are some small differences,
with the result that while the .Net header is 208 bytes
into the optional header for 32-bit, it is a 224 byte offset
for 64-bit files. There does not appear to be any difference
in the actual header itself, but I am not certain about that. If
the directory table offset is the only issue it will be very
easy to accomodate both file types.
  Mayayana replied to Mayayana
21-Jan-12 12:11 PM
Just posting the final URL for the DotNet Checker
utility, for people who may find this thread via
search:

http://www.jsware.net/jsware/scripts.php5#peops

(The original link was for a test version. That link
is no longer valid.)
Create New Account
help
trying to install Security Update for Windows XP (KB890859) in conjunction with Security Update for Microsoft .NET Framework, Version 1.1 Service Pack 1 (KB928366), my update history says that SP1 was installed 1 2007-10-08 13:51:56:609 1028 91c Agent * Title = Security Update for Microsoft .NET Framework, Version 1.1 Service Pack 1 (KB928366) 2007-10-08 13:51:56:609 1028 install these updates on Tuesday, October 09, 2007 at 3:00 AM: - Security Update for Microsoft .NET Framework, Version 1.1 Service Pack 1 (KB928366) 2007-10-08 13:52:11:640
FBAResetSetup 0:09:00 AM - [FBASetProgressText] Installing Components. . . 0:09:00 AM - [FBALaunch] C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ regtlibv12.exe C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ Microsoft.JScript.tlb (ExitCode: 0x0) 0:09:00 AM - [FBALaunch] C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ regtlibv12.exe C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ Microsoft
for you as it did for me. This also resolved an issue with installing the Microsoft .Net Framework 3.5 and Visual Studio 2008 Beta 2 (Orcas) with the following error messages. .Net Framework v3.5 nstall - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - [date] Microsoft .NET Framework 2.0SP1 (CBS): [2] Error: Installation failed for component Microsoft .NET Framework 2.0SP1 (CBS). MSI returned error code 1 [date] Microsoft .NET Framework 2.0SP1
2.0 are listed. I was able to install VS 2005 before without problem. Description: Microsoft .NET Framework 3.5 has encountered a problem during setup. Setup did not complete correctly. Problem signature microsoft.com / fwlink / ?linkid = 50163&clcid = 0x0409 Error log: [05 / 27 / 08, 11:07:33] Microsoft .NET Framework 2.0SP1 (CBS): [2] Error: Installation failed for component Microsoft .NET Framework 2.0SP1 (CBS). MSI returned error code 34 [05 / 27 / 08, 11:07:45
Security Update for Windows Vista (KB974571) - Security Update for the 2007 Microsoft Office System (KB974234) - Microsoft .NET Framework 1.1 Service Pack 1 Security Update for Windows 2000, Windows XP, Windows Vista, Windows Failure Content Install Installation Failure: Windows failed to install the following update with error 0x80070643: Microsoft .NET Framework 1.1 Service Pack 1 Security Update for Windows 2000, Windows XP, Windows Vista, Windows 822A781D07CC} 100 0 AutomaticUpdates Success Content Install Installation Successful: Windows successfully installed the following update: Microsoft .NET Framework 3.5 Family Update (KB959209) x86 2010-05-07 14:20:23:175 1300