883 replies to this topic

[_def_x_]

-> about windows update agent? it applies to all OS's

So is this going to be a monthly thing now with this huge file extracting an x86 and x64 version to XP x86?

Anyway, I will never be able to get all 24MB to download to temp_bin to extract, can I do this by hand, download 'windowsupdateagent30.exe' and extract the 2 files needed - 'WindowsUpdateAgent30-x86.exe' and 'WindowsUpdateAgent30-x64.exe'?

Btw, more Microsoft brilliance, download one file, extract 3 versions, throw one away, leave 2 in the folder, including an x64 version for XP x86.

[Cristiano]

> So is this going to be a monthly thing now with this huge file extracting an x86 and x64 version to XP x86?
no. the last update that this one had was several months ago and it us to be released as standalone. this time that ms did this ... of merge the 3 versions of it in the same update. the idea about have the x64 too is due the download. since the x64 version is already present, there's no reason to this one be deleted

> I do this by hand, download 'windowsupdateagent30.exe' and extract the 2 files needed
sure. it can be extracted easily with 7zip. but without it, it also can be extracted, with /c argument

> Btw, more Microsoft brilliance
i fully agree with you. only a bunch of people will require the itanium version.

[]s

[DesertJerry]

Also see posting #477

XP Pro x64 w/SP2 - same results as reported in earlier posting - item still listed in black.

Ran APUP and downloaded updates - folder mentioned earlier not removed - same folders and files as previously.

Ran AutoPatcher and selected only the Windows Update Agent v7.4.7600.229 (x64) > installation indicated it was successful; rebooted > AutoPatcher > item still black.

Opened Explorer 64-bit > Catroot - same as previously - no listing for WUClient.

Obviously, something is still not working correctly.

[Cristiano]

the detection for x64 for sure is broken and has to be re-written. i was suppose to remove my hds and attach another one to test with another x64 OS, but for a few days i will be forced to take a bus (meaning several hours a day wasted waiting). so, as soon as possible, i will do that to try catch an suitable detection. as for the removal:
#Cristiano: 2010-09-18
PreAction=rmdir /S /Q "autopatcher:\modules\Components\WindowsUpdate_x86_files"

unless there's something wrong with that path, that folder should be removed by the xp enu script

about the install, i will re-check that as well. but since i didn't found an way to run an x64 OS under an vm, every single time that i have to test with with another OS means an full install (no, i will not waste an 120GB hd just to run - argggggggggggggggggggg - vista. besides, without activate it, it works for 30 days tops. so...

[]s

[Cristiano]

ok. i've found an copy of win xp pro x64, so i've installed and tested the issue regarding WindowsUpdateAgent30-x64.exe. findings:

- the install string works as expected
- the detection will not work. reason: no .cat file, no registry entry stating the version that is installed, no nothing. how i know that is installed? easy: just search for wuapi.dll and look for file version. it will be 7.4.7600.229. 2nd reason why i'm sure that this one was deployed: look at windir\system32:\SoftwareDistribution\Setup\ServiceStartup\wups.dll\7.4.7600.229

under LongHorn, the detection works as .cat based, like this:
[DetectionFile]
FilePath=system:\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
FileName=WUClient-SelfUpdate-Core~31bf3856ad364e35~amd64~~7.4.7600.229.cat
FileVersion=ANY

so, tests done, exorcism made, possible solutions:
- lock WindowsUpdateAgent_x64.apm to not load under xp x64, despite be an update for xp x64 as well;
- leave the module loading into all x64 OS's, fixing the detection for LongHorn and Seven

any other options, suggestions?

[]s

[DesertJerry]

Checked here and the updated DLL was found in \system32\.

Also found a 32-bit version in \windows\SysWOW64\ - could that location be used by AutoPatcher?

[Cristiano]

> windows\SysWOW64
no. under seven x64, that file remains without any update and without an registry detection, it works in "this AND this mode". so, it's impossible set an detection that works for longhorn/seven and another one that works under xp x64 as well. to work properly, the file version should be checked, like this:
[DetectionFile]
FilePath=windows:\System32
FileName=wuapi.dll
FileVersion=7.4.7600.229

but this doesn't work. by other hand, this works:
[DetectionFile]
FilePath=windows:\System32
FileName=wuapi.dll
FileVersion=ANY

the issue: doing this way, it doesn't detect, it just say that the file is present and that's all. it's possible do an OR detection, if any registry detection is present and if more than one file/location can work as reliable detection, like this:
[DetectionRegistry]
RegistryPath=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\ComponentDetect\amd64_microsoft-windows-windowsupdate-adm_31bf3856ad364e35_0.0.0.0_none_eb6ca4ff13465505
KeyName=WUClient-SelfUpdate-Core-AdmComp~31bf3856ad364e35~amd64~~7.4.7600.229.Adm
KeyValue=7.4.7600.229@32

[DetectionFile]
FilePath=system:\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
FileName=WUClient-SelfUpdate-Core~31bf3856ad364e35~amd64~~7.4.7600.229.cat
FileVersion=ANY

FilePath=windows:\System32
FileName=wuapi.dll
FileVersion=7.4.7600.229

FilePath=windows:\SysWOW64
FileName=wuapi.dll
FileVersion=7.4.7600.229

attached to this, there's an test module. it works under longhorn/seven, but the only way to be sure that works under xp x64 is load that module under that OS as well. any other file location will do the trick as well, but the file version needs to be 7.4.7600.229, otherwise it will be detecting an obsolete version

[]s

Edited by Cristiano, 22 September 2010 - 11:39 PM.

[DesertJerry]

Booted into Win7 64-bit > AutoPatcher > Update Agent v7.4.7600.229 (x64) listed in black > selected > Next > Installation ok > reboot > AutoPatcher > update agent still black.

Checked \system32\wuapi.dll version .229 installed today.

Checked \system32\catroot\WUClient-SelfUpdate-Core-CoreComp~31bf3856ad364e35~amd64~en-US was there (many times)

Downloaded test file - will have to wait till tomorrow to test in XP Pro x64 - getting late here (2235 hours)

[Cristiano]

> update agent still black
only that test file will detect it right

> md64~en-US was there (many times)
yep. i'm not sure why, but a lot of .cat files related to that are in there. worst: this update is multilanguage and due that an file that change according to the language of the OS can't work as an reliable detection. but that test module will do the job (i hope). just please, test that module under 7 as well

[]s

Edited by Cristiano, 23 September 2010 - 11:17 AM.

[DesertJerry]

Extracted test file (had to use 7-ZIP)

First try was in XP Pro x64 w/SP2 - test APM file initially was black and after running the installation and rebooting it stayed black - no change.

Next was Win7 64-bit. Started AutoPatcher and test APM was now blue and the one I used yesterday was black; so the new one: wuagentx64-test.apm successfully identified the -.229 update.

So, at least, it works in Win7 64-bit.

[Cristiano]

> had to use 7-ZIP
sorry. it's the one that i have in my machine. it's fully free, doesn't ask to buy something after an trial period, it's x64 and decompress everything and also compress to a lot of formats. sometimes, i forgot that most of the people like more zip or rar

> it works in Win7 64-bit
under LongHorn too

so, about the issue with xp x64? lock it to this one or allow the install anyway? under xp x86, it is an critical update (in fact, it's part of the fix to another kb), but at x64, i'm not sure

[]s

[DesertJerry]

Cristiano, on 23 September 2010 - 09:06 PM, said:

> so, about the issue with xp x64? lock it to this one or allow the install anyway? under xp x86, it is an critical update (in fact, it's part of the fix to another kb), but at x64, i'm not sure
[]s

Unless there is an easy way to inform the user that it will always be shown in black because if the installation detection failure issue I would have to recommend not showing it for XP x64.

[Cristiano]

sadly, there's not an way to inform the users about that. most of those that run autopatcher doesn't even bother to come here. so, nothing to do about this one

[]s

[DesertJerry]

Cristiano, on 23 September 2010 - 09:06 PM, said:

> had to use 7-ZIP
sorry. it's the one that i have in my machine. it's fully free, doesn't ask to buy something after an trial period, it's x64 and decompress everything and also compress to a lot of formats. sometimes, i forgot that most of the people like more zip or rar
[]s

I am used to a 7-ZIP created file ending in .7Z - that way I know what to use. Why did you not create the file in question and have it end with .7Z ?

[Cristiano]

but that one at #487 is .7z

[]s

[Cristiano]

oh, before i forgot, the WUA x64 module was updated

[]s

[DesertJerry]

Cristiano, on 25 September 2010 - 12:37 AM, said:

but that one at #487 is .7z[]s

The file I downloaded is: wuagentx64-test.zip on 22 Sept - I know it is listed at #487 with a .7Z but that's not what I got- oh well, problems in cyber space.

Edited by DesertJerry, 25 September 2010 - 03:25 AM.

[_def_x_]

Quote

The file I downloaded is: wuagentx64-test.zip on 22 Sept - I know it is listed at #487 with a .7Z

A good program should extract without issue either extension. These are 2 common archive formats, if you are using a tool you paid money for it should extract either format (check extension in options / may not archive). Two very good free (also portable) tools are 7-Zip and PeaZip, if you want to spend money I like Winrar, there's WinZip and others.

Point is, this shouldn't even be an issue - too many available (and free) tools that handle .zip or .7z without a fuss. As an example, 7-Zip is a great free tool, just some of the formats 7-Zip can handle are,

...Compress / Decompress: - .7z, .zip, GZip(.gz, .gzip, .tgz), .tar
...Decompress: - .rar, .cab, .dmg, NSIS(exe), and a few more.

[Cristiano]

> wuagentx64-test.zip
oh, that. when i upload something to the general public i us do do that in .zip format, because since xp and beyond, there's no need for an uncompressor for this format. just a question: in here, a lot of people have winzip or winrar, without any kind of registration and deal with that shareware warning. personally, the word "free" has an significant impact, but i can't state the same for everyone else. it's the same in other countries?

[]s

Edited by Cristiano, 25 September 2010 - 11:10 AM.

[click-click]

Big Patch Tuesday coming up....
"MS planning Patch Tuesday whopper: 16 bulletins, 49 vulnerabilities"