27 replies to this topic

[oriensol]

Hi,

I notice extra lines under Enum under Livexp for ftdisk and dmio:

Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\dmio\Enum]

"0"="Root\\LEGACY_DMIO\\0000"

"Count"=dword:00000002

"NextInstance"=dword:00000002

"1"="ROOT\\dmio\\0000"



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ftdisk\Enum]

"0"="Root\\LEGACY_FTDISK\\0000"

"Count"=dword:00000002

"NextInstance"=dword:00000002

"1"="ROOT\\ftdisk\\0000"

While I do see/understand entries for Root\dmio and Root\ftdisk, I don't see why the LEGACY_FTDISK and LEGACY_DMIO entries are being created.

I am not able to see/figure out how/why these are created.

Would appreciate if anyone can shed light on this.

Thanks.

[Wonko the Sane]

You do know WHY a LEGACY kind of entry may be created/needed, don't you?
http://xpregistry.tvn.hu/xpr0047.html



Wonko

[oriensol]

Thanks for the link

But, to rephrase the question, while these devices/drivers don't end up having the LEGACY_ entries in regular XP, they are created ONLY in the PE. The other entries are those from under ENUM\ROOT (like dmio or ftdisk), which are understandable.

If you notice carefully, even the picture (figure 7.21) in the link provided has dmio and ftdisk but definitely no LEGACY_DMIO at least (as we can see that the LEGACY_DMBOOT is followed by LEGACY_DMLOAD).

[Wonko the Sane]

But, to rephrase the question, ...

Well, this is ANOTHER question...



Wonko

[oriensol]

Well , it is a clarification (as you can observe that the title clearly says the question is about PE1/Livexp and not XP).

The reason I am raising this question, is to verify if 'not having these entries' would help in some of the disk management/partition not recognized, etc. problems. I am ignorant, if that (i.e., avoiding these entries) would help or not - again talking only of Livexp. I thought it is at least worth a try. Incidentally, in pe3 as we don't see dmio/ftdisk (replaced by volmgr* from what I understand), things seem better.

[Wonko the Sane]

Well , it is a clarification (as you can observe that the title clearly says the question is about PE1/Livexp and not XP).

Which is obviously the reason why you posted it in:
Boot Land > Groups > Windows Support > Windows 2K/XP/2003

I see.

The question (the new one ) is:

Why in "normal" XP there are NO LEGACY type registry entries for dmio and ftdisk, whilst in LiveXP these keys are created?

Wonko

[oriensol]

The idea was that I would have a better shot (in this part of the forum) at getting someone knowledgeable about xp drivers to explain what is happening.

If it turns out to be a pure Livexp problem, the admins can probably move it to the Livexp section.

[MedEvil]

The reason I am raising this question, is to verify if 'not having these entries' would help in some of the disk management/partition not recognized, etc. problems.

What issues are you referring to?

About PE and drivers in general.
XP has more than 1 way to load a driver and PE even adds to that.
That however does not stop some developers, to make extra sure a driver gets loaded, by writing it into every possible loading routine.
Another problem is, that PE1.x unlike later PE did evolve, which means, as with everything that evolves, that it caries lots of old, outdated, superseded junk with it.

Easiest way to see, if removing those entries, will fix your issues, is to simple try it.

[oriensol]

@MedEvil

(Another hidden question is) how do you eliminate the entries, which magically appear when the PE boots - they DON'T exist before the boot! (note the phrase -not sure how/why they are created )

[Sha0]

oriensol: Leave the entries. For your problem, check that those services are actually started in the PE with sc query dmio, etc. Also beware of GPT-formatted disks, which are becoming more common and are not supported by XP. Zeroing out the MBR sector will destroy all partitioning information but allow for the disk to be re-initialized.

[oriensol]

@Shao,

Thanks for the answer. All services are up - no issues there. The question was/is not if the service is 'apparently' working.

But, I still don't understand why the extra entries are created under PE but not in XP (with the same exact hardware/environment). Perhaps there is some hidden thing in Livexp/PE1 .

[Wonko the Sane]

oriensol: Leave the entries. For your problem, check that those services are actually started in the PE with sc query dmio, etc. Also beware of GPT-formatted disks, which are becoming more common and are not supported by XP. Zeroing out the MBR sector will destroy all partitioning information but allow for the disk to be re-initialized.

Just to remind everyone:
http://www.boot-land...?...11600&st=32

I did a couple quick tests with gdisk and it seems like working allright.


Wonko

[Sha0]

oriensol: If you are saying that dmio does not have a LEGACY_ entry in SETUPREG.HIV, but you are seeing one after booting, would you kindly post the output of:

sc qc dmio

?

Wonko the Sane: Agreed. gdisk is nice. You can have a partition with 0xEE type under XP, certainly. I only mention it for the case where folks are using an XP PE to work with disks that might have only one partition, which is that type, but are expecting to see an NTFS partition somewhere since the computer boots to one.

[MedEvil]

@MedEvil

(Another hidden question is) how do you eliminate the entries, which magically appear when the PE boots - they DON'T exist before the boot! (note the phrase -not sure how/why they are created )

LiveXP does a whole lot of fiddeling during boot up.
Check EarlyStarter (service, i think) and runonceex entries.

[oriensol]

@Shao, here're the outputs

In XP

C:\Documents and Settings\Tester>sc qc dmio

[SC] GetServiceConfig SUCCESS



SERVICE_NAME: dmio

		TYPE			   : 1   KERNEL_DRIVER

		START_TYPE		 : 0   BOOT_START

		ERROR_CONTROL	  : 1   NORMAL

		BINARY_PATH_NAME   : \SystemRoot\System32\drivers\dmio.sys

		LOAD_ORDER_GROUP   : System Bus Extender

		TAG				: 13

		DISPLAY_NAME	   : Logical Disk Manager Driver

		DEPENDENCIES	   :

		SERVICE_START_NAME :



C:\Documents and Settings\Tester>sc qc ftdisk

[SC] GetServiceConfig SUCCESS



SERVICE_NAME: ftdisk

		TYPE			   : 1   KERNEL_DRIVER

		START_TYPE		 : 0   BOOT_START

		ERROR_CONTROL	  : 1   NORMAL

		BINARY_PATH_NAME   : \SystemRoot\system32\DRIVERS\ftdisk.sys

		LOAD_ORDER_GROUP   : System Bus Extender

		TAG				: 9

		DISPLAY_NAME	   : Volume Manager Driver

		DEPENDENCIES	   :

		SERVICE_START_NAME :

In PE1/Livexp:

X:\minint\system32>sc qc dmio

[SC] GetServiceConfig SUCCESS



SERVICE_NAME: dmio

		TYPE			   : 1   KERNEL_DRIVER

		START_TYPE		 : 3   BOOT_START

		ERROR_CONTROL	  : 1   NORMAL

		BINARY_PATH_NAME   : system32\DRIVERS\dmio.sys

		LOAD_ORDER_GROUP   : System Bus Extender

		TAG				: 13

		DISPLAY_NAME	   : dmio

		DEPENDENCIES	   :

		SERVICE_START_NAME :



X:\minint\system32>sc qc ftdisk

[SC] GetServiceConfig SUCCESS



SERVICE_NAME: ftdisk

		TYPE			   : 1   KERNEL_DRIVER

		START_TYPE		 : 3   BOOT_START

		ERROR_CONTROL	  : 1   NORMAL

		BINARY_PATH_NAME   : system32\DRIVERS\ftdisk.sys

		LOAD_ORDER_GROUP   : System Bus Extender

		TAG				: 9

		DISPLAY_NAME	   : ftdisk

		DEPENDENCIES	   :

		SERVICE_START_NAME :

The Registry Enum entries are in the first post.

Incidentally, the Start Type is 0 in SETUPREG.HIV in both cases (both drivers! not XP and PE1 ).

Let me clarify once again. The question/issue is NOT about ftdisk or dmio not working under normal circumstances. Everything works fine.

The effort is to understand if the extra (meaning those not created under XP) ENUM entries (under Services section) affect the behaviour when (some) other filter drivers are brought into the picture.

[oriensol]

LiveXP does a whole lot of fiddeling during boot up.
Check EarlyStarter (service, i think) and runonceex entries.

@MedEvil, this happens without any of the special scripts (keeping the bare minimum scripts) - in other words when EarlyStarter, MMC, DrvImpe, DPs Mass Storage, Removable Devices, etc. etc. are all NOT SELECTED.

[Sha0]

@Shao, here're the outputs

In XP

...

SERVICE_NAME: dmio

		TYPE			   : 1   KERNEL_DRIVER

		START_TYPE		 : 0   BOOT_START

...

In PE1/Livexp:

...

SERVICE_NAME: dmio

		TYPE			   : 1   KERNEL_DRIVER

		START_TYPE		 : 3   BOOT_START

...

Hmmm... What might cause the difference in START_TYPE here? We know that NTLDR loads START_TYPE 0 drivers noted in the Registry. We know that SETUPLDR loads drivers based on TXTSETUP.SIF.

...Incidentally, the Start Type is 0 in SETUPREG.HIV in both cases (both drivers! not XP and PE1 )...

I do not believe that SETUPREG.HIV has any influence over what drivers SETUPLDR loads, but could be mistaken. That is, START_TYPE 0 in SETUPREG.HIV would not help the driver to be loaded at boot time, before the system volume is established. Maybe that's incorrect. If correct though, it explains your 3s as well as a late-start service getting a LEGACY_ entry.

Does that help?

[oriensol]

@Shao,

Thanks. We are getting somewhere!

Most of the drivers (rather all the critical ones) with start = 0 get a start type of 3. Examples: disk, firadisk, cdrom, ntfs, fastfat, etc. too.

Interestingly, in PE3, they all get a start value (during the run time of the PE) of 0, as stated in the registry!

Should we be changing the start type in SETUPREG.HIV to, say, 1, in that case, in PE1?

[oriensol]

Tested with start = 1 in setupreg.hiv - still end up with 3 at run time. Those with start type 2 originally, do not change to 3 though!

Can we then say that all drivers that are critical and have a start type of 0 or 1 will end up getting/needing a legacy_ enum entry in PE1? But we do NOT have a LEGACY_ entry for all drivers and DO HAVE for a few of them. ftdisk, dmio, firadisk etc. do not have them (I vaguely remember firadisk having it initially, in the first versions).

So, does this have any implications for PE1?

Thanks.

[Sha0]

BartPE does not produce the LEGACY_xxx entry for dmio. How about looking for all lines with "dmio" in TXTSETUP.SIF?

[karyonix]

Normally a PnP driver is loaded and called when a device that require the driver is discovered.
When all devices that a driver controls is removed, the driver is unloaded automatically.

Legacy driver doesn't participate in PnP device enumeration, it does its job without a Pnp enumerable device.
If a driver is loaded but have no device associated with it in Enum key, Windows creates a fake device with key name LEGACY_xxx automatically. I think legacy device is there to prevent Windows from unloading the driver automatically when there is no PnP enumerable device associated with the driver.
When a driver have LEGACY_xxx device associated with it, it cannot be unloaded and cannot be updated without reboot. The driver file can be replaced but the driver in memory is still the old driver.

[oriensol]

BartPE does not produce the LEGACY_xxx entry for dmio. How about looking for all lines with "dmio" in TXTSETUP.SIF?

I have searched ALL the files - I don't see any file containing the text LEGACY_DMIO (or LEGACY_FTDISK), either in the livexp project/scripts or in the PE1 iso/target or in the (runtime) registry (other than the services\xxx\enum\legacy_xxx entry). That is why I raised this question.

Interestingly, firadisk does NOT get the legacy_ entry (FYI, I am booting the PE1 using firadisk map --mem, so it must be critical), though it looks similar in all other respects to dmio and ftdisk. There is ONLY ONE entry for firadisk (root\firadisk\0000) whereas dmio and ftdisk have two entries each (as stated in the first post) - root\dmio\0000 and root\legacy_dmio\0000, for example.

Thanks for clarifying that BartPE doesn't create this. Perhaps some 'core livexp' person might be able to explain this phenomenon.

[oriensol]

Normally a PnP driver is loaded and called when a device that require the driver is discovered.
When all devices that a driver controls is removed, the driver is unloaded automatically.

Legacy driver doesn't participate in PnP device enumeration, it does its job without a Pnp enumerable device.
If a driver is loaded but have no device associated with it in Enum key, Windows creates a fake device with key name LEGACY_xxx automatically. I think legacy device is there to prevent Windows from unloading the driver automatically when there is no PnP enumerable device associated with the driver.
When a driver have LEGACY_xxx device associated with it, it cannot be unloaded and cannot be updated without reboot. The driver file can be replaced but the driver in memory is still the old driver.

@karyonix

Thanks. If that is the case, since Shao says BartPE doesn't create this, there must be something else also, correct?

And we DO HAVE a device (root\dmio). So, why do we need root\legacy_dmio? It is possible that legacy_dmio is created first as explained by you and root\dmio is discovered later on and added. While that could be the explanation, the question would become, how come root\firadisk is discovered early enough whereas root\dmio is not!

[Sha0]

I have searched ALL the files - I don't see any file containing the text LEGACY_DMIO (or LEGACY_FTDISK), either in the livexp project/scripts or in the PE1 iso/target or in the (runtime) registry (other than the services\xxx\enum\legacy_xxx entry)...

What about just "dmio" without the LEGACY_ prefix? What lines show it up in LiveXP's TXTSETUP.SIF?

...Shao says BartPE doesn't create this, there must be something else also, correct?...

Just to clarify, I tested before saying that.

[oriensol]

Thanks Shao

I meant 'something else must be there' in the Livexp build!

I will test with ControlSet001\Enum\Root\dmio prepopulated in setupreg.hiv and report back after some time.

To answer your question about txtsetup.sif, the only thing I find is:

[BusExtenders.Load]

fltmgr=fltmgr.sys

wimfsf=wimfsf.sys

fbwf=fbwf.sys

pciide=pciide.sys

intelide=intelide.sys

viaide=viaide.sys

cmdide=cmdide.sys

aliide=aliide.sys

mountmgr=mountmgr.sys

ftdisk=ftdisk.sys

dmload=dmload.sys

dmio=dmio.sys

....