[naaloh]

I have a registry backup from a WinME machine. I want to know which PCI device was in which slot at the time of the backup being made. Would anyone be so kind as to tell me which keys I should examine to determine this?

Thanks in advance.

This post has been edited by naaloh: 18 February 2013 - 07:55 AM

[TmEE]

You only get what devices there are, but not in what slots they are. The device listing is in HKEY_LOCAL_MACHINE/Enum/PCI

[jaclaz]

TmEE, on 18 February 2013 - 09:21 AM, said:

You only get what devices there are, but not in what slots they are. The device listing is in HKEY_LOCAL_MACHINE/Enum/PCI

Windows 98's do not provide the key "locationinformation", but does Me behave like that as well?
I am asking because Windows 2000 does show it, and Me - when it comes to drivers/devices - tends to be similar to 2K.

jaclaz

This post has been edited by jaclaz: 18 February 2013 - 10:35 AM

[CharlotteTheHarlot]

I just might be able to help with this. After some searching in my ancient notes I found some snapshots of an experiment I did ( about 13 years ago! ) moving a modem to different PCI slots on an MSI motherboard using Win98se.

But first a digression! ... Let me explain what I deduced about how a motherboard works in concert with the Win9x registry from experimental trial and error. I believe that hardware device information is entered into the registry by CfgMgr32.dll at Windows Install, during the PnP phase at bootstrap, Add/Remove a device, when INF files are executed, when Device Manager or the kernel specifically calls it and perhaps at other times as well

Using the IDE bus as an example ( limiting this to "Type80" for brevity but "Type47" seems interchangeable ), moving a HDD among the four possible positions ( PM PS SM SS ) results in four different key names ( subvalues not shown ) ...

[HKEY_LOCAL_MACHINE\Enum\Esdi\Generic_IDE__Disk_Type80_\Mf&Child0000&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0100]
[HKEY_LOCAL_MACHINE\Enum\Esdi\Generic_IDE__Disk_Type80_\Mf&Child0000&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0110]
[HKEY_LOCAL_MACHINE\Enum\Esdi\Generic_IDE__Disk_Type80_\Mf&Child0001&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0100]
[HKEY_LOCAL_MACHINE\Enum\Esdi\Generic_IDE__Disk_Type80_\Mf&Child0001&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0110]

Which I decode as follows ...

; PM ... Primary Master ..... Child0000 ... Func_0100
; PS ... Primary Slave ...... Child0000 ... Func_0110
; SM ... Secondary Master ... Child0001 ... Func_0100
; SS ... Secondary Slave .... Child0001 ... Func_0110

This is important because Windows is keeping track of the four possible positions as separate entities. Hardware seems to be utilized from a positional basis. Continuing this example, each specific position on either IDE channel is hard-coded into the registry key name, and is necessary because of the way the two "ASD" keys work. These two keys to the best of my knowledge ( which means trial and error because this information is really sparse ) are critical to system startup and I believe the contents are executed directly in sequential order by the kernel in Win9x ( like CONFIG.SYS in plain DOS ). Their purpose ...

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{9b4e7760-3196-11cf-97ea-00aa0034319d}]
;;; These devices are Enumerated

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{cf2524c0-29ae-11cf-97ea-00aa0034319d}]
;;; These devices are Started

Most devices appear in both locations, but some are only seen in the latter ( I can't recall if any were only "Enumerated" ). This is where I did my hardware debugging ( and I learned that I could simply hand-edit the entries myself and import custom settings to "move" hardware around at will and some other tricks ). When a device would not work I would look here to see if the entries were correct and if it "Enumerated" and "Started". There are some more things to the "ASD" keys, and there are more than two, but that's probably beyond the current scope of this thread.

Okay, now here are the 4 possible ways a given HDD is later "Enumerated" and "Started" ( again: defined by bus location only, they are not identified by serial like NT is, in other words Win9x starts whatever HDD happens to be in that position ) ...

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{9b4e7760-3196-11cf-97ea-00aa0034319d}]
; Enumerate HDD Type 80 on PM ...
"Esdi\\Generic_IDE__Disk_Type80_\\Mf&Child0000&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0100"=hex:00
; Enumerate HDD Type 80 on PS ...
"Esdi\\Generic_IDE__Disk_Type80_\\Mf&Child0000&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0110"=hex:00
; Enumerate HDD Type 80 on SM ...
"Esdi\\Generic_IDE__Disk_Type80_\\Mf&Child0001&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0100"=hex:00
; Enumerate HDD Type 80 on SS ...
"Esdi\\Generic_IDE__Disk_Type80_\\Mf&Child0001&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0110"=hex:00

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{cf2524c0-29ae-11cf-97ea-00aa0034319d}]
; Start HDD Type 80 on PM ...
"Esdi\\Generic_IDE__Disk_Type80_\\Mf&Child0000&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0100"=hex:00
; Start HDD Type 80 on PS ...
"Esdi\\Generic_IDE__Disk_Type80_\\Mf&Child0000&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0110"=hex:00
; Start HDD Type 80 on SM ...
"Esdi\\Generic_IDE__Disk_Type80_\\Mf&Child0001&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0100"=hex:00
; Start HDD Type 80 on SS ...
"Esdi\\Generic_IDE__Disk_Type80_\\Mf&Child0001&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0110"=hex:00

If you look closely you see how incredibly simple the mechanism is that the system uses to "call" those keys, it merely repeats the actual registry key name ( collapse the double "\\" escaped backslashes ) as value names and ends it with "=hex:00" value data, which indicates "okay" and "no problem"..

If these were optical drives, the strategy is exactly the same but they appear under different key names, such as \Enum\Scsi\.

Important: the official comment for those two keys is actually "Problem"="Enumerating a Device" and "Problem"="Starting a Device", but my trial and error suggests that that is only part of the story. When a device fails, indeed the entry is modified from "hex:00" to something else, but this is long after the fact. These two keys apparently are the Win9x equivalent of CONFIG.SYS where all entries are executed in order. Removing an entry effectively removes the device. Moreover, I noticed that the system bootstrap ( the Windows cloud screen with the animated bar ) is quicker when the entries are deleted for items that do not physically exist, which makes sense because it is trying to handshake an empty location or worse, a non-terminated bus. So when I see a system hang on the "Cloud Screen" I normally would audit the "ASD" keys for dead entries for ones that point to the wrong position.

So that ends my rough overview of how I believe the Win9x kernel "CONFIG.SYS procedure" works. There are some major differences in how the NT Windows versions operate and I never really got a clear handle on it. Win9x works relatively simply, almost exactly like DOS and CONFIG.SYS. Back to the current topic ...

So I set about finding some corresponding snapshots for something in the PCI slots, and I got lucky with a well documented test complete with registry snapshots before and after moving a WinModem to each PCI slot position, and I even noted the corresponding BIOS hardware information as seen by HwInfo ( 3rd party hardcore system information ). Here it is with the changes shown, the duplicate information between tests removed ...

;;; this is from a WinModem in TOP SLOT (#1) ... HWINFO: Irq9 PCI Device Number: Bus: 1, Device: 0, Function: 0
[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\00f000]
; dupes under here
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{9b4e7760-3196-11cf-97ea-00aa0034319d}]
; Entry under "Enumeration" key not always present ( maybe this modem only needs to be "Started"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{cf2524c0-29ae-11cf-97ea-00aa0034319d}]
"Pci\\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\\00f000"=hex:00

;;; this is from a WinModem in MIDDLE SLOT (#2) ... HWINFO: Irq11 PCI Device Number: Bus: 1, Device: 1, Function: 0
[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\08f000]
; dupes under here
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{9b4e7760-3196-11cf-97ea-00aa0034319d}]
; Entry under "Enumeration" key not always present ( maybe this modem only needs to be "Started"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{cf2524c0-29ae-11cf-97ea-00aa0034319d}]
"Pci\\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\\08f000"=hex:00

;;; this is from a WinModem in BOTTOM SLOT (#3) ... HWINFO: Irq3 PCI Device Number: Bus: 1, Device: 2, Function: 0
[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\10f000]
; dupes under here
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{9b4e7760-3196-11cf-97ea-00aa0034319d}]
; Entry under "Enumeration" key not always present ( maybe this modem only needs to be "Started"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{cf2524c0-29ae-11cf-97ea-00aa0034319d}]
"Pci\\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\\10f000"=hex:00

Distilled down for easier comparison and readability ...

[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\00f000]
[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\08f000]
[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\10f000]

What I would conclude from those tests is that the PCI slots are definitely serialized with that 6-digit hex number added as a registry subkey ( e.g., \00f000] ), and the corresponding mapping is ...

00f000 ...... TOP SLOT (#1) ... PCI Device Number: Bus: 1, Device: 0, Function: 0
08f000 ... MIDDLE SLOT (#2) ... PCI Device Number: Bus: 1, Device: 1, Function: 0
10f000 ... BOTTOM SLOT (#3) ... PCI Device Number: Bus: 1, Device: 2, Function: 0

If there was a 4th, 5th, 6th PCI slot in that motherboard we might assume it would merely increment in the same fashion ...

[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\00f000]
[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\08f000]
[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\10f000]
[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\18f000]
[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\20f000]
[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\28f000]

Also note that in the test data above, the ASD key "starts" the associated key depending on which slot the modem was in.

To the OP, naaloh ... if you still have access to that machine, you can determine this for yourself by doing full registry exports with the device in different slots. You may want to first remove the device ( although it may not remove all entries ) and take a preliminary snapshot with nothing and then proceed with a separate export after installing it and after each time it is moved. Then WINDIFF can tell you everything you need to know. It's the only sure way to decode the positions with 100% certainty.

P.S. Note that I disregarded the IRQs used by the modem. At least in Win9x and as long as the motherboard works correctly the actual IRQs are fungible ( although there are many motherboards with strange designs that only allow certain IRQs to certain slots ). I am disregarding them in this case because they are not noted in the registry, this is one difference I believe in the NT kernel but I really cannot say for sure. For all practical purposes, the IRQs have little to do with Win9x and this can be proven if you ever tried to manage them from Device Manager which has little facility for successfully adjusting them. The BIOS does the juggling and stores them in CMOS ( which can be dumped to a file and examined ). If in a hypothetical BIOS you could simply change the IRQ from 9 to 11 ( assuming free ), the registry wouldn't know and wouldn't care. This is to the best of my knowledge, YMMV, because I obviously haven't seen every possible eventuality.


EDIT: clarity, typos

This post has been edited by CharlotteTheHarlot: 18 February 2013 - 11:04 PM

[naaloh]

It's nice to see so many replies with so much information, I do appreciate this

Upon examining the contents of the "HKEY_LOCAL_MACHINE/Enum/PCI" key I came to the same conclusion as CharlotteTheHarlot, i. e. that the number of the slot can be determined by the hex digit subkey. In my case there are the following subkeys.
000800 - Video Card , both the one present at the time of the backup and the one installed before that, they were actually in the AGP slot, not PCI
30F000 - DVB Card
38F000 - Sound Card
48F000 - Network Card, it was removed before backup
48F000, 49F000, 4AF000 - USB2.0 Controller, to the best of my recollection, it was indeed installed in place of the removed network card
50F000 - Modem
58F000 - IEEE 1394 Controller

This could be translated into
AGP - Video Card
PCI1 - DVB Card
PCI2 - Sound Card
PCI3 - USB2.0 Controller, previously Network Card
PCI4 - Modem
PCI5 - IEEE 1394 Controller
Which is plausible, because as far as I remember, IEEE 1394 Controller was, indeed at the bottom, however, it's strange that there is no 40F000 subkey and the USB2.0 Controller has three different subkeys. The latter is probably due to the controller being a composite device, but I see no explanation for the former.

CharlotteTheHarlot, on 18 February 2013 - 07:02 PM, said:

To the OP, naaloh ... if you still have access to that machine, you can determine this for yourself by doing full registry exports with the device in different slots.

I do have access to it, but it's running under WinXP now. To ensure I was right in my interpretation, I could place devices in the order I deduced, install WinME and see it the results are the same.

[CharlotteTheHarlot]

Just to quickly add to what I said about IRQs above, Win9x does have its own built-in mapping table, and has several other ones, note this picture from Device Manager ( I found in Google Images and note it is sourced from right here at MSFN ) ...

Spoiler

( original )

... but I stand by what I said, the facility for controlling them is practically useless, the BIOS seems to have absolute priority and the ability to select them from Windows just sucks. If you have a Win9x machine loaded with PCI cards and every other onboard function enabled you are in a world of hurt unless the motherboard gives you really granular control over IRQ, Memory and I/O address settings.

naaloh, on 19 February 2013 - 02:47 AM, said:

Which is plausible, because as far as I remember, IEEE 1394 Controller was, indeed at the bottom, however, it's strange that there is no 40F000 subkey and the USB2.0 Controller has three different subkeys. The latter is probably due to the controller being a composite device, but I see no explanation for the former.

Noting what I said above, with Windows having built-in tables of mappings, I imagine that also includes a table for this use. So it is likely that those hex values we have noted for identification in registry key names are not arbitrary at all. Consequently I wouldn't be surprised that one is missing ( or out of sequence ) I would surmise that it is reserved for a specific device that either you don't have, or for something disabled. For example 40F000 might be for USB 1.0 or some other variant of another device ( existing or not ).

naaloh, on 19 February 2013 - 02:47 AM, said:

CharlotteTheHarlot, on 18 February 2013 - 07:02 PM, said:

To the OP, naaloh ... if you still have access to that machine, you can determine this for yourself by doing full registry exports with the device in different slots.

I do have access to it, but it's running under WinXP now. To ensure I was right in my interpretation, I could place devices in the order I deduced, install WinME and see it the results are the same.

If you ever do the experiment, try to remember to grab a registry export as early as possible before adding any hardware. I got into the habit of installing Windows to a bare metal system whenever possible ( just the C: drive, no opticals, modems, etc ). Then I would add the parts later with registry snapshots and review the differences to see how the hardware tree grows.


EDIT: updated image URL, and again

This post has been edited by CharlotteTheHarlot: 06 May 2013 - 06:14 PM

[Mijzelf]

Quote

I would surmise that it is reserved for a specific device that either you don't have, or for something disabled. For example 40F000 might be for USB 1.0 or some other variant of another device ( existing or not ).

Why are you now switching from a position based key to a function based key? It seems more likely to me that the chipset has support for 7 slots, and only 6 are actually physically installed.

[CharlotteTheHarlot]

Mijzelf, on 19 February 2013 - 04:21 AM, said:

Quote

I would surmise that it is reserved for a specific device that either you don't have, or for something disabled. For example 40F000 might be for USB 1.0 or some other variant of another device ( existing or not ).

Why are you now switching from a position based key to a function based key? It seems more likely to me that the chipset has support for 7 slots, and only 6 are actually physically installed.

Well its not really me switching ( and note all my hedging of "to the best of my knowledge" ) it's the Windows PnP architects.

A certain bus like IDE is clearly position based. The PCI looks a little more complicated, especially because so many things are considered part of it ( see the list the OP has made in #5 ). I think we can fairly use both concepts when describing the methodology for the Win9x PnP strategy.

To make sure we are talking about the same thing, note that the 6 digit hex number is thus far only in reference to PCI devices, the IDE hard drives were done differently. IDE encodes the both device and position right into the root key name ...

[HKEY_LOCAL_MACHINE\Enum\Esdi\Generic_IDE__Disk_Type80_\Mf&Child0000&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0100]
[HKEY_LOCAL_MACHINE\Enum\Esdi\Generic_IDE__Disk_Type80_\Mf&Child0000&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0110]
[HKEY_LOCAL_MACHINE\Enum\Esdi\Generic_IDE__Disk_Type80_\Mf&Child0001&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0100]
[HKEY_LOCAL_MACHINE\Enum\Esdi\Generic_IDE__Disk_Type80_\Mf&Child0001&Pci&Ven_8086&Dev_24db&SubSys_101e147b&Rev_02&Bus_00&Dev_1f&Func_0110]

For PCI devices in real slots CfgMgr first encodes the device as a root key and then hang subkeys off of them to allow for its use in different slots ...

[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01]
[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\00f000]
[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\08f000]
[HKEY_LOCAL_MACHINE\Enum\Pci\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\10f000]

But it still all means the same thing because the entire key is entered as a value name under the ASD keys and is "called" from there as a whole. When it is "called" like this ...

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{cf2524c0-29ae-11cf-97ea-00aa0034319d}]
"Pci\\Ven_11c1&Dev_0441&SubSys_041013e0&Rev_01\\08f000"=hex:00

... it is actually calling Device\Position to be "Enumerated" or "Started". The Device portion of the key name could just as easily have been anything at all, or the hex digit subkeys could just as easily have been part of the root key using the &Child and/or &Func nomenclature of the IDE keys. It's just an arbitrary decision they made, but probably for good reason because of the complexity of the PCI space.

I am guessing that there is a table of hex numbers used to assign positions in the PCI space, which includes both real slots and virtual locations. The real locations on PCI ( at least in my testing ) definitely have positional identification. They appear to have subdivided the virtual locations by function ( Video, Sound, NIC, etc ). It makes sense from a human standpoint, there are humans creating these tables and it would be natural to group them as best as possible.

It's not surprising that there are arbitrary conventions really because this whole "Plug and Pray" thing dates directly back to 1994 with ICM ( Intel Configuration Manager ) and ICU ( ISA Configuration Utility ) which themselves were an evolution of the old PS/2 reference disks ( external 3.5" floppies which held the resource tables used to assign the onboard CMOS ). ICM and later PnP moved all the resource tables onboard the motherboard ( or somewhere in Windows ) and perfected the logic of the CfgMgr32. There was amazing progress made from the 1994 ICM and ICU proto-PnP to the 1995 PnP ( note that the CfgMgr was updated later I believe in every Windows version ). Somewhere in that 1993-1994 timeframe while Chicago was in beta they must have sat down and assigned all these mappings that we still use on Win9x here in 2013, fully 20 years later! Pretty amazing that they foresaw so many different things that far back..

EDIT: clarity

This post has been edited by CharlotteTheHarlot: 19 February 2013 - 05:45 AM