41 replies to this topic

[Brito]

Let's see if we can find the culprit!

If it takes too long then I guess a binary trial&error might be a good option.

This can be done by disabling half the folders on your app script list and keep the other half intact.

If it still boots and runs slow, divide again the active folders and retest until you isolate the folder and move onto individual script selection.

As you progress, the wait time to finish a build should also decrease.

-----

It's a time consuming goal but it might help shed some light on this matter.

Good luck.




--------------

Forgot mentioning one thing that I noticed before. Sometimes when large portions of registry data are imported onto the target registry they will contain entries that are valid on the OS where the snapshot was taken but contain invalid parameters on the running PE. This might hog down the entire operative system as the kernel tries to use them.

[sanbarrow]

Sorry sanbarrow, but the programers you're talking about here, are we, the script developers!
So i think your analysis does not quite fit.

I know that you are the programmers and I still think it applies.
I am pretty sure that some of the stuff you load at boot-time can as well be loaded at app-start-time.
I am also pretty sure that much of the registry stuff you add at built or boot-time can also be loaded at app-start-time.

This will not make a difference if your build is small and only has a few apps.
It makes a big difference for big builds with Gigabytes of apps.

[MedEvil]

I know that you are the programmers

Ooops, sorry for including you into the script developers!

[sanbarrow]

Ooops, sorry for including you into the script developers!

No problem - I have been accused for worse things

[MedEvil]

If it takes too long then I guess a binary trial&error might be a good option.

Already had a better idea, i hope.
I intend to scan the scripts tomorrow for loadhive syssetup.hiv. This should be the only point where any script can cause this kind of havoc.
Any pointers?

Forgot mentioning one thing that I noticed before. Sometimes when large portions of registry data are imported onto the target registry they will contain entries that are valid on the OS where the snapshot was taken but contain invalid parameters on the running PE. This might hog down the entire operative system as the kernel tries to use them.

Should i read this as, don't worry abaut api scripts or as watch out for buggy scripts?

[Brito]

I intend to scan the scripts tomorrow for loadhive syssetup.hiv. This should be the only point where any script can cause this kind of havoc.
Any pointers?

Are you sure that is simpler?

All app scripts load hives to add shortcuts so you won't be able to bulk test them but if you want to follow this route, I also suggest to look for .reg files attached inside the script since they are the ones that add the bulkier portion of registry data.

Should i read this as, don't worry abaut api scripts or as watch out for buggy scripts?

It's impossible to know what you should worry about since both can be responsible or neither of them and something else be involved. In case of doubt, it has helped me in the past to perform a binary trial to learn more about the conditions to replicate the bug.

[MedEvil]

All app scripts load hives to add shortcuts so you won't be able to bulk test them but if you want to follow this route, I also suggest to look for .reg files attached inside the script since they are the ones that add the bulkier portion of registry data.

I very much doubt that any script developer was ever that drunk to add shortcuts in the registry!
Guess you were thinking about file associations.
Those are fortunately not in syssetup.hiv. There are only services and drivers.

But the idea with the reg files.




edit:
NOT syssetup.hiv! setupreg.hiv! Moron!!!

[pscEx]

How do you do that? The last time i had to reinstall XP was because my HDD said bye bye and that too quickly!

Of course a daily backup of all important data.
Second: For all my systems I have exchangable HDD frames. So I just make a new install onto a fresh drive.
The old drive is mounted for some weeks. And whenever I need an app, I install it and copy the data from the mounted old drive.

Peter

[pscEx]

I intend to scan the scripts tomorrow for loadhive syssetup.hiv. This should be the only point where any script can cause this kind of havoc.
Any pointers?

Maybe this can help scanning.

Peter

[Brito]

Beware, can scanProject interpret "reg_add" app script entries as well?

[MedEvil]

Maybe this can help scanning.

How would this help in this case, it only finds duplicates, doesn't it?
Anyway, here's my list of candidates.
- GImageX.script(58): Hive_Load,HKLM
- HDM8.script(141): Hive_Load,HKLM
- Sysinternals Suite.script(213): Hive_Load,HKLM
- WinImage.Script(182): [EncodedFile-WinImage-filedisk.reg]
- PefMon_v002.script(46): RegHiveLoad,"Tmp_setupreg_hiv","%TargetDir%\i386\System32\setupreg.hiv"

Of course a daily backup of all important data.....

I was more referring to:

After reinstall the previously 'endless' boot time is going down to some seconds.
And then, from week to week, it is increasing again ...)

[pscEx]

Beware, can scanProject interpret "reg_add" app script entries as well?

This is where the program looks for:

cRW = 'RegWrite,';

  cRW1 = 'Reg_add,';

  cEnCoded = 'EncodedFile-';

Peter

[pscEx]

How would this help in this case, it only finds duplicates, doesn't it?

If you do not check 'Hide unique' and 'Suspicious only' it shows ALL reg entries.

Peter

[MedEvil]

If you do not check 'Hide unique' and 'Suspicious only' it shows ALL reg entries.

All reg entries from over a hundred app.scripts? That's like looking for a needle in a hay stack by hand! I prefer using a magnet.

[pscEx]

All reg entries from over a hundred app.scripts? That's like looking for a needle in a hay stack by hand! I prefer using a magnet.

How do you compare manually?
If you tell me the algorithm, I include a filter 'Show Medevil's bad boys only'

But here as always: Nobody forces you to use my app.

Peter

[MedEvil]

But here as always: Nobody forces you to use my app.

Thank you very much!

I used Textpad to search for .reg;setupreg.hiv;Hive_Load,HKLM in the new scripts. That should give me a complete list of all scripts fiddeling with services and drivers.

A project with just the suspects yielded as result already the unusualy high cpu strain. But the thinking pause before accessing a drive is barely there.

[MedEvil]

While sking today, i realized that i commited a cardinal sin.
I wasted earlier today pointlessly perfectly good time, by looking for bugs in scripts, i don't even intend to use!

So no more checking from my side, unless the bug happens to be in a script that makes its way into NaughtyPE.