13 replies to this topic

[JNicoll]

When I run Autopatcher it offers a particular update in the Critical section (for Windows XP SP3), showing it as ticked so it will be applied. I have several times told it to do so. Each time, after the apply is done and the machine rebooted, running Autopatcher again tells me again that the same update needs to be applied ...

In Autopatcher's display of available updates this one is described as

"Update for Root Certificates (February 2009)"

I've read the KB931125 info, and I know that the September 2009 equivalent has been installed. Indeed I looked at the contents of

C:\Program Files\~A-folder\AutoPatcher\modules\Critical\KB931125_xp_x86_rootcert.apm

to see how it detects that the most recent such fix has been applied then manually checked the registry value that shows that, and it is set properly. So that made me wonder where Autopatcher was finding info that made it think that the FEB 2009 fix was available to be applied.

I found, in: C:\Program Files\~A-folder\AutoPatcher\modules\Critical\ another .apm file, called: RootCerts_0902.apm

Should this have been deleted automatically at some stage?

If I manually delete it now, presumably Autopatcher will stop offering the FEB 2009 fix? Is that safe to do?

[Cristiano]

> I know that the September 2009 equivalent has been installed
isn't the same. the version has changed. but there's one way to check for any issue with the detection. please, run regedit.exe and look for:
RegistryPath=HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\{EF289A85-8E57-408d-BE47-73B55609861A}
KeyName=Version
KeyValue=22,0,2195,0

the current version is 22,0,2195,0. as you have RootCerts_0902.apm, this one looks for the wrong version and, due that, will offer to you this one every single time. probably this version was forgot in some update, i don't know. i never named files in this style, so this one may be in there since long ago, but autopatcher was supposing to show as unofficial due that. your version is official? as for safety of the removal, yes, it is. i've set an command to remove that file next time that you choose the xp enu script, but that can be done manually too

[]s

[JNicoll]

Cristiano, on 21 October 2009 - 02:00 AM, said:

> I know that the September 2009 equivalent has been installed
isn't the same. the version has changed. but there's one way to check for any issue with the detection. please, run regedit.exe and look for:
RegistryPath=HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\{EF289A85-8E57-408d-BE47-73B55609861A}
KeyName=Version
KeyValue=22,0,2195,0

the current version is 22,0,2195,0. as you have RootCerts_0902.apm, this one looks for the wrong version and, due that, will offer to you this one every single time. probably this version was forgot in some update, i don't know. i never named files in this style, so this one may be in there since long ago, but autopatcher was supposing to show as unofficial due that. your version is official? as for safety of the removal, yes, it is. i've set an command to remove that file next time that you choose the xp enu script, but that can be done manually too

[]s

Ok, I know they're not exactly the same, as MS say that 'KB931125' represents the repeating process of root cert updates rather than just one specific update (ie it's different from normal fixes).

I wasn't clear enough in what I described. I have already checked that key and seen that the value you mention is stored; this is how I know that the september version of KB931125 has been installed.


I don't understand what you mean by "shows as official"? I downloaded the initial install stuff for Autopatcher from this website, so how could it not be? But I had noticed that Autopatcher has a warning saying "Unofficial/Unsupported release" on its banner. I ignored this because I knew that Autopatcher was the genuine thing, downloaded from here.

Are you saying that this message - although it's on the Autopatcher banner - refers to one of the offered fixes rather than Autopatcher itself? If so, that's not clear. Perhaps the fix itself should be flagged somehow to show it's not official; after all, how is a user supposed to know which fix(es) the warning refers to, and what to do about it?

Thanks for changing the command.

[JNicoll]

Following up on your comment about the name of the file: RootCerts_0902.apm being non-standard....

I always run apup.exe with logging on, and I try to keep all the logs. I looked back through them to see if any of them gave any clues. In the apup.exe run I made on 26 May 2009 the log shows:

The Following Releases have been Picked:
apup.script
apengine.script
english/win_xp/autopatcher_xp_sp3_enu_1405a.script

There are two references to "RootCerts" is this log. The first is in the last of the pre-cleanup lines:

Deleting file C:\Program Files\~A-folder\AutoPatcher\modules\Critical\RootCerts_0811.apm

Then the detection phase shows:

Missing file C:\Program Files\~A-folder\AutoPatcher\modules\Critical\RootCerts_0902.apm
Item AutoPatcher RootCerts module is missing. Adding its download to the queue.
--Adding http://www.autopatch..._enu_0902.zip--

So someone - even if it wasn't you - has clearly used this sort of filename in the past...

i think it's a pity that apup's logs are not automatically kept from each run, indeed I'd be happier if the scripts which get put in temp_bin were also archived after each run. It'd make finding out what happened and why a great deal easier!

[JNicoll]

JNicoll, on 21 October 2009 - 07:51 PM, said:

So someone - even if it wasn't you - has clearly used this sort of filename in the past...

i think it's a pity that apup's logs are not automatically kept from each run, indeed I'd be happier if the scripts which get put in temp_bin were also archived after each run. It'd make finding out what happened and why a great deal easier!

I've been reading the thread:

http://www.autopatch...ported-release/

and I see from that - in msg 16 - guitarmike said:

This is good example of when a "Master Cleaner" script would come in handy. The main script keeps the "removal" commands for
a short time but, when they are deleted from the most recent script (assuming the user has run apup.exe recently) any "removal"
commands are placed in the "Master Cleaner" script - each release would have it's own "Master Cleaner".

I had no idea that file removal commands which may once have been in a script would get deleted from them. That's probably been the cause of my problem because I don't run apup as often as I should. Obviously I don't know how all these scripts are structured but it strikes me as foolish in the extreme to remove commands which you don't know that all the users have actually run.

[_def_x_]

@JNicoll

I will try to shed a bit of light on some of your questions but you will simply have to hang around the forums and in time you
will see the light. We really don't have time to keep teaching AutoPatcher / APUP 101 - it takes too long and a search of the
forums using specific terms may yield some threads that you can learn from, but I'll try the simple stuff.

...running Autopatcher again tells me again that the same update needs to be applied
Sure, this is a detection issue and they need to be fine tuned from time to time so the update gets marked as installed properly
the first time. Also, you probably picked up on this, the .apm file is the connection between AutoPatcher and the Update, remove
rename or edit the detections in the apm and the executable might as well not be in the release folder.

...about the rootcerts issue
I'm not sure exactly the problem here other than it looks as if you had a stray .apm file in your release that was causing problems,
and your release should have been unofficial if there are stray files left behind. The .rti file you see in the main folder stores all
the md5sums for the files in the release, have a bad sum, missing file, or extra files - you should get the unofficial flag, this lets
you know to hunt down the problem. BTW, there are a few files that get updated regularly, MRT and rootcerts are 2 of them.

Also, don't get too overwhelmed about the information in the script, there are a few Phases the script runs through so you will see old
files being deleted say "update.september.exe" (Pre-Cleanup Phase) and "update.october.exe" being downloaded (Downloading Phase),
and most errors will be picked up during the Detection Routine Phase.

...I'd be happier if the scripts which get put in temp_bin were also archived
I try and save the scripts that are known as "Official" - before you hit the Finish tab in APUP, "Copy" out the script and save it, you
can use notepad to open the scripts as well. Also, I know that APUP does logging differently - 1 log file getting rewritten to, but it is
better than a kick in the groin. You can use the "hit_this" file or create a shortcut adding /log -> apup.exe /log and always have a new
and updated log file ready to look over.

...about cleanup routines or the "master cleaner" script
If your release is unofficial you need to track the culprit(s) down and remove it / them. Also, if the script wasn't cleaned every now and
again it would grow way too large, and you shouldn't wait sooooo long between updates - the scripts aren't cleaned but months apart.
You could also create your own cleanup script by adding the cleanup routines and running the script locally.

This should get you a little more familiar with the procedures. BTW, I didn't proof-read my post (I'm tired) so be mindful of my typing and
errors.

[JNicoll]

gUiTaR_mIkE, on 21 October 2009 - 09:47 PM, said:

@JNicoll

I will try to shed a bit of light on some of your questions but you will simply have to hang around the forums and in time you
will see the light. We really don't have time to keep teaching AutoPatcher / APUP 101 - it takes too long and a search of the
forums using specific terms may yield some threads that you can learn from, but I'll try the simple stuff.

...running Autopatcher again tells me again that the same update needs to be applied
Sure, this is a detection issue and they need to be fine tuned from time to time so the update gets marked as installed properly
the first time. Also, you probably picked up on this, the .apm file is the connection between AutoPatcher and the Update, remove
rename or edit the detections in the apm and the executable might as well not be in the release folder.

...about the rootcerts issue
I'm not sure exactly the problem here other than it looks as if you had a stray .apm file in your release that was causing problems,
and your release should have been unofficial if there are stray files left behind. The .rti file you see in the main folder stores all
the md5sums for the files in the release, have a bad sum, missing file, or extra files - you should get the unofficial flag, this lets
you know to hunt down the problem. BTW, there are a few files that get updated regularly, MRT and rootcerts are 2 of them.

Also, don't get too overwhelmed about the information in the script, there are a few Phases the script runs through so you will see old
files being deleted say "update.september.exe" (Pre-Cleanup Phase) and "update.october.exe" being downloaded (Downloading Phase),
and most errors will be picked up during the Detection Routine Phase.

...I'd be happier if the scripts which get put in temp_bin were also archived
I try and save the scripts that are known as "Official" - before you hit the Finish tab in APUP, "Copy" out the script and save it, you
can use notepad to open the scripts as well. Also, I know that APUP does logging differently - 1 log file getting rewritten to, but it is
better than a kick in the groin. You can use the "hit_this" file or create a shortcut adding /log -> apup.exe /log and always have a new
and updated log file ready to look over.

...about cleanup routines or the "master cleaner" script
If your release is unofficial you need to track the culprit(s) down and remove it / them. Also, if the script wasn't cleaned every now and
again it would grow way too large, and you shouldn't wait sooooo long between updates - the scripts aren't cleaned but months apart.
You could also create your own cleanup script by adding the cleanup routines and running the script locally.

This should get you a little more familiar with the procedures. BTW, I didn't proof-read my post (I'm tired) so be mindful of my typing and
errors.

Thanks for such a thorough reply. You said: We really don't have time to keep teaching AutoPatcher / APUP 101

-- it's a great pity that there isn't decent documentation for the whole system. I've read the FAQs that I could find, and searched
the forums for various things. However because so many posts contain apup logs, it's really hard to find posts that are
relevant to very specific things. For example if you search on a particular KBnnnnn value you'll find references to it in
every embedded log, whether that post/thread is relevant to that fix or not.

The .apm file... yes, they seem straightforward inside; now that I know these exist it'll be easier to understand what's going on. I
did wonder though if editing one would cause a md5 failure on it, and if deleting one would simply cause apup to download it again or eg say that there was a mismatch between an .apm file and the fixes it describes how to install. I assume that normally one has both.

You said: ... and your release should have been unofficial if there are stray files left behind ...

-- to me, saying something "should have been unofficial" isn't very good english and it's hard to be sure exactly what you mean by it. It's partly that "should" normally implies a positive requirement, but that's contradicted by the negative-sounding 'unofficial'. It's also sounds as if you're saying that as a user I must have done something or other that I shouldn't have done. I think what you're actually saying is that Autopatcher is indicating that there's an integrity problem in one or more fixes in one or more releases. It's NOT saying that the fixes themselves necessarily came from an unofficial site, or that autopatcher.exe has got infected by something - but that's what it looks like it is saying.

Archiving temp_bin contents: I'll certainly try to do so from now on - thanks for telling me that they're accessible for a while...

You said: If your release is unofficial you need to track the culprit(s) down and remove it / them

When Autopatcher gives this warning in red, there doesn't seem to be any way to tell (a) which release(s) it's referring to, or ( what part of those releases. It seems odd to me that whereas apup creates a decent log, Autopatcher doesn't create any kind of log at all. I presume that the process of installing specific fixes is logged in C:\WINDOWS\KBnnnnnn.log etc, but what about the actions of Autopatcher itself?

You said that scripts would get too large if not cleaned....

Would it not be possible to create subsidiary scripts containing the stuff that you excise from the main scripts and ship those as actions that (like fixes) need to be 'installed'?

[_def_x_]

@JNicoll

Let me offer a bit of advice right from the get-go to keep you in the good graces of the forum regulars...
Please DoNot "Quote" verbatim every post - it gets redundant and the threads really start to get long.
...Log Files & "Quotes" - Please Read!

[_def_x_]

...Followup to post #7 above:

Quote

it's a great pity that there isn't decent documentation

True. I was going to create a nice guide but it didn't work out but to simply download a release and update a
system it really isn't difficult, that is why I'm wondering why you are already dissecting every word someone
says and trying to reinvent the wheel. It surely isn't perfect but it does work enough to update Windows XP.

Quote

The .apm file...if editing / if deleting -> would cause a md5 failure / cause apup to download it again

Yes! You answered your question just fine, basically, except...If the detections are incorrect the only way to know there
is a problem is for an end user to mention it. If the wrong info was added by mistake, and then the md5 calculated for
the script, the same error prone apm file will keep being downloaded if removed. You will notice that even after a script
has been updated there may be a few edits to a script or apm that will be needed to make the release good.

Quote

to me, saying something "should have been unofficial" isn't very good english

This is the part where I begin to get a little annoyed, not so much at your question but rather why? You have been here
for less than 2 days and you are getting distracted with aspects of the project that really don't concern you per se when
you should be trying to get your release Official. My Point: If a man falls off a 4 story building and lands on his head
is it unreasonable to remark "this man should have died, yet he didn't" - this is wrong you say? If in fact you had extra
apm files in your release both pointing to rootcerts, this should have caused the release to show as Unofficial normally,
but not always - if the release maintainer made a mistake.

...About the release integrity:
Again, you need to relax, you are thinking far too hard about all this. The files come from either microsoft.com, or
autopatcher.com, adobe, etc - direct from the developer's site ( look at the script -> DownloadFrom=http:// ).

Here's a test: When you get your XP SP3 release up to par (Official) simply put any new file in the \modules directory,
remember where you put it, you will want to remove it. Now, run autopatcher.exe and watch your Official release become
Unofficial. Now, after removing the extra file and your release is Official once again, remove an .apm file from the
\modules directory, remember you will want to put it back, fire up autopatcher.exe again and wallah! the release is
again Unofficial and it wasn't a big mean virus but the absence or presence of a rogue file.

Quote

...this warning in red, there doesn't seem to be any way to tell (a) which release(s) or ( what part...)

Well, there is a way ---- The APUP log may offer something up, or APUP may give off an error when downloading, you can fire up
autopatcher.exe and look for a red flag -> Start AutoPatcher - click the About tab, click Release Info, the bad release will be listed
in red under Title, as well the Status will list as False. Trying to find the file(s) that are causing the problem can be accomplished
by running apposing md5 checks - a good md5 from an Official release run on the Unofficial release, as well run an md5 created
on the Unofficial release on the Official release. This does become more difficult if there are multiple releases in the same \modules
folder but the tracking can still be done. -> XP SP3 Unofficial Status

Quote

Would it not be possible to create subsidiary scripts containing the stuff that you excise from the main scripts

The fix for this issue - Don't Wait 4 Months Between Updates, in fact it is a good idea to run APUP a couple times a month
or when the user base has been told there were edits to a script with a message...Please run apup.exe /log to update the release.

[JNicoll]

gUiTaR_mIkE, on 22 October 2009 - 02:29 AM, said:

@JNicoll

Let me offer a bit of advice right from the get-go to keep you in the good graces of the forum regulars...
Please DoNot "Quote" verbatim every post ...

Sorry, that was an accident. I have trimmed quotes in other replies.

[JNicoll]

gUiTaR_mIkE, on 22 October 2009 - 07:50 AM, said:

I was going to create a nice guide but it didn't work out but to simply download a release and update a
system it really isn't difficult, that is why I'm wondering why you are already dissecting every word someone
says and trying to reinvent the wheel. It surely isn't perfect but it does work enough to update Windows XP.

Your forums are full of questions from people which suggest that it isn't straightforward all the time.
I'm not trying to reinvent a wheel, but to understand properly the wheel we've got.

gUiTaR_mIkE, on 22 October 2009 - 07:50 AM, said:

This is the part where I begin to get a little annoyed, not so much at your question but rather why? You have been here
for less than 2 days and you are getting distracted with aspects of the project that really don't concern you per se when
you should be trying to get your release Official. My Point: If a man falls off a 4 story building and lands on his head
is it unreasonable to remark "this man should have died, yet he didn't" - this is wrong you say? If in fact you had extra
apm files in your release both pointing to rootcerts, this should have caused the release to show as Unofficial normally,
but not always - if the release maintainer made a mistake.

I'm certain I've been here longer than just 2 days but couldn't find the details of how I previously registered so had to re-register. Moreover I've been using AP for a good deal longer than 2 days. It's only in the last few days that I've had probvlems I couldn't understand and had to resort to the forums though.

You say I'm getting distracted by 'aspects of the project that don't concern me'. What do you mean? Like all your other users I'm trying to use AP (certainly much better than raw windows update), but I find myself frustrated trying to work out what AP is doing so that I can get to the bottom of why it isn't working properly. A case in point is the "unsupported/unofficial" thing - there's a fair number of posts on the various forums made by people hitting that and yet, despite it being a common problem, there's no clear explanation anywhere of exactly how a user can diagnose and fix such a problem. I think that if there was a little more user documentation, you and the other AP people would spend a lot less time having to help people.

gUiTaR_mIkE, on 22 October 2009 - 07:50 AM, said:

Again, you need to relax, you are thinking far too hard about all this. The files come from either microsoft.com, or
autopatcher.com, adobe, etc - direct from the developer's site ( look at the script -> DownloadFrom=http:// ).

Here's a test: When you get your XP SP3 release up to par (Official) simply put any new file in the \modules directory,
remember where you put it, you will want to remove it. Now, run autopatcher.exe and watch your Official release become
Unofficial. Now, after removing the extra file and your release is Official once again, remove an .apm file from the
\modules directory, remember you will want to put it back, fire up autopatcher.exe again and wallah! the release is
again Unofficial and it wasn't a big mean virus but the absence or presence of a rogue file.

Actually, that's what I have been trying to say to you. "Unofficial" sounds like a much bigger, or different, problem from what the actual problem is. If AP said: "found unexpected files" or "couldn't find expected files" that might be clearer. "Unofficial" makes naive users like me think the worst is happening. (I do realise that if you have no developer you can't do anything about the code in autopatcher.exe, but you could still document the implications and how to investigate the problem, which would be more reassuring.)

gUiTaR_mIkE, on 22 October 2009 - 07:50 AM, said:

Well, there is a way ---- The APUP log may offer something up, or APUP may give off an error when downloading, you can fire up
autopatcher.exe and look for a red flag -> Start AutoPatcher - click the About tab, click Release Info, the bad release will be listed
in red under Title, as well the Status will list as False. Trying to find the file(s) that are causing the problem can be accomplished
by running apposing md5 checks - a good md5 from an Official release run on the Unofficial release, as well run an md5 created
on the Unofficial release on the Official release. This does become more difficult if there are multiple releases in the same \modules
folder but the tracking can still be done. -> XP SP3 Unofficial Status

Thanks for the ABout->Release Info information. I certainly didn't know that before. (I'm currently seeing - on a different computer - 'Unofficial' declared in the warning but no releases described as bad that way, which presumably means extra files somewhere rather than missing or corrupt ones - but I'll go into that more in a new thread I think.)

gUiTaR_mIkE, on 22 October 2009 - 07:50 AM, said:

The fix for this issue - Don't Wait 4 Months Between Updates, in fact it is a good idea to run APUP a couple times a month
or when the user base has been told there were edits to a script with a message....

I've added diary entries to machines to remind me to do this.

If a new user comes along and starts using AP they could have all the fixes issued (eg for XP) since SP3 to download and install, even though the first of those became available quite a while ago. Do the cleaned scripts still work for people who are behind the times like that?

[Cristiano]

> there's no clear explanation anywhere of exactly how a user can diagnose and fix such a problem.
no, because the scripts was lacking an basic information: an check for the files. so, some of the releases already have an .md5 file. an start is check that against the files that are in your own apup folder. if everything matches, then this issue is surely related to extra files, that can be tracked in minutes, if the user present an recursive md5 from the entire content of his apup folder. that can done with many free softwares, like hksfv, etc.

> Do the cleaned scripts still work for people who are behind the times like that?
yes, the scripts will still work. even the download result will work. the only things that may happen is:
- the release becomes unofficial;
- the user will stay with obsolete files and taking more time than is required to install everything due the extra files

but we don't have an real choice about the cleaning of the scripts. if we don't do that, the scripts become an real mess, impossible to read or track issues worst: the log becomes an nightmare. it can be hide, but then track broken commands become an real problem, because then the log will show noting more than a few infos that may or not help something. but when you see the commands that are running, then you may see why something gone wrong. but still, even with hidden ren/del/rmdir, etc the size of the script increases too much.

[]s

[_def_x_]

@JNicoll

If you could do a few things for us this might help get your release(s) Official.

...Run "apup.exe /log" (you can do this by dbl-clicking the "hit_this" file), select the release(s) you have in your AutoPatcher folder to update them,
make note of any errors APUP may show (pop-up).

...Once you have done everything available by using APUP, scan your entire \AutoPatcher folder (recursively) to create an .md5 of the total folder contents.

...Run "autopatcher.exe /verbose" - when the modules load click About - click Release Info - please get a screenshot of the Release Info window.

If you could post a .zip file containing: (1) .md5 of your entire AutoPatcher release(s), (2) APUP & AutoPatcher logs, (3) screenshot (Release Info window).


...Finally, quit complaining about the use of Unofficial / Unsupported (we understand - you disapprove) - it does serve a purpose. The fact anybody can come
in here and download a release and post it on the internet (possibly putting rogue files in the release that could be run) as a single executable requires a stern
warning. Again, we have heard you loud and clear regarding your complaints - let's move on. Please post details of issues with your release(s), we don't have
the time to debate (for me, desire) because a simple fix is for you to find a program that meets your intellectual necessity if AutoPatcher / APUP are unable to.

One important issue regarding APUP / AutoPatcher that does seem to escape basic reasoning for some: They are a work in progress, in many ways incomplete
but are free to use (or not). Also, any offer of support is again free (for you) and does cost somebody time, so how about we agree to disagree and move forward
with trying to make things easier 1 step at a time - there are a few improvements in the works.

[James]

gUiTaR_mIkE, on 30 October 2009 - 03:39 AM, said:

One important issue regarding APUP / AutoPatcher that does seem to escape basic reasoning for some: They are a work in progress, in many ways incomplete but are free to use (or not). Also, any offer of support is again free (for you) and does cost somebody time, so how about we agree to disagree and move forward with trying to make things easier 1 step at a time - there are a few improvements in the works.

I agree, especially as most of this thread is now way off-topic.

In the meantime, thanks Mike, for the valuable assistance given.

==