←  AutoPatcher for Windows XP SP3 (x86)

AutoPatcher Forum

»

Slow installing

OmYcroN's Photo OmYcroN 25 Feb 2010

Hi and congrats for APUP and for members working on it. I've just tested on VMWare 7 and it works nice but takes very much time to install the updates and some times hangs with 100% CPU. APUP has problems with virtual environments !? Also why APUP doesn't directly install updates with the silent switch and choose to expand it before this ?
Quote

_def_x_'s Photo _def_x_ 25 Feb 2010

Hi OmYcroN

Just to be clear, APUP downloads / maintains the release(s) and AutoPatcher installs the updates to your system.

I just updated a new install of XP SP3 x86 in VPC 2007 and had zero problems running AutoPatcher in a virtual environment. If you had
every update checked for installation that may be part of the problem, I think there were 60+ updates needed, that's a lot in one pass,
IMO.

Also, most of the updates have the /quiet switch so only in rare occasions should you get a prompt, I don't recall seeing any but Cristiano
can address this issue better, he does the release, there may be a few updates that require user input, if this is what your referring to.
Quote

OmYcroN's Photo OmYcroN 25 Feb 2010

I didn't say there were problems in WMWare but it takes very much time to install all critical updates (60+) with AutoPatcher. A normal install takes 15 minutes no ? I did a batch that installed all those updates (silent) and it was much quicker. Maybe AutoPatcher is doing something else when installing updates (like expanding exes into temp folders and then running them, checking files etc.) ?!

And another thing. WGA must be installed manually !!! Why not use autoit (or something similar) to resolve that ?
Edited by OmYcroN, 25 February 2010 - 03:10 PM.
Quote

_def_x_'s Photo _def_x_ 25 Feb 2010

OmYcroN said:

I didn't say there were problems in WMWare

OmYcroN said:

and some times hangs with 100% CPU

OmYcroN said:

APUP has problems with virtual environments
I don't know what to tell you then.
Quote

OmYcroN's Photo OmYcroN 25 Feb 2010

 gUiTaR_mIkE, on 25 February 2010 - 03:41 PM, said:

I don't know what to tell you then.


:lol: Let's say the hang CPU problem and the slow installing are Vmware related. In "real life PC" how much time does AutoPatcher need to install those 65 critical updates ? I hope it's muck quicker than the online one :o .
Quote

Cristiano's Photo Cristiano 25 Feb 2010

> A normal install takes 15 minutes no ?
i run some vms with ms virtual pc 2007 in a athlon xp 2600+ and i us to set only about 300mb of ram to the vms. and the install doesn't take so long. for sure, with an better hardware, it's possible that you can deploy all the updates a lot faster than 60minutes. as an guess, it may be an issue in the vm himself. also, the deploy task us to take a lot less when you disable system restore (but of course, you know what happens when you disable that)

> AutoPatcher is doing something else when installing updates (like expanding exes into temp folders and then running them, checking files etc.
no. autopatcher is just an interface. when autopatcher loads, it reads the infos about your OS, language and do the proper detections to check for already installed updates. after that, autopatcher loads the update tree. with that ready, according to your selections, autopatcher will run every single update like this:
"Module:\WindowsXP-KB975713-x86-ENU.exe" /quiet /norestart /overwriteoem

where: module is the folder with the same name than the .apm file (unless specified in the .apm file).

any other task is done only by the update himself, according to the settings /quiet /norestart /overwriteoem . most of the updates extract the content of the update to an temp folder and then deploy the update himself. but that task isn't done by autopatcher, it's done by the kb

> And another thing. WGA must be installed manually !!! Why not use autoit (or something similar) to resolve that ?
because ms says that the user must agree with the eula to this one and have removed the /quiet option. also, every single update must come from ms website. due that, any change in the update himself needs to be done in the user's machine

> and some times hangs with 100% CPU
that us to indicate that the system is busy with something. perhaps an av scanning?

> In "real life PC" how much time does AutoPatcher need to install those 65 critical updates ?
well, how fast is your machine? a few days ago, i've fixed an customer machine and, after set autopatcher to run deploying all the updates at once (including .net, java, direct x, etc), i've left the room to take an juice and feed my cats. after that (i was away for less than 10min) autopatcher was already finishing the deployment of adobe reader. for sure that machine was really faster, but even in my 2600+ the whole deployment doesn't take longer than 30minutes. but (there's always an but) i've already found several machines that was painfully slow and the deployment in certain cases toke more than 1 hour.

[]s
Quote

OmYcroN's Photo OmYcroN 25 Feb 2010

Thank you for the reply. The case of 100% cpu in vmware is addressed to AutoPatcher when installing updates. - The thing with the WGA - When an user selects that update isn't he agreeing to the "agreement" ? Or before the installation begins can't AutoPatcher show the user that EULA or even move the priority of WGA's installation to top, so the install doesn't stop after ~19 updates ? I want to install them without being there after I click Install. The solution is to run a parallel autoit program and wait for the WGA to pop out but then again this is something else.
Quote

Cristiano's Photo Cristiano 25 Feb 2010

> When an user selects that update isn't he agreeing to the "agreement" ?
no. the user must read and accept the eula

> can't AutoPatcher show the user that EULA or even move the priority of WGA's installation to top
that can be done, but updates needs to be deployed in a proper order. we us to choose release date as order. i will do some checks (but not sooner than next week) about change that date to allow that

[]s
Quote

OmYcroN's Photo OmYcroN 28 Feb 2010

Here is my desktop in VMWare (1 gb ram) and processes list :

Posted Image

Maybe it helps or not but the CPU is always too high (and updates take a lot to install than installing theme from a .bat (~10s small ones) file (i know autopatcher does the same but what is wrong here ?!). If somebody is trying this on VMWare 7 please post.

1. I see that each update has it's installing time (10s ?!) so if an update is faster than that it has to wait that time ?

2. What is that with the red marks : Unofficial/Unsupported version ?

IGNORE PICTURE BELOW !
Edited by OmYcroN, 28 February 2010 - 09:00 PM.
Quote

_def_x_'s Photo _def_x_ 01 Mar 2010

OmYcroN said:

2. What is that with the red marks : Unofficial/Unsupported version?
It means your release isn't quite 100%, you are either over / under / not passing hash on 1 file or more.

If you could, run the .md5 file inside the \apup folder, if it verifies all the files you likely have an extra somewhere. If you have
multiple releases in the \apup folder run each .md5, as well, fire up AutoPatcher, click About - Release Info, the offending release
is the one marked False.

If you have only XP SP3 x86 by itself, can you create an .md5 of the entire release and I will run it against my Official release and
maybe we can find the stray file, assuming it is a stray, it may be that a file didn't pass hash and needs to get downloaded again.

Also, are you having troubles with AutoPatcher running in the host OS at 100% CPU or is it only the virtual machine? I can't be sure but
it looks as if you have some sort of anti virus or other security software running, if so, disable it while AutoPatcher is updating the OS.
Quote

Cristiano's Photo Cristiano 01 Mar 2010

> Maybe it helps or not but the CPU is always too high
that it's an issue from your vm.

> 1. I see that each update has it's installing time (10s ?!) so if an update is faster than that it has to wait that time ?
no. that is just to give the user an idea of the remaining time. that time was true in the past, but now, with really fast machines, that time is very wrong. but when the executable from the update closes, autopatcher moves to the next, doesn't matter if the update has an time to install = 1 hour. also, if the update has an time to install = 1s the deploy time will not be faster just due that

[]s
Quote