13 replies to this topic

[pscEx]

@All

As the second step of HoJoPE I'm currently working on generating the setup hive from scratch.

I know that usually all necessary registry entries are anywhere in the hives???.inf, biosinfo.inf etc.

But there is one key

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Arbiters\AllocationOrder

which seems to be necessary and is not defined in those files.
If I omit it I get a Blue Screen at startup.

Does anybody know where this key is coming from?

Peter

//draugen-mod-edit: changed [quote] to [code=auto:0]

[Alexei]

Does anybody know where this key is coming from?

This key is created by DLL or driver (it's hardcoded in it). I did some search in installed 2003 for unicode strings "Arbiters" and "AllocationOrder", resulted in hal.dll, ntoskernal.dll, and others (sorry, can't copy from TotalCmd's list). This link may be of some help:
http://usenet.p2prea...-t-1287681.html
From the link above: "These registry entries are set by "PnP (Kernel-mode)" component."

Alexei

[Draugen]

@All

As the second step of HoJoPE I'm currently working on generating the setup hive from scratch.

I know that usually all necessary registry entries are anywhere in the hives???.inf, biosinfo.inf etc.

But there is one key

which seems to be necessary and is not defined in those files.
If I omit it I get a Blue Screen at startup.

Does anybody know where this key is coming from?

Peter

Just wondering now: Wich part of the PE registry are you working on? if it is the part defined in setupreg.hiv, most info SHOULD already be inside %source%\i386\setupreg.hiv. And the registry key you reference seems to confirm this. IIRC, [win|bart]PE's HKLM\SYSTEM hive is simply setupreg.hiv, with some extra additions I may be wrong though...

No offense intended: but if the info is already there, why create it all over again? just seems.. unneccesary.

Again, this is not meant to be an attack on your build methods. Really

//martin (who is trying to not be the quarrelsome, stubborn asshat he occasionally is known to be )

( PSC, i also changed the BBcode around the reg entries to [code=auto:0] )

[pscEx]

Just wondering now: Wich part of the PE registry are you working on? if it is the part defined in setupreg.hiv, most info SHOULD already be inside %source%\i386\setupreg.hiv. And the registry key you reference seems to confirm this. IIRC, [win|bart]PE's HKLM\SYSTEM hive is simply setupreg.hiv, with some extra additions I may be wrong though...

No offense intended: but if the info is already there, why create it all over again? just seems.. unneccesary.

Again, this is not meant to be an attack on your build methods. Really

//martin (who is trying to not be the quarrelsome, stubborn asshat he occasionally is known to be )

( PSC, i also changed the BBcode around the reg entries to [code=auto:0] )

You are right, it is setupreg.hiv.

The goal is to write a new setupreg.hiv using only the information provided by the setup cd.
(Same I allready did succesful with generating txtsetup.sif)

My setupreg.hiv is completely new written and works, if I manually insert the arbiters key (or insert in the script by reg / regedit).

But that would be a way I do not want. I do not want to use anything else than my setup CD (no encoded .reg, no BartPE).

Peter

[Draugen]

OK, now I am curious. Just HOW, exactly, are you going about 'writing a new setupreg.hiv based on the setup CD'? Since SETUPREG.HIV already exists, it would seem in-efficient to recreate it from scratch. Especially since it already contains the key you reference in ControlSet001 (which is mapped to CurrentControlSet at boot time). The mapping is based on the <setupreg.hiv>\Select subkey.

just my 0.02 NOK
//martin

[smiley]

Yes . Martin is right. I remeber that in a log of bart pe, it said "copying setuprteg.hiv" or "loading setupreg.hiv" or something like that.

Good work Psc!

[pscEx]

OK, now I am curious. Just HOW, exactly, are you going about 'writing a new setupreg.hiv based on the setup CD'? Since SETUPREG.HIV already exists, it would seem in-efficient to recreate it from scratch. Especially since it already contains the key you reference in ControlSet001 (which is mapped to CurrentControlSet at boot time). The mapping is based on the <setupreg.hiv>\Select subkey.

just my 0.02 NOK
//martin

OOPS

I have been on the wrong way!
I did not have had a careful enough look into the CD and the scripts:
The target setupreg.hiv was rebuilt from an encoded stripped(?) version of the original setupreg.hiv.
So I have to do my own stripping.

Thank you very much.

Peter

Edited by psc, 20 September 2006 - 12:41 PM.

[Alexei]

OOPS
I have been on the wrong way!
I did not have had a careful enough look into the CD and the scripts:
The target setupreg.hiv was rebuilt from an encoded stripped(?) version of the original setupreg.hiv.
So I have to do my own stripping.
Thank you very much.
Peter

Peter, I don't think you were on the wrong way
I believe, MS created setupreg.hiv out of some set of components it has. Peter was trying to discover / reconstruct those initial components. That's good and may be useful in the future to gain better control over booting process. The first that came to my mind is allowing user to boot from "initially unsupported" devices that need F6+floppy during "normal" setup (that's why MS has setup from floppies)
So, what about combining two approaches? I mean taking "hardcoded stuff" from setupreg.hiv and the rest from reconstructed components.

Alexei

[Draugen]

Alexei: However M$ created setupreg.hiv (before they put it on a windows [2000|XP|2003] install CD) is, IMO, rather irrelevant to this discussion But if psc's experiments can lead to a better understanding as to how the PE setupreg.hiv (which has quite a few additions) is created from the default windows-NT-based-install-disk-setupreg.hiv, we're quite a bit closer to reaching nirvana.

Or something

//martin

[pscEx]

Alexei: However M$ created setupreg.hiv (before they put it on a windows [2000|XP|2003] install CD) is, IMO, rather irrelevant to this discussion But if psc's experiments can lead to a better understanding as to how the PE setupreg.hiv (which has quite a few additions) is created from the default windows-NT-based-install-disk-setupreg.hiv, we're quite a bit closer to reaching nirvana.

Or something

//martin

At least one thing to know right now:

PE hive has much more services!
[attachment=354:attachment]

Peter

[Brito]

I like your exec reg tool!

I think you'll find more answers if you compare it against a windows PE 1.x, these services can't be started by txtsetup.sif? (or am I confusing them with drivers)

[Draugen]

@nuno: both services and drivers are listed under the same reg key (HKLM\System\Currentcontrolset\Services)

[pscEx]

I like your exec reg tool!

It is realy not an issue for this forum, but allow me to be a little bit proud. It is not a reg tool, it is a compare tool.
Example: .NET solution

[attachment=355:attachment]

Peter

[Alexei]

It is realy not an issue for this forum, but allow me to be a little bit proud. It is not a reg tool, it is a compare tool.
Example: .NET solution
Peter

Looks good BTW, speaking about registry tools, does anybody know the one that can: 1. show strings hidden in hex entries and search for them, 2. Show class reference in a tree-like form?

Back to the topic, we just need to have scripts for each addition to the setup.reg, though Peter most likely already has them Are they INFs? If yes, they can be converted into a scripts, however one call to setupapi may do the trick, see http://windowssdk.ms...y/ms723901.aspx "RelativeKeyRoot" parameter allows to preserve current registry Note that "legacy INFs" (what's that?) are not supposrted.
Also see:
http://windowssdk.ms...y/ms723524.aspx
http://windowssdk.ms...y/ms723544.aspx

Alexei