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
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
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
"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
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
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
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
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]
