Posted 19 May 2012 - 04:16 PM
It wouldn't be impossible for the server to have a momentary issue but this is rare, at least in my experience
Posted 19 May 2012 - 09:53 PM
Posted 19 May 2012 - 11:41 PM
Posted 20 May 2012 - 02:48 AM
Never disable a firewall, AV..., give the executable(s) permission to run.
More descriptive, didn't notice - the list didn't load, the screen was blank, doesn't get more prominant than that. OK, mayber a better explanation might help, but in this case it was something at your end apparently, the server wasn't the issue.
APUP is a straight-forward tool, run it, it will load the release list and display a selection of packages (scripts) to download, when you make your selection, the script(s) will download said updates mostly directly from Microsoft, a few small files from autopatcher.com, or the various packages from either Adobe, ...
If you ever want to see what's in a script, load the releases.list in your browser, copy & paste the script link (everything after Script=) into a browser - AutoPatcher for Windows 7 SP1 (x86)
Point, if the list or script can be reached from a browser but not from APUP, it's not the server, it may or may not be APUP, could be a firewall interferring, bad proxy, buggy internet connection. A forum search for the error "unable to fetch release list" brings up many results, and answers. The APUP FAQ as well has this...
Q: APUP reports "Error fetching releases.list"
A: APUP has no internet connection. Check that Internet Explorer can access the internet, then check your firewall settings.
2 errors are common, they print out straight from the application window - "error fetching release list" & "one or more files failed verification" - the forum is full of answers on how to nail down where the issue is.
Posted 20 May 2012 - 03:34 AM
Edit: I've been using Autopatcher since 2006. Its been about 2 years since my last use and I'd never had either of these problems. My experience level is as a paid IT professional. I guarantee there were no network issues on my end, that I could find, even upon examination with TCPView and WireShark to determine where APUP was trying to connect so I could try my own ping of the server.
It would be more useful to display actual Winsock error or HTTP error that results in the generic fetching error.
Edited by raccoon, 20 May 2012 - 03:40 AM.
Posted 20 May 2012 - 04:35 AM
This is an entirely different issue, you didn't mention this earlier. You don't need to start from scratch - except as a last resort. After you've tried to download the releases, check the log file for the errors - read here & here about logs and how to post them in the correct forum - XP issues in the XP forum, 7 issues in the 7 forum etc. You want to identify the problem release. Select only one package at a time, download, did you get the error. You will also want to run AutoPatcher, click About - click Release Info, the release that is listed Red & False is the problem. Follow the directions when posting log files.
It would be more useful to display actual Winsock error or HTTP error that results in the generic fetching error.
Like I said, these 2 errors are very common, and the fix in most cases is easy as well, allow apup.exe or autopatcher.exe to run on said computer through adjusting firewalls, proxys, DEP, etc. I tried and got the list, DesertJerry did as well, I'm sure ViroMan tried to connect, if he'd had a problem he would have said something. You said you are downloading and getting failed verification errors, it appears you got a good connection, now we need to find the problem release and you should be good to go.
Locate the problem script, this is likely a problem at AutoPatcher's end, when the issue is determined it will be corrected. Also, if by chance you are trying to update a very old release, deletions may have been removed so stray files might get left behind. You said you started from scratch so this no longer applies but it may have been part of the problem earlier, stray files that should have been deleted but the scripts get pruned a bit for size so old files could get left behind.
It is a good idea to run APUP every month to get the latest files and remove the outdated stuff, you wait too long and the newer script wont remove everything - this is when a from scratch download would be better.
Posted 20 May 2012 - 05:04 AM
Running APUP2 I've run into the same issue. I'm going to try as you suggested after one more go at it, enabling logging and going at them one-by-one.
For the moment, here's a screen cap of the most recent failure. It's the first time APUP actully gave this error, it's usually Autopatcher that does. However, this is the first time using apup2.exe as well. The verification error usually happens in Autopatcher while validating files.
I'll keep you posted.
Posted 20 May 2012 - 05:22 AM
Posted 20 May 2012 - 05:37 AM
If the script is the problem, and looking at some of your selections, Office addon etc, I'm gonna guess it is an Office release that is at least partially responsible. Going from APUP1 to APUP2 (beta) only makes this more difficult and it wont matter a hill of beans if it's a script - it will still fail.
The AutoPatcher validation error is again a third and completely different issue. You want to get a release downloaded first, no failed files, no errors from APUP. Secondly, fire up AutoPatcher and make sure the release is Official. There are various issues that come from a bad apm file but it as well is handled differently, a bad detection, stays black when it should be blue. You seem to have at least 3 separate issues that need to be addressed one at a time - fetching issue, failed verification issue, and what ever this verification error in AutoPatcher is.
I see your post #10 - the XP script, we can only guess what the issue is unless we see the log for each script that's failing, like the log file thread stated. Some of the scripts have been updated for this last Patch Tuesday and may need some fixin' - need to see the log file otherwise we're guessing where the problem is.
What you need to do is provide the info I asked for - not screenshots, log files, what releases are Red in AutoPatcher as well, we need to run each script, create a log file, and post it in the appropriate forum for a better look, and possibly an edit.
You need to tell someone - Office Addon, XP English, etc are failing in my release package, run each script, create a log, also check AutoPatcher Release Info.
Posted 20 May 2012 - 05:49 AM
The reason we need this is because it will tell us specifics on what download failed... not just... something failed.
Posted 20 May 2012 - 07:24 AM
Posted 20 May 2012 - 07:38 AM
Detection error for file C:\Users\xaneth\Desktop\apup\modules\stand_alone\mseinstall_xp_vista_seven_x86.apm_files\mseinstall.exe MD5 Hashes do NOT match. Expecting AD2C37CEB8ADA40431AC9E4A41098820, but found 4cc124d12e39d0620931bbba53362c49!!! Item mseinstall_xp_vista_seven_x86 failed detection or its parts. Adding whole download for this item to the queue. --Adding http://download.micr...seinstall.exe-- Detection error for file C:\Users\xaneth\Desktop\apup\modules\stand_alone\mseinstall_xp_vista_seven_x64.apm_files\mseinstall.exe MD5 Hashes do NOT match. Expecting B34618EAF07F752B7572F7E7D0431101, but found 1a453eede7e44733dbfaa6e427d52c9d!!! Item mseinstall_xp_vista_seven_x64 failed detection or its parts. Adding whole download for this item to the queue. --Adding http://download.micr...seinstall.exe--
xaneth sent me part of the above in a PM. Looks like Microsoft has changed two files. While they are vista downloads I would bet the other windows versions of these files have been altered as well.
edit: I am looking into it now. huh... seems they are the only versions. The install works for XP through Win 7.
edit2: yep they modified the files... I will fix this now. Should be fixed within 10 mins.... maby longer since my connection is so crappy.
edit3: ok the script is updated and the rti is updated to allow it to show official... however I can't install it to pull the values to modify the apm file since I already have both a firewall and a antivirus. I would rather not have to uninstall both of them to get that value then install them again. Could someone install the new MS SE and then do a registry check at this location:
any x64 windows HKCR\Installer\Products\0BD83724E3CF27649AB939275F96E603 or any x86 windows HKCR\Installer\Products\D7CD6B45B5C8BFD4CB510C013A23B6B2
Specifically I am looking at key "Version" I need the values. They should both be the same however you will only have one of those values unless you have more then one windows installed. Until I get those values, the install will always appear as uninstalled in Autopatcher, if you already have the new one in, and always installed, if you still have the old ones in.
Edited by ViroMan, 20 May 2012 - 08:19 AM.
Posted 20 May 2012 - 01:40 PM
Edit: Also, are we simply "OK" with Microsoft modifying old modules? Is that a common practice for them? I thought they always created new files and obsoleted the old.
Edited by raccoon, 20 May 2012 - 01:45 PM.
Posted 20 May 2012 - 05:53 PM
They constantly modify old ones for no apparent reason. Size remains the same, version remains the same but, md5 changes. In this case they appear to have modified it substantially, increasing its size by about 2mb, possibly just AV updates.
Posted 20 May 2012 - 08:46 PM
Also, any plans to switch to SHA1 or better? Anyone can pass off an absolutely different file, then modify a few key bytes to make the MD5 match.
Edited by raccoon, 20 May 2012 - 08:47 PM.
Posted 20 May 2012 - 09:29 PM
It can already take a very long time to md5 something... doing a sha1 would add much more time to the process and only gain a slight amount of protection from a possible collision. Again the md5 is only to verify that the file is indeed complete and correct. They could have gone with a crc32 check which is really quite fast although the chance of a collision goes through the roof.
Posted 21 May 2012 - 04:42 AM
Edit: Sorry for the repeat. The page didn't refresh when revisited.
In response, SHA1 seems just as fast as MD5 even on my vintage 2004 laptop. I suppose there could be some accumulative reduction in speed, but nothing significant. I understand that MD5 is completely valid for detecting file write corruption, but what about DVD and torrent distributed Autopatcher? Alas, Microsoft may not put up with us forever, and script/patch distribution may have to take a more community-oriented path. There's also the unlikely but possible MITM attack vector.
Edited by raccoon, 21 May 2012 - 04:49 AM.
Posted 21 May 2012 - 06:30 AM
Slower hashing speeds will be painfully more so on a DVD... really you should remove the RTI files before burning to a DVD so there is no hashing going on.
The torrent distributed files are WAY out of date. If you see any version that does not come from this site it is NOT officially supported by us and you take any risks in using it.
Microsoft has no reason to resent us... anymore... we comply with the law fully(as far as I am aware).
I am creating a newer version of AutoPatcher that will be very script friendly. Should this site be shut down(knock on wood) after the new AP is out, people will be able to do there own thing without me.
You are correct the "Man In The Middle" attack is possible but, it is possible in any online connection you can have. While it is possible someone may do such a thing on this site... it will be hard to do once the new AP is out. the RTI files will be signed by the authors with there own signature file instead of a standard signature. Once AP finishes downloading the apm files and the RTI files. The RTI files will be checked then the apms and any already downloaded updates checked with the RTI files. Its not the best way to do it but, it is the simplest.
2 user(s) are reading this topic
0 members, 2 guests, 0 anonymous users