Author Topic: Clean-Up Tool for Comodo Internet Security (OLD)  (Read 430917 times)

Offline Alan Borer

  • Comodo's Hero
  • *****
  • Posts: 528
Re: Clean-Up Tool for Comodo Internet Security (OLD)
« Reply #45 on: February 18, 2010, 06:52:53 AM »
Hi

There are many Google results for "Registrar Lite", but the un-crippled version 2.00 is vastly outnumbered.
By greatly restricting the advanced search parameters I had a vastly improved set of results.
Many results were downloads from sites I had not heard off, and I decided not to link to a potential malware site - then I saw MajorGeeks which I recognise and trust.

The link I gave worked on Tuesday - but not today.
In case it was restricted to members, I logged in and tried again - still nothing.

I quick search on their site gave me this :-
http://forums.majorgeeks.com/showthread.php?t=190345
I strongly recommend it.
They have experts who can guide you better than I upon the use of registry editors.
This thread has guidance by an expert on owning the registry.

Look at the first reply on that thread, it includes a link to  Registrar Lite  at
http://downloads.bjgarrick.com/files/RegistrarLite.zip
I remember something like BigArrick as one of the Google results I knew nothing about,
but if it is good enough for MajorGeeks it is good enough for this little geek.

I have just clicked on the link and it redirected to bjgarrick and gave me
RegistrarLite.zip   Size 1.97 MB (2,075,934 bytes)
That should sort out the registry.

Eric
Reboot is not required for taking control and deleting the key.
I now know more than I ever wanted to know about the registry,
but I think it is sufficient to know that sometimes a reboot is needed.
e.g.  If an application is tweaked by hacking a registry key,
that application may continue to operate according the the value in the registry at start-up,
and will only behave consistently in the new fashion after a reboot.

My application of my knowledge and fears of the registry when un-installing Comodo :-
1.  Physically disconnect from the Internet ;
2.  Cancel Comodo's self protection - which I believe is now in Defense+ / My protected Files / Groups ;
3.  Disable AntiVirus, Firewall, and Defense+ ;
4.  Reboot to ensure everyone is singing from the same Registry songsheet ;
At this stage "cmdGuard.sys" and all the other Comodo drivers etc. should be free of permissions issues,
just in-case the Comodo un-install procedure forgets to exterminate any ;
5.  Use Revouninstaller to launch Comodo's Un-install and to do the follow-up clean-up ;
6.  Upon completion and reboot, to run my clean-up script ;
7.  Fix any residual permission issues that have been identified ;
8.  Reboot ;
9.  Good to Go - System should now be wide open for installing Comodo upgrade.

I am over cautious, but a few redundant reboots is a small price to pay for a clean upgrade.
It cost me many hours of work trying to upgrade from Comodo Firewall 2.4.
For many weeks I started each morning by restoring a disc image with a working Comodo 2.4,
and then scoured the Internet looking for solutions,
and then another afternoon trying to apply the solutions.

I am now confident that CACLS and Registrar Lite 2.00 will immediately solve an future permissions issues,
but I am still haunted by the version 2.4 disaster years ago that left 2000 frozen registry keys.

Regards
Alan

Offline Maverik

  • Newbie
  • *
  • Posts: 12
Re: Clean-Up Tool for Comodo Internet Security (OLD)
« Reply #46 on: February 18, 2010, 05:48:36 PM »
Thanks Alan, most apreciated.
I see that possibly I missed one step of yours. I'm talking of n. 2 "Cancel COMODO's self protection"; at the moment I don't remember ... is there a button or similar to do this? (I have to reinstall CIS to see this LOL).

Anyway thanks for the link and your patience.

Regards
Riki

Offline Alan Borer

  • Comodo's Hero
  • *****
  • Posts: 528
Re: Clean-Up Tool for Comodo Internet Security (OLD)
« Reply #47 on: February 19, 2010, 06:54:41 AM »
I vaguely remember that before there was Defense+ there used to be some sort of button or link on one of the Comodo Firewall Tabs that would enable or disable protection.  This would have been version 2.4, and possibly also early version of 3.?

I can no longer see any such control.

But there appears to be protection control independently for 6 different Comodo Files and Folders via
Defense+ / My protected Files / Groups.
Also Defense+ / Advanced / Defense+ Settings / General Settings  has a check box for
"Deactivate Defense+ permanently (requires restart).

Alan

Offline Maverik

  • Newbie
  • *
  • Posts: 12
Re: Clean-Up Tool for Comodo Internet Security (OLD)
« Reply #48 on: February 19, 2010, 04:50:58 PM »
Hallo Alan and thanks for your reply.

at point 6 of your list what do you think it will happen if your clean-up is launched BEFORE rebooting?
I am tempted to do this ...

Please let me know.
Regards

Riki

Hi

There are many Google results for "Registrar Lite", but the un-crippled version 2.00 is vastly outnumbered.
By greatly restricting the advanced search parameters I had a vastly improved set of results.
Many results were downloads from sites I had not heard off, and I decided not to link to a potential malware site - then I saw MajorGeeks which I recognise and trust.

The link I gave worked on Tuesday - but not today.
In case it was restricted to members, I logged in and tried again - still nothing.

I quick search on their site gave me this :-
http://forums.majorgeeks.com/showthread.php?t=190345
I strongly recommend it.
They have experts who can guide you better than I upon the use of registry editors.
This thread has guidance by an expert on owning the registry.

Look at the first reply on that thread, it includes a link to  Registrar Lite  at
http://downloads.bjgarrick.com/files/RegistrarLite.zip
I remember something like BigArrick as one of the Google results I knew nothing about,
but if it is good enough for MajorGeeks it is good enough for this little geek.

I have just clicked on the link and it redirected to bjgarrick and gave me
RegistrarLite.zip   Size 1.97 MB (2,075,934 bytes)
That should sort out the registry.

Eric
Reboot is not required for taking control and deleting the key.
I now know more than I ever wanted to know about the registry,
but I think it is sufficient to know that sometimes a reboot is needed.
e.g.  If an application is tweaked by hacking a registry key,
that application may continue to operate according the the value in the registry at start-up,
and will only behave consistently in the new fashion after a reboot.

My application of my knowledge and fears of the registry when un-installing Comodo :-
1.  Physically disconnect from the Internet ;
2.  Cancel Comodo's self protection - which I believe is now in Defense+ / My protected Files / Groups ;
3.  Disable AntiVirus, Firewall, and Defense+ ;
4.  Reboot to ensure everyone is singing from the same Registry songsheet ;
At this stage "cmdGuard.sys" and all the other Comodo drivers etc. should be free of permissions issues,
just in-case the Comodo un-install procedure forgets to exterminate any ;
5.  Use Revouninstaller to launch Comodo's Un-install and to do the follow-up clean-up ;
6.  Upon completion and reboot, to run my clean-up script ;
7.  Fix any residual permission issues that have been identified ;
8.  Reboot ;
9.  Good to Go - System should now be wide open for installing Comodo upgrade.

I am over cautious, but a few redundant reboots is a small price to pay for a clean upgrade.
It cost me many hours of work trying to upgrade from Comodo Firewall 2.4.
For many weeks I started each morning by restoring a disc image with a working Comodo 2.4,
and then scoured the Internet looking for solutions,
and then another afternoon trying to apply the solutions.

I am now confident that CACLS and Registrar Lite 2.00 will immediately solve an future permissions issues,
but I am still haunted by the version 2.4 disaster years ago that left 2000 frozen registry keys.

Regards
Alan


Offline Alan Borer

  • Comodo's Hero
  • *****
  • Posts: 528
Re: Clean-Up Tool for Comodo Internet Security (OLD)
« Reply #49 on: February 19, 2010, 06:19:00 PM »
When Comodo un-installs it does not consider the job completed until you have rebooted.
If you fail to reboot before running the cleanup script it is probable that :-
1. Some files / folders / keys may still be subject to permissions restrictions until you do a reboot ;
2. Registrar Lite and CACLS may be unable to delete anything which Windows considers to be captive to a running process.

After a reboot then Registrar Lite and CACLS would have a better chance.

Please note that I have adapted the best endeavours of other people in choosing what should be zapped.
There may well be other stuff that they and I are not aware of.
This other stuff will not be targetted by my script,
and the only hope is that Comodo developers may know of it and prime the system with a Run Once deletion upon reboot before permissions (/refusals) are re-activated.
Similarly Revo-uninstaller may observe remnants that it would like to  zap via Run Once.

I am sure that failing to reboot at the appropriate time will not result in permanent disaster,
but think you may have a lot more manual selection and deletion to perform.

But please feel free to try your luck and post back.
I am not averse to learning from other people's experiences ! ! !

Alan

Offline Maverik

  • Newbie
  • *
  • Posts: 12
Re: Clean-Up Tool for Comodo Internet Security (OLD)
« Reply #50 on: February 20, 2010, 01:54:13 AM »
Hi all,
Alan you may be right. Actually when I woke up this morning I had the idea to see how many key are left in the registry by COMODO software. At the moment only COMODO System Cleaner is, let's say, officially installed.

1. launched Registrar Lite (from now on is rev. 2 - thanks Alan) and looked for "comodo" keyword in all registry. A list start building and suddently had a blue screen system stop (or crash as you like). No special hardware or driver failure were reported in the blue screen.

2. rebooted and made the same search hive by hive. The result was
CLASSES_ROOT: only references to COMODO System Cleaner and no crash
CURRENT_USER: nothing
USERS: references to COMODO System Cleaner and some to COMODO Internet Security but no crash
CURRENT_CONFIG: nothing
LOCAL_MACHINE: a list start building with references to System Cleaner and possibly to Internet Security, but this time I had the crash.
My feeling is that in the last search Registrar was trying an access to some protected keys. Your opinion Gentlemen?
Thanks in advance.

Riki
« Last Edit: February 20, 2010, 01:59:52 AM by Maverik »

Offline Alan Borer

  • Comodo's Hero
  • *****
  • Posts: 528
Re: Clean-Up Tool for Comodo Internet Security (OLD)
« Reply #51 on: February 20, 2010, 05:46:42 AM »
I have no such problem.

I have just done your search in HKLM on my machine.
Registrar Lite 2.0 took 1 min 48 seconds "CPU Time" and its summary was :-
Keys searched 124,304
Key names matches 10.467
value name matches 9
data matches 617
The peak memory used by rl.exe was 10,364 K - so for me there was no "out of memory" danger.

The above results are mostly for Comodo C.I.S. which is installed and fully protecting itself.
Only 21 results seem to refer to something else, they all start
HKLM\SOFTWARE\Microsoft\SystemCertificate\AuthRoot\Certificates\????????????
where ??????????? is a big multi-digit number which I believe relates to an application for which a Comodo certificate was purchased.
There was no evidence of COMODO System Cleaner in my registry -
if there had been I would be asking Comodo for my money back because I use the portable version ! ! !

I strongly recommend un-installing COMODO System Cleaner - perhaps that will avoid the crash.
1)  It may protect its keys more aggressively than C.I.S.
2)  When its privacy is invaded it may prefer death rather than dishonour >> B.S.O.D.
3)  There may be some special feature that causes Registrar Lite 2.0 to enter a recursive loop.

The next stage would be Registrar Registry 6.5 which you started with.
This may be better able to search without causing a BSOD.
ALSO it is crippled so that key permissions cannot be altered -
if it is not allowed to read it may give up whilst Registrar Lite could overcome restrictions.

I have XP Home which is free of UAC aggro - how about you.
When Registrar lite pokes around in some special HKLM regions then UAC may see that as a security threat.
 
Alan

Offline Maverik

  • Newbie
  • *
  • Posts: 12
Re: Clean-Up Tool for Comodo Internet Security (OLD)
« Reply #52 on: February 20, 2010, 07:23:45 AM »
ooppss ... I realized right now I didn't mention before my OS ... lol. I'm running on WinXP Pro.

Will try removing COMODO System Cleaner and redoing my search (just for couriosity), what I don't like in Registrar Lite 6.5 is that I found the button for modifying ownership and permissions dimmed -> unusable ... pretty much frustrating. Do you think it's worth the pain to get the full version? I'd not mind to spend 40 bucks if the software is good ... and when I say good I mean really good e.g. it does what they promised ... your opinion?

Another thing ... what's UAC ? forgive me but I'm not that used to achronisms (italian ... lol)

Regards
Riki

Offline Alan Borer

  • Comodo's Hero
  • *****
  • Posts: 528
Re: Clean-Up Tool for Comodo Internet Security (OLD)
« Reply #53 on: February 20, 2010, 10:19:27 AM »
UAC - You would know about it if you had it ! ! !

User Access Control - one of the reasons to avoid Vista.
It was so bad I believe it has been tamed slightly in Windows 7.

I probably use Registrar 2.0 or Registrar Registry 6.0.3.* only 3 or 4 times a year.
Registrar 2.0 does all I need with no restrictions.  I feel no need to buy a later version
Registrar Registry 6.0.3 has a nicer GUI - but if I need a facility that is crippled in 6.0.3 I revert to Registrar 2.0.

I suggest you just try out the 6.5 you downloaded for free, and see what facilities are crippled.
Then you can decide if you want to pay for the un-crippled PRO version,
or whether to fall back on 2.0 for the things that are crippled in 6.5

Regseeker took 2 min 44 seconds CPU time to do what Registrar 2.0 did in 1 minute 48 seconds.
One benefit of Regseeker is that I checked the "Group similar Keys" box and the summary was a far more concise display of only 395 "grand-daddy" keys, omitting all the child sub-keys.
Not only is Regseeker slower at searching,
it also fails to detect if the key is protected, and reports deletion even though nothing was zapped.

Regscanner (from Nirsoft) took only 33 seconds CPU time to find 30768 items
I have not tested whether it reports deletion failure.

I would be interested in the search times that you achieve with both 2.0 and 6.5.

Regards
Alan

Offline the1who

  • Newbie
  • *
  • Posts: 4
Re: Clean-Up Tool for Comodo Internet Security (OLD)
« Reply #54 on: March 10, 2010, 12:47:23 PM »
Ragwing,


Thank you thank you thank you thank you!

Well, can't say it enough.

About to pull my hair out, but that's ok, it only took 2.5 hours to fix it. I kept wondering what is going on here. This fix truly got version 4 on the system after experiencing error 1603, after removal of version 3 and reboot.

Thanks!

Offline Alan Borer

  • Comodo's Hero
  • *****
  • Posts: 528
Re: Clean-Up Tool for Comodo Internet Security (OLD)
« Reply #55 on: March 12, 2010, 11:56:58 AM »
To those who still have problems after running Ragwin's original version clean up tool,
I strongly recommend trying my version.

My version cleans up relevant items on the path "%userprofile%\...", whilst the original aimed at
"%systemdrive%\Documents and Settings\%username%\...".
That removes a major error for some people.
My "%USERNAME%" is "Alan" so the original target was
C:\Documents and Settings\Alan\...
but that does not exist.  What does exist is
C:\Documents and Settings\Dad\...   which corresponds to  %userprofile%\...

I made several other minor corrections.

I have also added extensive error checking.
The original script changes directory and then, regardless of error, deletes named target files.
So long as the "upon error default" folder does not hold files with those names then no harm is done.
My script is risk free by refraining from deleting any files from an "upon error default" folder

Apart from those changes, the second stage of my script cleans the same stuff that the original cleaned.

The tremendous bonus is that the third stage runs through the same list of files / folders / and registry keys,
and identifies each and every one that still needs removal.
This shows exactly which items have permission issues that must be resolved.
My script does NOT try to fix permission issues, BUT it shows you what YOU need to fix, after which you can try again.

I strongly recommend running the third stage after using the second stage to purge.
The second stage indicates some of what it deletes, and some of what failed,
BUT unfortunately %ERRORLEVEL% fails to show if a file / folder / key survived deletion,
so you will not know for sure if purge is complete until you run the third stage.

Only after total success in the above should you move on to stage 4, which prepares for a RunOnce reboot.

After all the above you can check if the Windows Security thinks that Comodo is still installed,
and if so you can run the script again, skipping the first 4 stages, and stage 5 will remove the repository.

NB  the first stage is the same as the third stage.
It shows how much was left after un-installing but does not remove anything.
It is for debug purposes - I needed to see what it would try to remove before it ran wild.
I have actually run the first stage of my script whilst Comodo was still protecting me - no damage.
It is still present for those who may wish to see in advance what is about to be removed.

When using the original script the screen is flooded with "not found" error messages for each and every file that the script tries to remove but fails because it went upon un-installing Comodo.  That flood of error messages renders almost invisible any complaints that the item was not accessible due to permissions restrictions.  My script suppresses these irrelevant messages so you can see what needs fixing.

NB I am disturbed by the effect on my system when I originally used Ragwin's script.
After I ran it many times and caught glimpses of "No Access" and fixed them,
I was able to complete removal of the old Comodo.
Before installing the new Comodo I checked in the error logs to see if any damage was done,
and found 4 off .NET Framework error messages upon reboot :-
Failed to load MOF C:\WINDOWS\MICROSOFT.NET\FRAMEWORK\V3.0\WINDOWS COMMUNICATION FOUNDATION\SERVICEMODEL.MOF while recovering repository file.
Subsequent reboots yielded no further errors - but I think the damage was already done.
I am now satisfied the problem was that the script concluded by deleting the repository.

Somewhere I have seen that auto-recovery works for "things" that are properly installed and not updated,
and it also works for them if they have been updated and re-registered or something,
but it will fail for those things that have been updated but not re-registered etc.
I am one of MANY people hit hard by a .NET Framework security patch that failed,
and M.$. Tech Support were unable to fix it for me.  We could not even remove .NET Framework.
I guess that counts as an update that failed too properly re-register,
hence rebuilding the repository gave 4 off MOF errors.
The probability is that there was no need to rebuild the repository,
and therefore deleting it did no good, but actually did me harm.

When the Repository is deleted, WMI may fail to rebuild a damaged repository.
When this situation occurs, all functionality of the WMI subsystem may be lost.
That sounds pretty serious to me.  see   http://support.microsoft.com/kb/320373

A much safer solution may be to disable the Security Centre and/or checks that it performs, see
http://forums.cnet.com/5208-6142_102-0.html?threadID=296381

I have been researching various tools to SAFELY identify WMI and repository problems,
and researching alternatives to rebuilding the repository.
I will very soon restore the ancient disc image from BEFORE the repository was ever deleted,
and then determine what damage is actually done by deleting or by alternative remedies.
Then I will post a final version of my script with any relevant updates.

The only change I anticipate is to rename the repository instead of deleting it,
so that if "all functionality of the WMI subsystem may be lost" and Windows is "dead in the water",
you can fall-back and resurrect Windows.

Alan

Offline FrENzy

  • Newbie
  • *
  • Posts: 3
Re: Clean-Up Tool for Comodo Internet Security (OLD)
« Reply #56 on: April 06, 2010, 02:42:14 PM »
[at]Ragwing:

Thanks for this useful tool, unfortinately it disabled my Windows-Security-Center (under Vista Home Premium 64Bit SP2 - German Language) - which can easily be activated again - but since then it did not recognize my Anti-Virus anymore (Avira AntiVir 10) even if it´s active.

Because the problem persisted, I unistalled Avira 10 and installed it again, now the Antivir is recognized again by the Security-Center!

[at]Maverik:

Did I understood you right, that you can´t delete some registry entrys?

Maybe you should try this: (copied from my post in another thread)

Quote
I found no normal way to get the ownerrights for the legacy-entrys in regedit to my admin account or the everybody-account under my Vista, it always popped up a message it did not save the settings- so I had to use Psexec from Sysinternals/Microsoft to kill them under "System"-rights. BE CAREFULL WHEN DOING THIS!

http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx English Link
http://technet.microsoft.com/de-de/sysinternals/bb897553.aspx German Link

After downloading the pack, make an link to psexec.exe with the following parameters:

"C:\Program Files\PsExEc\psexec.exe" -i -d -s c:\windows\regedit.exe

Check the path for psexec!

After using the link, you can easily delete the formerly listed LEGACY entrys, because regedit is then executed with system rights!

[at]Alan Borer:

Thank you for your work with your cleaning-tool. Didn´t you say it doesn´t show missing files? Well, on my PC it did - unfortunately the output is so long, I couldn´t read it all :(

Screenshot added at end.

"FEHLER: Der angegebene Registrierungsschlüssel bzw. Wert wurde nicht gefunden."
translates to the  following (I´m trying to translate it)
"ERROR: The entered Registrykey or Value couldn´t be found."

Now my question, how can an key/value be frozen if it´s not found? Maybe I didn´t get the tanslation correct, but I thought frozen keys are like the "legacy" keys, that you have to get ownership first?!


Oh, forgot to tell ya, that I just uninstalled CIS 3 and wanted to update to v4, but got the "1603-error".



edit:

oh and have you seen the thread "What are the install traces for CIS 3.11.108364.552" ? Maybe there are one or more file/key/value you eventually missed till now.

Quote from: EricJH
The following registry keys have been causing problems after uninstalling CIS. Try removing them before you install v4 again. They will resist deleting. You need to take ownership of those keys. To do so right click on the key --> Permissions --> give Owner's right full permission --> Ok --> now delete the keys.

Here are the keys :
   u.  HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\Root\LEGACY_CMDAGENT *
    v.  HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\Root\LEGACY_CMDGUARD *
   w.  HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\Root\LEGACY_CMDHLP *
    x.  HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\Root\LEGACY_INSPECT *
    y.  HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Enum\Root\LEGACY_CMDAGENT *
    z.  HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Enum\Root\LEGACY_CMDGUARD *
  aa.  HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Enum\Root\LEGACY_CMDHLP *
  bb.  HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Enum\Root\LEGACY_INSPECT *
  cc.   HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Enum\Root\LEGACY_CMDAGENT *
  dd.  HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Enum\Root\LEGACY_CMDGUARD *
  ee.  HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Enum\Root\LEGACY_CMDHLP *
   ff.   HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Enum\Root\LEGACY_INSPECT *
  gg.  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_CMDAGENT *
  hh.  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_CMDGUARD *
    ii.  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_CMDHLP *
   jj.   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_INSPECT *

Quoted by EricJH in the 1603-error-thread.

[attachment deleted by admin]
« Last Edit: April 07, 2010, 03:01:39 PM by FrENzy »
The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.
Douglas Adams, Mostly Harmless

Offline sf1003

  • Newbie
  • *
  • Posts: 15
Re: Clean-Up Tool for Comodo Internet Security (OLD)
« Reply #57 on: April 08, 2010, 01:25:37 AM »
Many thanks for batch file - bacon saved.

The only message I was getting from CIS was that the installation had failed because of an error, and basically to try later. An error number would have been great or something to give a pointer.

Regards,RL

Offline clydetrixz

  • Newbie
  • *
  • Posts: 1
Re: Clean-Up Tool for Comodo Internet Security (OLD)
« Reply #58 on: April 11, 2010, 01:26:06 AM »
omg
how come comodo internet security isnt in add/remove programs? =(

Offline Alan Borer

  • Comodo's Hero
  • *****
  • Posts: 528
Re: Clean-Up Tool for Comodo Internet Security (OLD)
« Reply #59 on: April 13, 2010, 06:53:32 PM »
[at]Alan Borer:
Thank you for your work with your cleaning-tool. Didn´t you say it doesn´t show missing files?
Well, on my PC it did - unfortunately the output is so long, I couldn´t read it all :(
I probably said something like that about one aspect of the tool,
and it should be possible to read it all - in a bit at a time ! !

Explaining from the beginning :-

Firstly, I took script at the start of this topic as a basis,
and did a quick select and change to all the entries.
The change was basically to replace every CD or DEL or REG.EXE with one of three routines,
and each routine tested the validity of the next section of the originally line of code,
and then took the relevant action and gave a relevant report on the outcome.
This has become a DELETION DEFINITION SCRIPT

If you inspect ZAP_CIS.TXT at the end of my post dated January 25, 2010, 10:52:09 AM on page 3,
you will see an introduction stating
There are now 3 new stages :-
LIST - Identifies what needs fixing, and gives summary plus Needed Fix TOTALs
KILL - Identifies fix attempts, BUT %ERRORLEVEL% is too unreliable for TOTALs
SHOW - Identifies remaining defects, and gives summary plus Needed Fix TOTALs

My new script runs the same DELETION DEFINITION SCRIPT in each stage.

The LIST STAGE concludes with
Code: [Select]
PATHS    :- VALID = 8; FROZEN = 0;             ABSENT = 2
FILES    :- FOUND = 8; FROZEN = 0; KILLED = 0; ABSENT = 8
REG_Keys :- FOUND = 44; FROZEN = 0; KILLED = 0; ABSENT = 99
NEED FIX :- FOUND = 52; FROZEN = 0; KILLED = 0;
52 Off Permissions/Residuals to correct.
This shows 8 valid paths and two absent paths, a total of 10 paths,
and the LIST stage identifies each path and whether it is valid or absent
and each is preceded by a blank line for clarity - a total of 20 lines.
Immediately below each path is a list of files expected on that path,
Each expected file is identified as Found or Absent, 1 line each.
There are 16 files expected so that is 16 lines.
Then there are 143 Registry keys, identified as Found or Absent, taking 143 lines.
Altogether it needs about 20 + 16 + 143 = 179 lines to display the LIST stage.

Having launched the script I did right click on the top bar of the "DOS" window,
chose properties / Layout, and set the Screen Buffer Size to Width 160 and Height 300.
Then a pop-up "Apply Properties" and I chose "Save properties for future Windows with same title"

Then I aborted the script and relaunched and there-after everything could be seen by scrolling.

No-one needs to run the LIST stage - it does nothing other than show what it is prepared to do.
But it is there for all the nervous people like me who worry about the consequence of running a stranger's script ! !

Also  I need it, and so does any-one else who might like to amend the script.
The very first thing I did was to run the LIST with Comodo fully active,
and I looked to confirm that it FOUND absolutely everything that was expected,
and then I investigated failures ! ! !
As you can see, there are a lot of ABSENT items - because I never accepted options like AskSBar.
When I first ran it I also found a very big error
Code: [Select]
Error:  The system was unable to find the specified registry key or value
ABSENT:- "HKEY_CURRENT_USER\Software\Local AppWizard-Generated Applications\HKEY_CURRENT_USER\Software\Local AppWizard-Generated Applications\CFPLog"
Obviously it needed to be corrected to delete
Code: [Select]
"HKEY_CURRENT_USER\Software\Local AppWizard-Generated Applications\CFPLog"
I looked at the original code I had copied and adjusted, and found the original code was
Code: [Select]
REG DELETE "HKEY_CURRENT_USER\Software\Local AppWizard-Generated Applications\HKEY_CURRENT_USER\Software\Local AppWizard-Generated Applications\CFPLog" /F
Obviously there has been a cut and paste accident in the original script,
and although it has been downloaded 606 times, no one else has stumbled across this error.
Perhaps 605 people have an unexpected CFPLog key.
More junk for a registry cleaner to do ! !

The LIST stage gives peace of mind to anyone who does not like to be surprised,
and prefers to know exactly what is about to happen.
It also easily shows any errors if/when I or any-one else should adjust the script.
Unlike your understanding of what I may have inadequately explained,
Every file and registry key is identified and and its status reported.

The KILL stage is where the action takes place.
If a file or key is absent, it is counted as absent in the summary but it is omitted from the list of items.
Each item is deleted, and a preliminary diagnosis of success or failure is made.
REG.EXE is a diabolical swine, it only returns two possible error codes,
and they do NOT always indicate success or failure, but any one of many other conditions - who knows what.
I have therefore focussed diagnosis upon expected "error messages".
e.g.  if you delete a registry key, you may fail because a permission prevents your access for deletion.
You may also fail because you are allowed access, BUT a sub-key is in use - yet the error code says you succeeded ! !

The ZAP_CIS.TXT discussed above was created to show what is listed WHILST Comodo is fully active.
The K_Test01.txt described and appended below was created after Comodo was uninstalled.

You will see the List stage shows almost everything is absent, but identifies 13 things need fixing
Search in the KILL stage for " ++ FROZEN  " and you will find 3 such items for which "access is denied"
and the grand total summary shows
Code: [Select]
PATHS    :- VALID = 7; FROZEN = 0;             ABSENT = 3
FILES    :- FOUND = 0; FROZEN = 3; KILLED = 0; ABSENT = 11
REG_Keys :- FOUND = 0; FROZEN = 0; KILLED = 8; ABSENT = 135
NEED FIX :- FOUND = 0; FROZEN = 3; KILLED = 8;
It is a best guess that three items were frozen,
but the registry is a horrible place and there could be other things wrong,
so the SHOW stage is needed for definite testing of whether all has been purged
This particular SHOW stage concludes with
Code: [Select]
PATHS    :- VALID = 7; FROZEN = 0;             ABSENT = 3
FILES    :- FOUND = 3; FROZEN = 0; KILLED = 0; ABSENT = 11
REG_Keys :- FOUND = 0; FROZEN = 0; KILLED = 0; ABSENT = 143
NEED FIX :- FOUND = 3; FROZEN = 0; KILLED = 0;
3 Off Permissions/Residuals to correct.  16:37:43.89

Please note that there is no difference between the actions of LIST and SHOW,
excepting that SHOW does not waste space on the ABSENT things;
it only shows what needs to be fixed.

After the above 3 stages I Quit and dealt with permissions issues, and had a meal.
a couple of hours later I ran the script again, QUITing the LIST but doing the KILL
It seemed to have success killing SFI.DAT.
The subsequent SHOW stage demonstrated success by concluding with
Code: [Select]
PATHS    :- VALID = 7; FROZEN = 0;             ABSENT = 3
FILES    :- FOUND = 0; FROZEN = 0; KILLED = 0; ABSENT = 14
REG_Keys :- FOUND = 0; FROZEN = 0; KILLED = 0; ABSENT = 143
NEED FIX :- FOUND = 0; FROZEN = 0; KILLED = 0;
0 Off Permissions/Residuals to correct.  19:27:01.13

After this is the next stage, i.e.
Use RUN_ONCE ?
I said yes and I got an error [SC] OpenService FAILED 1060:
I did not care because it was a belated attempt at fixing what should have (and in my case was) fixed by the initial un-installation of Comodo.
If you look in ZapBeta you will see the :RUN_ONCE code creates a registry key which should remove Comodo from the registry RUN startup keys, and also a RunOnce key is set to have another bash at Comodo upon reboot.  Obviously a 1060 error means that the RegEdit fixes could not delete their targets because their targets were long gone.

After this is the :REBUILD stage, in which I give dire warnings not to do this because it damaged my system.  After the warnings is
DESTROY & Rebuild Repository ?  Y(es) / N(o) :-
to which I promptly responded N.

Please note that the original script is one non-stop journey.
I have basically broken that into 3 pieces,
where the first piece (with up to 3 stages used) should be repeated until perfection is reached,
and only after that is something I would not dare to have designed,
i.e. launch RegEdit under full auto without any manual overide ! ! !
I do however believe this was written by experts far more competent than I,
and I am happy to include this as a useful stage - but it may give a harmless 1060 error if it was not needed.

The action of DESTROY & Rebuild Repository is to DESTROY and then hope Windows can Rebuild.
The reason is that Windows Security may mistakenly believe Firewall/Malware protection is still present,
and that mistake MAY cause it it to interfere with installation of "additional" protection,
so by deleting the "repository", windows should automatically, sooner or later, rebuild the repository, and then Windows Security should have a better idea of reality.

Obviously with a bit of luck and a clean removal, Windows Security will already know reality and have no need for this "assist".
There is however a real danger that Windows is already broken so bad that it cannot rebuild the Repository, and things just do not get better after this.  I have seen advice that the repository should NOT be deleted but renamed so you have something to fall back on.  I have seen a tool recommended for dealing with Windows Security without damaging the repository.  I think that WMI or some such thing can be exported and possibly imported to recover from some disasters.  I am still looking and testing.

I recommend that you avoid the DESTROY stage if possible,
but if you must do it, then in the words of Dave Allen,
"May your God be with you" ! !

When I first decided to incorporate error detection and reporting to this clean-up script,
and decided that Reg.exe was useless at distinguishing between errors with %ERRORLEVEL%,
I chose to instead use tests upon the presence or absence of certain phrases in the Console and/or Error streams.
I recognised that could be a problem for foreign languages,
but needed to get this thing working - even if only in English - so I could at least debug it.

Then I realised it could never work on foreign systems no matter what I did.
If you look at the second and third posts at the beginning of page 1,
you will see the script dealt with
%systemdrive%\Documents and Settings\All Users\Skrivbord\   instead of
%systemdrive%\Documents and Settings\All Users\Desktop\
and it was explained that "Skrivbord" was Swedish.
I deduced that the first originator of the script was Swedish,
and once he had it working it was translated for the benefit of the English,
so I guessed that if this script was run on any foreign machine,
it would not find any of the folders with things to be zapped,
and assumed the same was true for all the Registry Keys.
I now see in you screenshot that all the keys shown do match what I have in English.
How about the file and folder paths ?
Do they match the German reality, or does the script need adapting to hit the "foreign" file paths ?

Please advise if the targets for deletion need major changes before they work on foreign languages.
If only minor or zero changes are needed then I will urgently change my tests so they are independent of language, otherwise my priority will continue to be how to avoid disaster when Rebuilding the Repository.

To answer your question about FROZEN.
This should only appear when on the KILL mode when an item (file or key) has been deleted but fails to go away.  I know it should have gone and since it is still their I assume there is some permissions issue, or perhaps it is in use by some process.
The 6 FROZEN paths are a pure accident caused by foreign error messages.
I perform CD "path" to select the folders/files to be deleted, and test success or failure.
Then I show the intended path with either "VALID" or "ABSENT", - but getting a foreign response was not something I anticipated - whoooops !

n.b. If a "deleted" item is still present at the SHOW stage, I suspect it was frozen,
but merely show FOUND because there can be other causes,
e.g. Windows File Protection may notice it has gone and within a second or so it may replace it with a copy held in DLLCACHE.
This is also the reason I do not depend upon testing for a successful deletion at the time of KILL,
but leave the final test for the SHOW cycle.

Meanwhile, the following should enable you to correct the language dependant parts of my script.

PLEASE look in ZapBeta and locate
FIND /V /I "unable to find" < %TEMP%\ZAP_CFP\REG2.txt | FIND " "
Change "unable to find" to your German language and the Registry keys should be correctly reported.

To fix the FROZEN paths make similar changes to
FIND /V /I "cannot find" < %TEMP%\ZAP_CFP\remove_oop.txt

best of luck.

Regards
Alan


[attachment deleted by admin]
« Last Edit: April 14, 2010, 05:54:56 PM by Alan Borer »

 

Free Endpoint Protection
Seo4Smf 2.0 © SmfMod.Com Smf Destek