Microsoft Antispyware folder not completely uninstalled

[Guest]

Looks like a minor problem. During installation of Windows Defender,
Microsoft Antispyware gets uninstalled. However the "Microsoft Antispyware"
folder in Program Files is only partially emptied of contents. The folder is
there and numerous *.gcd files are still there including gcUserData.gcd. As
far as I can tell so far, it isn't causing a problem.

I had a previous dialogue with Bill Sanderson about a similar situation with
reintalling MS AS where reinstalling MS AS while the old gcUserData.gcd was
already present. It kept you from being able to save settings after
reinstalling. I don't thing that is happening now, but seeing the old
problem still occurring makes me wonder of there could be some scenario where
the old data file could get in the way.

 

[Robert Williams]

Looks like a minor problem. During installation of Windows Defender,
Microsoft Antispyware gets uninstalled. However the "Microsoft Antispyware"
folder in Program Files is only partially emptied of contents. The folder is
there and numerous *.gcd files are still there including gcUserData.gcd. As
far as I can tell so far, it isn't causing a problem.

When in the history of Windows has a folder been completely emptied and deleted
when a program is uninstalled? Same goes for the registry. This I believe is
one of MS's downfalls. And if you think about it, it *really* isn't that big a
deal. I just don't like spending half the day looking through and documenting
links for items that have been left behind when I remove a program. Maybe once
they get all their higher priorities taken care of they will work on this too.

[snip]

 

[Bill Sanderson]

I've noticed that the folder is left behind. I don't know what the
rationale is--perhaps enough is left behind to enable removals from
quarantine or something like that--or, perhaps, it's as Robert Williams
supposes.

 

[Guest]

Tons of registry entries left behind by AntiSPyware - named gcasdtserv.exe

 

[Robert Williams]

I've got my AS in Computer Programming (not much, I know) but whenever I write a
program, I search the registry for all instances of the program and add the
deletion keys to my program's uninstall method. Sure it takes time, but in the
end, it's worth it (and the customers are happier)

I personally believe that most companies don't care about how their program is
uninstalled, because they figure the user isn't going to be using their product
anymore anyways. So they don't worry about removing everything, just the visible
stuff (and not even all of that sometimes).

One test I will perform prior to purchasing any online software is the uninstall
test. If the program doesn't at least uninstall everything in the directory,
and any main links in the registry, I won't buy it. There are plenty more
vendors out there that make better (or at least similar) products.
Unfortunately, in this case, we are talking about a Microsoft product.

So, what do you do? Let them know how you feel about the product. I've filled
out many of those online Survey's that MS has on their site, but I have yet to
see one that asks about uninstallation.

 

[Bill Sanderson]

Have you ever considered that there may be reasons other than sloppiness for
leaving such details behind? I don't have any particular insight into the
thought processes of the developers, but some that I can imagine: 1) some
details are migrated in the course of the upgrade--it's true that this might
be accomplished without leaving the details behind, but perhaps that is a
part of the reason. 2) It may well be that enough pieces are left behind to
allow for the removal of quarantined items, if any. I don't know anything
about the limitations of installer logic, but perhaps it is too much to
expect an actual check for whether such items exist and or dialogs asking
the user whether they wish to leave the data in place or not.

As I say--I likely know far less than you do about such things--the last
programming I did was in Cobol a good many years ago--but there are
alternative explanations for the data left behind I suspect. To say nothing
of course, for the question about whether, in fact, performance is
measurably impacted by registry entries such as thouse you mention--I don't
think I've ever seen data proving that registry cleaners and the like really
provide significant benefit to the average user--have you?

--

 

[Robert Williams]

Have you ever considered that there may be reasons other than sloppiness for
leaving such details behind? I don't have any particular insight into the
thought processes of the developers, but some that I can imagine:

Sure, it's possible there are other reasons. One of the *main* reasons is to
make sure that users don't install trial versions of software, uninstall, and
reinstall, repeatedly, to keep using the trial version (which can be
accomplished with the use of a few synonymous keys. But for the most part, the
stuff I have encountered is just pure sloppiness.

1) some
details are migrated in the course of the upgrade--it's true that this might
be accomplished without leaving the details behind, but perhaps that is a
part of the reason.

I don't know about everyone else, but when I uninstall a program it's to
completely uninstall it. If I want to upgrade, I'll upgrade. But yes, it could
very well be part of the reason, however, migration settings tend to be in .ini
files in the program's folder (which can be copied to an alternate location, or
left alone, if migration is intended)

2) It may well be that enough pieces are left behind to
allow for the removal of quarantined items, if any. I don't know anything
about the limitations of installer logic, but perhaps it is too much to
expect an actual check for whether such items exist and or dialogs asking
the user whether they wish to leave the data in place or not.

I've always just thought it better to be safe than sorry. If I know a key or
value has been directly added to the registry by my program, then I like to make
sure I remove it. Adding and removing keys is a simple API call that can be set
into a function. From there you just pass the variables to them.

As I say--I likely know far less than you do about such things--the last
programming I did was in Cobol a good many years ago--but there are
alternative explanations for the data left behind I suspect. To say nothing
of course, for the question about whether, in fact, performance is
measurably impacted by registry entries such as thouse you mention--I don't
think I've ever seen data proving that registry cleaners and the like really
provide significant benefit to the average user--have you?

Give Registry First Aid a try. I can see a big difference in performance when I
run a monthly to quarterly cleaning.

http://www.rosecitysoftware.com/programs/RegFA/

http://www.rosecitysoftware.com/reg1aid/

 

[Bill Sanderson]

Give Registry First Aid a try. I can see a big difference in performance
when I
run a monthly to quarterly cleaning.

http://www.rosecitysoftware.com/programs/RegFA/

http://www.rosecitysoftware.com/reg1aid/

I'll consider that--I know that registry cleaners are quite popular, but I'm
statled that you find that a monthly run gives a noticeable performance
change. But maybe, as a developer, your registry gets a very different
usage pattern than the average user?