58 replies to this topic

[click-click]

I am currently faced with a problem where AP shows an incorrect status for
fixes that have been superseded by newer files. The new hotfixes are not being
taken into consideration in the AP processing because these hotfixes can only be
obtained by request. This means that the AP update detection rules are still based
on the older fixes and will cause AP to incorrectly flag fixes that have been replaced
by a newer fixpack

I was told that these type of hotfixes could not be included and I assume it is because
APUP does not have the needed access. I experimented with the related .APM files to
see if I could get AP to flag the superseded fixes as being installed. I was able to do
this by adding a second KBxxxxxx.CAT file + md5sum under [FileDetection] to each KBxxxxxx.APM
in question. This seems to work and AP now flags the superseded KBxxxxxx files as installed.
This works on both an integrated RVM system where the hotfixes exist and a non-integrated
system where only the superseded fixes exist.

Is it possible to add the additional CAT files and their ms5sums as a second criteria to
the superseded KBxxxxxx.APM files or will this be bending things to far?

In case there is interest, here is a list of fixes that are being flagged as uninstalled.

KB951748 -> KB951163-oro hotfix (DNS Spoof)
KB958655 -> KB967756-oro hotfix (Update Windows Installer 4.5)
KB968537 -> KB972483-oro hotfix -> KB971250-oro hotfix (Kernel)
KB970653 -> KB974176-oro hotfix (Timezone Update)
KB961501 -> KB972483-oro hotfix (Print Spooler)
KB956744 -> KB958106-oro hotfix -> KB967885-oro hotfix -> KB972828-oro hotfix (RDP 6.1)

These hotfixes can also be obtained from
http://thehotfixshar...oads&showcat=13

Thanks

Edited by click-click, 28 October 2009 - 01:12 AM.

[Cristiano]

> Is it possible to add the additional CAT files and their ms5sums as a second criteria to the superseded KBxxxxxx.APM files or will this be bending things to far?
sadly, no. it's possible have more than one detection by registry, but not by file. for registry, the detections works as "this or this" and for files, the detections works as "this and this". so, with 2 detections, the module will show as installed only for those that have booth updates. as those are released by request only, an major part of the users will have issues with that kind of detection. yes, that is an flaw of autopatcher, it could read an section of "or this" for files too, but for certain updates, we need more than one file detection. so, the best that can be done is make an section of "or" for files too. the good thing is that we are rebuilding autopatcher.exe. the bad thing is that will take time, because Antonis didn't shared the full source for it yet. due that, reinvent the wheel. and that takes time... but noted. this could be an interesting feature, in deed

oh, yes, there's one thing that can be done, but i don't know is can be useful to you: when you right-click one module, there's an option that says "don't show this module anymore". that can be set for those. it will not fix the issue, but it's the best that can be done

[]s

Edited by Cristiano, 28 October 2009 - 01:25 AM.

[click-click]

Well, it seems to work in my case. On the RVM system, I only have KB951163.CAT and the KB951748.CAT does not exist. I have changed the APM in the following way:

[DetectionFile]
FilePath=system:\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
FileName=KB951748.CAT
FileVersion=ANY
FileMD5=2911A6E75D5ACCA09EA2D32407A35C7C

FileName=KB951163.CAT
FileVersion=ANY
FileMD5=35a5041c4d1ddf79b2b441c833ae3bcf

On my non-integrated system, KB951163.CAT does not exist, but KB951748:CAT is there and that works too, so it looks like my changes are being processed as either or.

I'll test a bit more tomorrow to make sure.

Ciao

[Cristiano]

interesting behavior. this "or" never happened. but there's a lot of infos about autopatcher.exe that wasn't shared with us and we just tested like this:
[DetectionFile]
FilePath=system:\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
FileName=KB951748.CAT
FileVersion=ANY
FileMD5=2911A6E75D5ACCA09EA2D32407A35C7C

[DetectionFile]
FileName=KB951163.CAT
FileVersion=ANY
FileMD5=35a5041c4d1ddf79b2b441c833ae3bcf

in this mode, it works as booth. if this detection work, there's no problem adding that. so in deed, more tests may be required and you may have discovered one thing that we didn't knew so far

[]s

[_def_x_]

click-click said:

...Is it possible to add the additional CAT files and their ms5sums as a second criteria
...Well, it seems to work in my case.

Nice find, I hope it proves to be reliable - keep experimenting!

[click-click]

Here are my results on improving detection when KBxxxxxx fixpacks get
superseded by non-public hotfixes. In order for AP to flag superseded fixes
as installed, the following conditions must be met:

1. you must have only one [DetectionFile] section present
2. you must have two entries in the [DetectionFile] section of the APM file
3. both files must have the same FilePath
4. Filepath must only be specified for the first entry

AP will now process both criteria and if either condition is true, will flag
the superseded fix as installed.

Here are the changes that I have added in the following APM files. All
information is based on the ENU branch

KB958655_xp_x86.apm (Components)
FileName=KB967756.CAT
FileVersion=ANY
FileMD5=f12933ad5dd81d53ce4eb33269d2494b

KB951748_xp_x86_enu.apm (Critical)
FileName=KB951163.CAT
FileVersion=ANY
FileMD5=35a5041c4d1ddf79b2b441c833ae3bcf

KB956744_xp_x86_enu.apm (Critical)
FileName=KB972828.CAT
FileVersion=ANY
FileMD5=010db7a40262b48a52d1336f8bf3503a

KB957097_xp_x86_enu.apm (Critical)
FileName=KB947460.CAT
FileVersion=ANY
FileMD5=ce9e78375968f03222c60b31b44a2335

KB961501_xp_x86_enu.apm (Critical)
FileName=KB968585-V2.CAT
FileVersion=ANY
FileMD5=d74942039267a4cdc0756f34182ec51f

KB968537_xp_x86_enu.apm (Critical)
FileName=KB971250.CAT
FileVersion=ANY
FileMD5=de06a499eb80c9a9a4376724dd659215

I also found that the Detection File criteria for KB970653 is not
detecting correctly when using FileVersion=>5.1.2600.5845

I changed it to 5.1.2600.5861 for the file that I have installed and
AP still did not detect it correctly.

If I use FileMD5 and comment out the FileVersion entry, detection works
as it should.

[DetectionFile]
FilePath=system:\
FileName=tzchange.exe
;FileVersion=>5.1.2600.5845
FileMD5=b19591cd426ff2d3ddcd6cfeb1a093f5

FileName=tzchange.exe
;FileVersion=>5.1.2600.5861
FileMD5=0965fae98565e355cb64d8720e43a569

I also ran a test using the CAT files which also worked. I don't understand
why the Cat files weren't used in the first place.

FilePath=system:\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
FileName=KB970653-v3.CAT
FileVersion=ANY
FileMD5=f154a15b2fc009893f5628bbb413a845

FileName=KB974176.CAT
FileVersion=ANY
FileMD5=6d143cc97c0e73a616543643e0c2e604

[Cristiano]

congratulations. you have found an way of detection that we didn't know so far. those modules will be updated later today. there's no an real need for FileMD5= be exact. also those updates aren't public, may be tricky check if that .cat file matches for all. so, instead, i will set an ANY for that field, ok? so, it will make autopatcher only look for the .cat file. if it's in there, ok

> KB970653 is not detecting correctly when using FileVersion=>5.1.2600.5845
in here, it is. take a look:
http://img402.images...5402/970653.gif

but the issue regarding the detection may be the FileMD5 field. the detection works as "bigger or equal", but if you set an md5 for the file, then the file shall be the same than you have.

[DetectionRegistry]
RegistryPath=HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
KeyName=TZVersion
KeyValue=590080

[DetectionFile]
FilePath=system:\
FileName=tzchange.exe
FileVersion=>5.1.2600.5845
FileMD5=ANY

but this isn't an surprise at all. sometimes, certain files doesn't work well with file version

> I don't understand why the Cat files weren't used in the first place
because ms could do an non-public version of this one and name if of v4 or v5. then the user could not have this file and the detection could not work. by the other hand, if you set "bigger or equal", then anyone with an version bigger than that one could see this one as already installed

those files will be updated at night

[]s

Edited by Cristiano, 01 November 2009 - 04:06 PM.

[Cristiano]

ok, script updated. but sorry to tell you this, but this may be just an bug into autopatcher.exe. i did all those modules, just replacing the FileMD5=ANY. i did those changes into ptb and enu scripts and booth showed unexpected results. in the ptb script, KB958655 was always showing as not installed. i've installed this one by hand and still, same issue. for the enu script, this one worked, but not KB957097. so, one step back and, for every one of those updates that didn't worked, and the original detection was restored. all the modules was updated in the same way. more tests will be done, but if this double detection proves unreliable, it will be removed. in meantime, please report if any of those changes are working properly

[]s

[click-click]

Thank you for your support Cristiano. All of your changes worked fine for me.
I am still having problems with file detection based on FileVersion. It just
doesn't work in my case. I did try one more change which caused AP to detect
the Time Zone fix to be flagged as installed for the newer fix that I have.
For KB970653, I added the following entries (in red) to the [DetectionRegistry]
section:

[DetectionRegistry]
RegistryPath=HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
KeyName=TZVersion
KeyValue=590080

RegistryPath=HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
KeyName=TZVersion
KeyValue=590082

This will also work as an either or situation and flag the fix as installed.
FileVersion can stay the way it is now.


For KB957097 I added:

FileName=KB947460.CAT
FileVersion=ANY
FileMD5=ANY

This worked for me, but I don't understand why it failed for you. I also
don't understand why AP reacts differently with the PTB script as with the
ENU script.

BTW, I hid the CAPICOM fix KB931906 while I was experimenting and I'm not
sure how to tell AP to list it again. This is another fix that is being
detected by FileVersion which if I recall correctly, is also not being
detected even though it is installed. I'm not sure though and that is why
I need you to tell me how to unhide it.

Thanks ....

Edited by click-click, 02 November 2009 - 11:40 AM.

[Cristiano]

> I also don't understand why AP reacts differently with the PTB script as with the ENU script
neither me. but i will run more tests

> BTW, I hid the CAPICOM fix KB931906
easy. look into apup folder for an file named blacklist. you can edit that with notepad or just remove the file. booth actions will do the trick

as for this detection by registry, i will fix that in a few hours. right now, my ic is kinda unstable and i will not risk upload anything

[]s

[click-click]

No hurry Cristiano ....

False alarm on CAPICOM fix KB931906. FileVersion detection is working correctly for
that fix.

Edited by click-click, 02 November 2009 - 12:14 PM.

[click-click]

Cristiano, you were right about KB957097. I just noticed on my non-integrated SP2
system that this update was flagged as not installed. I looked at this a little
closer and the only difference I noted with this fix and the other superseded ones
was that the [DetectionRegistry] did not have any entries. So it looks like multiple
CAT entries will not work if there are no entries for [DetectionRegistry] I added the
following to the KB957097 APM and it works for both SP3 integrated with KB947460
and SP2 non-integrated without KB947460. I left [DetectionFile] as you had it with the
original CAT file

[DetectionRegistry]
RegistryPath=HKLM\SOFTWARE\Microsoft\Updates\Windows XP\SP4\KB947460
KeyName=Type
KeyValue=Update

Thanks

Edited by click-click, 02 November 2009 - 03:44 PM.

[Cristiano]

that may explain the issue, then. in the ptb script, KB958655 v2 didn't had an detection registry as well.

[]s

[click-click]

Hi Christiano,

I noticed that you made some updates to the PTB SP3 release (Nov. 4), but left the ENU SP3 release as it was. Is this because you are testing the requested changes for KB957097 and KB970653 that I asked about?

Also, any verdict on KB967715 that I posted here?:

http://www.autopatch...6-hotfix-depot/

I know you are busy so just tell me to stop pestering you if you feel like you're being pushed. I won't take it personal.

Thanks,

[Cristiano]

the ptb release has the extras and .net packages built in, to avoid certain files that only applies to win2k and x64. shockwave was updated in the extras package, so i had to update this script as well. as i stated more than once (but no one listened) the scripts should have only the files for one OS/language, as it was in the early days. but then, a lot of files in the extras package was merged with x64 and win2k, making an download that is useless for a lot of people. also, for non-english versions of any OS, there's translations packs for the .net package and there's no point about an english user download translations for ptb. by the other hand, it's also useless do an .net package for ptb that only has translations. so, instead, i've left that script as it was before the split done by erik. at that time, a lot of users had complains about download an "useless thing" like the .net package

the detections wasn't changed, because right now i'm kinda busy. i work fixing machines, you know. in the early days of each month, i have to burn the midnight oil, because this date is more close to the payment day from most of people. so, when i feel my eyes too tired, i try avoid change too many things at once.

about the detections, in deed those "or" seems to work only when there's an registry detection. so, i will add those, but probably i will have time for it only on saturday. the same for this update that seems replaced.

[]a

[click-click]

No problems and thanks a lot. I will be more patient the next time. I'll give you at least a week.

I'm amazed how you manage doing all this in the first place.

[Cristiano]

done. the remaining fixpack detections shall be fixed by now. also, KB971029 was added and KB967715 removed. thanks click-click

[]s

[click-click]

Here are a few more detection additions that are being missed with my
newly integrated RVM SP3 and non-integrated SP2 system. One problem I
am having is that sometimes when addons are integrated, the dev for that
addon may not always use the ENU branch CAT file. This causes AP to flag
the fix as not installed. Actually, there is nothing wrong with using a
CAT from another language branch as long as the CAT has been signed by
Msoft. This can sometimes easily be resolved by adding a registry detection.

Here are some changes that I made to the following APM files:

KB892130_wga_xp_x86.apm (wga) OR detection
RegistryPath=HKLM\SOFTWARE\Microsoft\Updates\WGA\SP0\KB892130
KeyName=Type
KeyValue=Update

KB952069_xp_sp3_x86_enu.apm (Critical) OR detection
RegistryPath=HKLM\SOFTWARE\Microsoft\Updates\Windows XP\SP4\KB952069
KeyName=Type
KeyValue=Update

KB958655_xp_x86.apm (Components) OR detection
RegistryPath=HKLM\SOFTWARE\Microsoft\Updates\Windows XP\SP4\KB972397-v2
KeyName=Type
KeyValue=Update

and remove the next file detection

FileName=KB967756.CAT
FileVersion=ANY
FileMD5=ANY

KB968816_xp_x86_enu.apm (__WMP_critical) single detection
[DetectionRegistry]
RegistryPath=HKLM\SOFTWARE\Microsoft\Updates\Windows Media Player\SP0\KB968816_WM9
KeyName=Type
KeyValue=Update

KB971961_IE8_xp_x86_enu.apm (__MSIE_critical) single detection
[DetectionRegistry]
RegistryPath=HKLM\SOFTWARE\Microsoft\Updates\Windows XP\SP0\KB971961-IE8
KeyName=Type
KeyValue=Update


I also noticed some fixes not being listed in my non-integrated XP SP2 because only

WindowsVersion=XP_SP3_X86 was specified for the following __WMP_critical fixes

KB954155_xp_x86_enu.apm
KB968816_xp_x86_enu.apm
KB969878_xp_x86_enu.apm

I don't think this is right because I have the first two fixes installed in SP2.
The titles for the 1st two fixes should also be changed not to reflect only SP3

Thanks

Edited by click-click, 15 November 2009 - 02:36 AM.

[Cristiano]

> KB892130
this one is a little bit complicated, due the version. if you set this one to be detected as update only, then the detection by version will be broken, even if you have an .cat detection as well. if any of those detections criteria match, then the module will be flagged as already installed and even the very first version of this one put that same info into the registry. so, if the version that the user has isn't the latest one, then when the user check at wu, then the new version will be prompted to be downloaded. so, at least for this one, an generic detection can't be set. worst: there's more-up-to-date versions of this one, but we don't have the link

as for the other ones, in a first look, no problem

[]s

[click-click]

Ahh, okay I think we talked about this once before. What if the CAT file detection were replaced with

FilePath=windows:\system32\
FileName=LegitCheckControl.dll
FileVersion=>1.7.69.2

Just a thought. I need to try it and see if it works on both systems.