Have microsoft changed something which is fouling up autopatcher? Can this be fixed?
Spoiler
0
Verification failed
Started by RedDwarf, Oct 05 2011 09:26 PM
7 replies to this topic
#1
-
- Members
-
- 3 posts
Newbie
Posted 05 October 2011 - 09:26 PM
I cannot get autopatcher to get past downloading updates. It has worked previously but now it fails. It does try to download a microsoft update even when I don't select any such updates and only have the autopatcher and common files selected for download. It tries to get windows-kb890830 v4 and never completes. I have windows-kb890830-x64-v3.16.exe on my hard drive even though I am using XP x86.
Have microsoft changed something which is fouling up autopatcher? Can this be fixed?
Have microsoft changed something which is fouling up autopatcher? Can this be fixed?
#2
-
- Release Managers
-
- 517 posts
Release Manager God
- Gender:Male
- Location:Italy
Posted 06 October 2011 - 06:16 PM
Uhm... your log report "Description: Failed to connect to host."
Have you any issues with internet connection? (firewall, proxy or other).
Have you any issues with internet connection? (firewall, proxy or other).
#3
-
- Members
-
- 3 posts
Newbie
Posted 07 October 2011 - 12:11 AM
No, my internet is working fine. I even shut down the firewall to make sure it was not affecting autopatcher. I don't use a proxy.
The problem seems to be with kb890830 v4 which is not available. It cannot be downloaded, although why on earth it is trying to download that because no windows updates were selected. It should only be updating autopatcher.
It still will not work.
The problem seems to be with kb890830 v4 which is not available. It cannot be downloaded, although why on earth it is trying to download that because no windows updates were selected. It should only be updating autopatcher.
It still will not work.
#4
-
- Veterans
-
- 1,460 posts
audi 5k
- Gender:Male
Posted 08 October 2011 - 10:22 AM
My friend is having a similar problem as RedDwarf, she saw this post and asked if I could help, I said I would try and answer both in this thread - here goes.
The common script is not a regular OS list of updates, it's a list of updates common to the OS scripts, XP, Vista, 7 etc. The script contains 4 files - Malicious Software Removal Tool (MRT) and Windows Update Agent (WUA) in both x86 and x64 flavors. If you want the MRT and WUA tools you will need to add the common script to your list of downloaded scripts, it's not a replacement for the XP, Vista, or 7 scripts.
Q. Why were these 4 files moved from the OS scripts?
A. There's 1 script to update when Microsoft updates any of these 4 files. It used to be when MS updated MRT mid month, before or after Patch Tuesday ALL the scripts would need to be updated - now only 1.
The problem in post #1 appears to be a firewall or other security software issue (if not the internet connection) blocking apup.exe or curl.exe - give these 2 apps access permissions if blocked. I'm able to reach the files from the links given in the log file.
RedDwarf, if the files can be downloaded from the direct links something is blocking the programs listed above...
MRT x64 ... http://download.micr...30-x64-v4.0.exe
MRT x86 ... http://download.micr...890830-v4.0.exe
The files will eventually 404 (dead link out) when updated, at that point the script will get updated too, for now the links appear valid. If Microsoft makes the links static, the files will simply not pass hash or size calculations, similar to rootsupd.exe (root certificates) when updated.
RedDwarf, the files are downloading because of the script you selected - autopatcher_common_.script - you want AutoPatcher for XP English, according to the OS listed in your log, if you want the critical updates. Select the common script for the additional tools, MRT & WUA, mentioned above.
Sarah, this applies to you too
Note: I've mentioned this a few times to friends, you will have to download versions you don't want to get the versions you do with the common script - if you want only x86 files, you still need all 4 present to have the release Official - this could change. An option, grab the links to the latest files from the script and download what you want separately but - keep the files out of the release or it will show as Unofficial.
The scripts can be reached from - http://www.autopatch...m/releases.list - simply copy the http link into your browser address bar, it's nothing more than a text file. Locate any file you want to test (or download separately) - the line is DownloadFrom=.
The common script is not a regular OS list of updates, it's a list of updates common to the OS scripts, XP, Vista, 7 etc. The script contains 4 files - Malicious Software Removal Tool (MRT) and Windows Update Agent (WUA) in both x86 and x64 flavors. If you want the MRT and WUA tools you will need to add the common script to your list of downloaded scripts, it's not a replacement for the XP, Vista, or 7 scripts.
Q. Why were these 4 files moved from the OS scripts?
A. There's 1 script to update when Microsoft updates any of these 4 files. It used to be when MS updated MRT mid month, before or after Patch Tuesday ALL the scripts would need to be updated - now only 1.
The problem in post #1 appears to be a firewall or other security software issue (if not the internet connection) blocking apup.exe or curl.exe - give these 2 apps access permissions if blocked. I'm able to reach the files from the links given in the log file.
RedDwarf, if the files can be downloaded from the direct links something is blocking the programs listed above...
MRT x64 ... http://download.micr...30-x64-v4.0.exe
MRT x86 ... http://download.micr...890830-v4.0.exe
The files will eventually 404 (dead link out) when updated, at that point the script will get updated too, for now the links appear valid. If Microsoft makes the links static, the files will simply not pass hash or size calculations, similar to rootsupd.exe (root certificates) when updated.
RedDwarf, the files are downloading because of the script you selected - autopatcher_common_.script - you want AutoPatcher for XP English, according to the OS listed in your log, if you want the critical updates. Select the common script for the additional tools, MRT & WUA, mentioned above.
Sarah, this applies to you too
Note: I've mentioned this a few times to friends, you will have to download versions you don't want to get the versions you do with the common script - if you want only x86 files, you still need all 4 present to have the release Official - this could change. An option, grab the links to the latest files from the script and download what you want separately but - keep the files out of the release or it will show as Unofficial.
The scripts can be reached from - http://www.autopatch...m/releases.list - simply copy the http link into your browser address bar, it's nothing more than a text file. Locate any file you want to test (or download separately) - the line is DownloadFrom=.
#5
-
- Project Manager
-
- 1,159 posts
Just an awesome guy.
- Gender:Male
- Location:California, USA, Earth, SOL, Milkyway
- Interests:Programming and being a know it all pest.
Posted 08 October 2011 - 06:38 PM
nice to see your still around and helping people. 
#6
-
- Veterans
-
- 1,460 posts
audi 5k
- Gender:Male
Posted 09 October 2011 - 09:29 AM
I suppose this wont matter since APUP v2 will soon be released but, after downloading and extracting the contents of apup131.zip to my C: drive to experiment with the 2K script mentioned in another post, I noticed something strange...
When I ran apup.exe for the first time 'Updater' and 'Engine' were auto-selected as expected but - instead of my OS, XP x86, APUP also selected autopatcher_common_.script as well. I deleted the folder and started fresh to test a second time - same result. Strange.
I haven't had AutoPatcher / APUP on my system since June, this was a fresh first-time run on a new drive, strange APUP ignored the OS and auto-selected the autopatcher_common_.script. I don't remember seeing this behavior from APUP in the past.
When I ran apup.exe for the first time 'Updater' and 'Engine' were auto-selected as expected but - instead of my OS, XP x86, APUP also selected autopatcher_common_.script as well. I deleted the folder and started fresh to test a second time - same result. Strange.
I haven't had AutoPatcher / APUP on my system since June, this was a fresh first-time run on a new drive, strange APUP ignored the OS and auto-selected the autopatcher_common_.script. I don't remember seeing this behavior from APUP in the past.
#7
-
- Project Manager
-
- 1,159 posts
Just an awesome guy.
- Gender:Male
- Location:California, USA, Earth, SOL, Milkyway
- Interests:Programming and being a know it all pest.
Posted 09 October 2011 - 06:05 PM
APUP2 doesn't auto select anything since some people in the suggestions area didn't want that. It will remember your selections and mark them again for you though.
#8
-
- Members
-
- 3 posts
Newbie
Posted 10 October 2011 - 08:45 PM
Thanks for trying to help gUiTaR_mIkE, I have fixed it and it is now working correctly.
It turned out it was DEP that was stopping things from working correctly. I enabled DEP for all programs very recently as I prefer to have it fully on for everything. It does mess up a few program and stop them working until they are added to the exclude list. I had forgotten about it.
After adding apup.exe and autopatcher.exe to the exclude list, it now works fine. autopatcher wouldn't even run, it started and terminated immediately starting drwtsn32.exe. Maybe it was a program that aup.exe relied upon which also triggered DEP and caused it to fail.
After doing that the kb890830 v4 files were downloaded fine. They did appear to download or data was certainly being transferred but they always came up as hash fails previously. I use Netmeter which shows when traffic is being transfered so I can see when downloads are happening. That does tend to indicate that a required program such as a hash checking program was unable to run due to DEP.
It turned out it was DEP that was stopping things from working correctly. I enabled DEP for all programs very recently as I prefer to have it fully on for everything. It does mess up a few program and stop them working until they are added to the exclude list. I had forgotten about it.
After adding apup.exe and autopatcher.exe to the exclude list, it now works fine. autopatcher wouldn't even run, it started and terminated immediately starting drwtsn32.exe. Maybe it was a program that aup.exe relied upon which also triggered DEP and caused it to fail.
After doing that the kb890830 v4 files were downloaded fine. They did appear to download or data was certainly being transferred but they always came up as hash fails previously. I use Netmeter which shows when traffic is being transfered so I can see when downloads are happening. That does tend to indicate that a required program such as a hash checking program was unable to run due to DEP.
Edited by RedDwarf, 10 October 2011 - 09:14 PM.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users
