AutoPatcher Forum

looking through the log, everything looks okay.
Except that it stops at:
"Executing shell command: del "F:\AutoPatcher\modules\Components\MicrosoftUpdate_x86.apm_files\MUWEB_SITE.CAB""

I get an on-screen error saying "one or more files failed verification"

(yes, yes, I know you will be getting rid of the XP SP2 module though).

has anybody else come across this?

FYI, on screen it shows:
muweb_site.cab
fetched 399.6 KiB / 390.6 KiB (102.3%)

Hi j-sta...

First...Try running Apup again and see if it can extract the missing files from the muweb cab file.
If you don't get any error message then IGNORE what I offer below. If you keep getting the error
message and the needed files are missing, then try what I suggest unless there are better suggestions.

I apologize up front if I shouldn't offer advice like this. You can do this if you are careful and
understand a little about how/where the script looks for files and the hashes it expects to find.

Do this at your own risk but it has worked for me on many an occasion.

I'm assuming you are doing this using AutoPatcher for Windows XP SP2 x86.

In my \Components\MicrosoftUpdate_x86.apm_files\ folder I have the following files...

....DataStore.edb
....InstMUWC.inf
....muweb.cat
....muweb.dll
....muweb.inf

I have a feeling you are missing the 3 "muweb" files which are likely in the "muweb_site.cab" file,
Verify this???

I have had issues with Apup not being able to extract the contents of cab files so I downloaded directly
the needed cab, extracted the necessary files using Winrar, verified the hash (md5) using HashTab, and
then moved to the appropriate folder without issue.

This is what my script looks like regarding the 3 "muweb" files, use your script if different.
.................................
Item=Microsoft Update

DetectFile=autopatcher:\modules\Components\MicrosoftUpdate_x86.apm_files\muweb.cat
DetectHash=7E93AE97E40CD479864D1F52E5F02B01

DetectFile=autopatcher:\modules\Components\MicrosoftUpdate_x86.apm_files\muweb.dll
DetectHash=8038B166CE79E58E193566150CE26465

DetectFile=autopatcher:\modules\Components\MicrosoftUpdate_x86.apm_files\muweb.inf
DetectHash=D5E8D43AFF3BC1BE877AEFA98D78A169
-------------------------------------------------------------------------------------------------------
If you need the cab for the missing files, download to a temp folder, extract the contents,
and if your missing files are in it, verify the hashes, and then move to the appropriate folder.

Use your script not mine, for where the expected files should be, the hashes, etc.

This is an example of what my script looks like. This is where I would download the cab file from,
and the expected hash should match, if not the file is corrupted - re download and verify again.

DownloadFrom=http://www.update.microsoft.com/microsoftupdate/v6/V5Controls/en/x86/client/MUWEB_SITE.CAB
ExpectedHash=8A35776F5A5EAC483480C309A39241A5


Again, sorry if I am over stepping the bounds.

Mike
Edited by gUiTaR_mIkE, 05 June 2008 - 03:59 AM.

gUiTaR_mIkE
thank you for the reply.
And yes, it is missing the muweb files.

Strangely, when I manually download the file, it's only 104K.

So why is apup displaying 390K? and how does it download 399K when a file is much smaller?

interesting; after manually adding the file, it's now failing on rootsupd.exe (Fetched 295.61 KiB / 286.1 KiB (103.1%))

Here's the end of the log

  Looking for file H:\AutoPatcher\modules\Critical\RootCert_files\rootsupd.exe
  MD5 Hashes do NOT match. Expecting 020EF20DD655F8992A64FBFC6F59FF90, but found b0ef15fe19fb3ac9367b1fcfe6d473f3!!!
Item rootsupd.exe doesn't appear to be here. Adding its downloads to queue...
  Adding http://download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe.
Finished adding downloads. Process queue.
Download queue status: 1 files waiting.
rootsupd.exe: Download complete.
Download queue status: 0 files waiting.

the file already in the folder is the same exact file as it's trying to retrieve. And both are failing.
Edited by j-sta, 05 June 2008 - 04:03 AM.

j-sta, lets not get ahead of ourselves. First, did the muweb files verify for you? I'm gonna guess yes
but you kinda turned left real quick on me here.

Did your log file look like this regarding the muweb files???

Starting detection routine for item Microsoft Update
Looking for file G:\AutoPatcher.Updater.New\Windows.2K.Updates\modules\Components\MicrosoftUpdate_x86.apm_files\muweb.cat
MD5 Hash matches (7E93AE97E40CD479864D1F52E5F02B01).
Looking for file G:\AutoPatcher.Updater.New\Windows.2K.Updates\modules\Components\MicrosoftUpdate_x86.apm_files\muweb.dll
MD5 Hash matches (8038B166CE79E58E193566150CE26465).
Looking for file G:\AutoPatcher.Updater.New\Windows.2K.Updates\modules\Components\MicrosoftUpdate_x86.apm_files\muweb.inf
MD5 Hash matches (D5E8D43AFF3BC1BE877AEFA98D78A169)

They passed if you got a "MD5 Hash matches" ????????

Clarify for me!!! If so lets move on. When you get an error like you have, just retry the download first,
checking the same boxes, in most cases it will download correctly. If you get an error again, look at the log,
and if you feel comfortable, download the file directly, always verifying to make sure the hash matches, and
then you can safely move it to the proper folder.

So, if your muweb files passed lets move on to "rootsupd.exe".

"Quote" -> the file already in the folder is the same exact file as it's trying to retrieve. And both are failing.

BOTH files, are you sure there are 2 files failing, it looks like 1 to me, rootsupd.exe

Same exact file, look again maybe the hashes don't match...

From your log...
Looking for file H:\AutoPatcher\modules\Critical\RootCert_files\rootsupd.exe
MD5 Hashes do NOT match.
Expecting 020EF20DD655F8992A64FBFC6F59FF90, but found b0ef15fe19fb3ac9367b1fcfe6d473f3!!!

"Compare" the hash from the "script" and/or "log" to the actual file in the folder.
If different, re download using Apup or do a "direct download" and verify again.

Let me know how it went...Pay close attention to the log file and script, their in lie the answers.

Mike

ok...
muweb_site.cab
in the script

ExpectedHash=8A35776F5A5EAC483480C309A39241A5
ActionAfterDownload=expand "autopatcher:\modules\Components\MicrosoftUpdate_x86.apm\MUWEB_SITE.CAB" -F:* "autopatcher:\modules\Components\MicrosoftUpdate_x86.apm_files"
ActionAfterDownload=del "autopatcher:\modules\Components\MicrosoftUpdate_x86.apm_files\MUWEB_SITE.CAB"

the muweb_site.cab's actual hash: 8A35776F5A5EAC483480C309A39241A5

Expected hash and file hash are the same, yet it's failing verification.
If I extract the cab file, yes, apup then passes through muweb_site.cab because the muweb files exist.
(I'm just assuming this is the file that's failing, because nowhere in the log does it state this file passed MD5 Hash Verification, and it's the last file listed in the log).

as for rootsupd.exe
it downloads the file from MS, and has the hash: B0EF15FE19FB3AC9367B1FCFE6D473F3
I manually downloaded the file off MS to verify it wasn't in the download... same hash.

yet the script is looking for hash: 020EF20DD655F8992A64FBFC6F59FF90
the actual file size is also larger than expected file size.

maybe an update MS put out and the script just hasn't been updated?

after editing the expected file size and hashes in the script, it was able to receive a bunch more files.
but then again failed on another file... windows_components_xp_x86_enu.zip
which is actually a file hosted by autopatcher...?
and in the folder this file goes, is already a file named: indows_components_xp_x86_enu_sp2.zip
typo? (no, I did not typo the file name... it is missing the 'w')

and now the script was changed back to default, and is failing on rootsupd.exe again.

ok so I see it keeps re-downloading the script... so no way to really fix that then, I s'pose.
Edited by j-sta, 05 June 2008 - 08:29 AM.

j-sta, I feel like we are not connecting here. I can't help if you don't offer the "correct"
follow up info. If you got it handled just say so, we'll move on.

1. If you get an error, in most cases closing apup, restarting, and downloading again works,
but not always.
2. I never said anything about "editing" the script, I said look at it and the log file for reference.
3. A cab file is really a zip file by another name that contains more files. In most cases Apup
DELETES the CAB file after extracting the needed files that are in the cab file.

(1)...The 3 muweb files and NOT the cab file are the important things here. I asked you for
verification from your log file. Did you put the 3 muweb files in the appropriate folder, and did
they pass verification? The cab file should never have been put in the apup/autopatcher folder.
I said put it in a temp folder and extract the contents, verify they are good, and then move "THEM"
to \Components\MicrosoftUpdate_x86.apm_files\. I still don't know what you have done here.

Look at my post #2 starting at -> Item=Microsoft Update (This is where the "FILES" should be)
I also said this in my first post to you -> If you need the cab for the missing files, download to a
temp folder, "Extract The Contents", and if your "Missing Files" are in it, verify the hashes, and then
move to the appropriate folder. If your 3 missing files are good, and you moved or copied them to
"MicrosoftUpdate_x86.apm_files" folder, you can delete the cab file at this point.

I did not say put the "CAB" file in the apup folder, but the 3 missing files.

Thats all you have to do here, and then verify by looking at the log file. I pointed to this in my
second post to you starting at -> Did your log file look like this regarding the muweb files???.

Then you switched to rootsupd.exe all of a sudden. If the 3 "muweb" files verified, your done here,
delete the cab file, you only wanted it for the 3 missing files. I'm just not sure exactly what all your
doing at this point with all the talk of editing etc and not seeing anything helpful from your log file.

Mike

just mis-understandings, but I have provided the info.

When apup fails on muweb_site.cab, if I click "no" on the "one or more files failed verification, continue" it leaves the cab file in the same folder the files would have been extracted to. I just extracted the files from the cab file, into the folder the file already existed in (which is the same folder that apup looks for the files in, being F:\apup\modules\Components\MicrosoftUpdate_x86.apm_files\). Make sense?
Basic jist: if I say no to continue, it leaves the cab file in the F:\apup\modules\Components\MicrosoftUpdate_x86.apm_files\ folder. I then extracted the contents of the cab file, into the F:\apup\modules\Components\MicrosoftUpdate_x86.apm_files\ folder.

Yet, why is it failing on the cab file, when the actual hash is the same as the expected hash? apup hasn't even (presumably) extracted the cab when it errors, so I don't see how it can be verifying the individual file hashes if it never extracts the files.
Regardless, if I manual extract the contents of the cab file, and it passes, why does apup not pass?

Yes, after I do this, they do then apparently pass verification, because I no longer get an error message on the muweb_site.cab file. Which would be the ONLY way for it to start failing on rootsupd.exe (since it looks for rootsupd.exe AFTER it looks for muweb_site.cab; therefore it can't fail on rootsupd.exe, if it fails on muweb_site.cab first)

Now it's still failing on rootsupd.exe.
Most likely because M$ updated the rootsupd.exe file, and the script is still expecting the old rootsupd.exe file; which of course I cant' do anything about.
Edited by j-sta, 05 June 2008 - 06:07 PM.

 gUiTaR_mIkE, on Jun 5 2008, 07:57 AM, said:

 j-sta, on Jun 4 2008, 11:00 PM, said:

but it should still not be failing in apup when cab file hashes are correct, and when it does pass verification when manually extracting contents of said cab file.
Edited by j-sta, 05 June 2008 - 06:09 PM.

from: http://www.autopatcher.com/forums/index.ph...hl=rootsupd.exe

 EmuKing, on May 31 2008, 02:16 PM, said:

so I'm not the only one with the issue with rootsupd.exe.

so the script does just need updated with the new file size and hash.

too bad there's no way to get apup to NOT re-download the script everytime it's run, or I coulda had it working fine, for myself anyway.
Edited by j-sta, 05 June 2008 - 09:49 PM.

you are right j-sta, there is an issue with rootsupd.exe.

It seems that both "XP SP2" and "XP SP3" have the same link to
rootsupd.exe, but "XP SP2" has a different file it is expecting to find.

rootsupd.exe must have been updated or changed since XP SP2, so they need to fix
the XP SP2 script for anyone who downloads XP SP2 from now until June 10 or this file
will keep failing verification.

(_XP_SP2_)
http://download.windowsupdate.com/msdownlo...en/rootsupd.exe
ExpectedSize=292952
ExpectedHash=020EF20DD655F8992A64FBFC6F59FF90

and the same link for XP SP3...but the size and hash are different and this is the file you download
from both links so the 302168 file size is the latest...

(_XP_SP3_)
http://download.windowsupdate.com/msdownlo...en/rootsupd.exe
ExpectedSize=302168
ExpectedHash=B0EF15FE19FB3AC9367B1FCFE6D473F3

The reason I seem to be allright is because I pieced together my XP SP2 package from an old
Autopatcher release as much as possible using the latest XP SP2 script as my guide, and then
finished downloading using Apup. This saved me lots of time, see I'm on dialup. I actually
have the old rootsupd.exe in my folder (292952), but if I deleted it, apup would download the
new one (302168) and I would have the same problem you are having.

If or when they fix the script, Apup will download the new file and over write my old one unless I
leave my XP SP2 Autopatcher as is and never run apup.exe. In your case, apup will finally pass
your file, if they fix the script which they may not because it is being phased out for XP SP3.

If they don't all ready know about this you might bring it to their attention. If they dont fix it, and to
just keep everything cool I can zip the (292952) file for you and email it to you so you can finish XP
SP2 on a good note.

Just a thought, if you notice the "apm" file associated with each folder's contents, if the "apm" shows no
regard for hashes and only correct file names, you might be able to simply leave the new file in there
and AutoPatcher will work just fine because a rootsupd.exe file will be present. Again, this is ONLY IF
the associated "apm" file ignores hashes, I don't know.

Mike

thanks for the tip on the apm files!
It does not appear the RootCert_enu.apm file has a line in it regarding the md5 hash.
As long as everything else got downloaded then, it should be fine.
But if it keeps failing, and there are other updates that are downloaded after this file, I will never receive the rest of the files.

If the script could be updated, or if it would just stop re-downloading everytime I run apup it would nice!
but I can't seem to change the path used to download the .script file. Otherwise I could manage.

Hi j-sta...

If you want to know exactly the files Apup is having problems with do this...

Run apup.exe /log and check only the (windows xp sp2 x86) box. This will
keep the log relevant for XP SP2 only. Let it download, and click "yes" to
continue when you get the warning message, click the "finish" tab to close
Apup.

Now...Scroll to the very end of the log file. Im not at a computer with a log to
look at but this is the jist...

It's the last 5 or 6 lines from the bottom we are interested in.

Look for the line saying something like "Adding To Download Que", so on and so forth.
Within these last few lines you can see the files apup redownloads because of errors
it found in the previous part of the log.

I think the last line will read "0 files waiting"....This you will get after apup finishes.

I think the only files you will see in the last few lines are rootsupd.exe, and if you never
got the muweb stuff sorted out, apup will try again with MUWEB_SITE.CAB looking
for the 3 missing muweb files we talked about.

Give it a go.

Mike

the issue with muweb_site.cab was resolved 2 days ago

Quote

the issues with rootsupd.exe.... gotta say, M$ just did something funky, because I can't even get that patch installed on the dozen or so computers I've tried so far... they all "install" but the update re-appears in Microsoft Update.

ah well.