Query on Advanced RISC Computing (ARC) naming convention

NTDEV
1

I am new to this, so please bear if doubts look like dumb to you.

From windows internals book I see that Windows follow Advanced RISC
Computing (ARC) naming convention for target boot object (I don’t if I am
using correct jargon here, target boot object is self invented).

They can follow the form

  1. Arcname\multi(W)disk(X)rdisk(Y)partition(Z)
  2. Arcname\scsi(W)disk(X)rdisk(Y)partition(Z)
  3. Arcname\signature(V)disk(X)rdisk(Y)partition(Z)

My doubts are below:–

  1. Who create these objects?
  2. If this is some windows component, then how does it comes to know whether
    it should be multi or scsi or signature based.

Any more information or pointer are also welcome.

Regards
Deepak

2

s/doubt/question/ig

3

Starting with vista, windows no longer uses arc names. Before that, the loader would create the names, hand themoff to the os, the drivers would recreate the names and the os would try to match both sets up to find the boot device.

d

dent from a phpne with no keynoard

From: Deepak Gupta
Sent: November 04, 2010 1:05 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Query on Advanced RISC Computing (ARC) naming convention

I am new to this, so please bear if doubts look like dumb to you.

From windows internals book I see that Windows follow Advanced RISC Computing (ARC) naming convention for target boot object (I don’t if I am using correct jargon here, target boot object is self invented).

They can follow the form

1) Arcname\multi(W)disk(X)rdisk(Y)partition(Z)
2) Arcname\scsi(W)disk(X)rdisk(Y)partition(Z)
3) Arcname\signature(V)disk(X)rdisk(Y)partition(Z)

My doubts are below:–

1) Who create these objects?
2) If this is some windows component, then how does it comes to know whether it should be multi or scsi or signature based.

Any more information or pointer are also welcome.

Regards
Deepak
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

>1) Arcname\multi(W)disk(X)rdisk(Y)partition(Z)

This is the drive which NTLDR accessed using int 13h.

The disk number is int 13h disk number (well, minus 0x80).

  1. Arcname\scsi(W)disk(X)rdisk(Y)partition(Z)

This is the drive which NTLDR accessed using ndbootdd.sys, which is a dumb copy of the controller’s SCSIport miniport (NTLDR contains the emulation of SCSIPORT in it), placed to the root of the boot drive.

  1. Arcname\signature(V)disk(X)rdisk(Y)partition(Z)

Never ever saw this.

  1. Who create these objects?

Windows kernel during its init.

It joins the 2 sets a) all currently present physical disk device objects b) the list of disks from the loader block built by NTLDR. To do row-by-row compare, it reads the MBR signature from the device object and then compare it with the one provided by NTLDR.

The result of join is \ArcName object directory, with symlinks like multi(…) -> \Device\Harddisk1\Partition0.

\SystemRoot is also built this way.

  1. If this is some windows component, then how does it comes to know whether it should be multi or
    scsi or signature based.

I think NTLDR passes this info.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

5

>Starting with vista, windows no longer uses arc names

\ArcName object dir is still here on 2008 non-R2 at least (don’t have Win7 or R2 running at hand).

BOOTMGR no more uses them to identify SystemRoot (it uses mountdev IDs instead), but the names are still here.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

6

Names are present for app compatibility. AFAIK, nothing in box uses them anymore.

d

dent from a phpne with no keynoard

-----Original Message-----
From: Maxim S. Shatskih
Sent: November 05, 2010 4:21 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Query on Advanced RISC Computing (ARC) naming convention

>Starting with vista, windows no longer uses arc names

\ArcName object dir is still here on 2008 non-R2 at least (don’t have Win7 or R2 running at hand).

BOOTMGR no more uses them to identify SystemRoot (it uses mountdev IDs instead), but the names are still here.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

7

>

Windows kernel during its init.

It joins the 2 sets a) all currently present physical disk device objects
b) the list of disks from the loader block built by NTLDR. To do row-by-row
compare, it reads the MBR signature from the device object and then compare
it with the one provided by NTLDR.

The result of join is \ArcName object directory, with symlinks like
multi(…) -> \Device\Harddisk1\Partition0.

MBR signature or BootSector Signature. I assume these sets are linked per
partition basis, right.

Regards
Deepak

8

For the sake of completeness of post.
Forgive me, post is a bit long, but I guess it was necessary to give a
complete view of the problem.

I was getting Bugcheck 7B (INACCESSIBLE_BOOT_DEVICE) after restoring a
volume image on different hardware (Bare metal recovery).

After debugging and from suggestions on NTDEV, I found that in
nt!IopMarkBootPartition call crash is happening and for the reason that
ArcName objects were not populated.

So I went to see if responsible LSI’s raid controller driver is getting
loaded or not.
It was getting loaded but no device’s were being created.

Eventually I did !pci and !pcitree and found out that on the bus on which
raid controller is present, enumeration is not happening on it

!pci 2 ff…
PCI Segment 0 Bus 0x1
00:0 1000:0060.04 Cmd[0047:imb.p.] Sts[0010:c…] LSI RAID Controller
SubID:1014:0364 // LSI RAID
…

!pcitree
Bus 0x1 (FDO Ext
897a9478)
// No devices could be enumerated on Bus 1
No devices have been enumerated on this bus.

So i tried to see the device extension using *!devext address pci* .
And here got to know that pci symbols are incorrect.
Did !sym noisy and tried .reload /o /f pci (even deleted older one) but
still it was not able to resolve the types.

Felt like this must be some RTM build of pci for which MS doesn’t keep
symbols on symbol server.

So I tried to replace pci driver with another pci driver (from another
installation and for which symbols were there).

To my surprise, this time enumeration happened on Bus1 with this new PCI
driver and Arcnames were also populated
and system booted fine, finally.

!pci 2 ff
PCI Segment 0 Bus 0x1
00:0 1000:0060.04 Cmd[0046:.mb.p.] Sts[0010:c…] LSI RAID Controller
SubID:1014:0364 // LSI RAID Controller is on Bus 1

!pcitree
Bus 0x1 (FDO Ext 89bb3820)
0104 00601000 (d=0, f=0) devext 89bb2d28 Mass Storage
Controller/RAID // FDO has been created, devices enumerated on Bus 1
0604 3a488086 (d=1c, f=4) devext 89b01f08 Bridge/PCI to PCI

Below I am pasting the versions of two pci drivers

7: kd> lm v m pci (PCI DRIVER IN VOLUME IMAGE, SYSTEM
DIDN’T BOOT)
start end module name
f741c000 f7432000 pci (pdb symbols)
g:\ossymbols\2k3\pci.pdb\19C18EEF2357412DA2D507D00DFDBD021\pci.pdb
Loaded symbol image file: pci.sys
Image path: pci.sys
Image name: pci.sys
Timestamp: Fri Feb 16 22:59:03 2007 (45D699A7)
CheckSum: 0001E42B
ImageSize: 00016000
File version: 5.2.3790.3959
Product version: 5.2.3790.3959
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft? Windows? Operating System
InternalName: pci.sys
OriginalFilename: pci.sys
ProductVersion: 5.2.3790.3959
FileVersion: 5.2.3790.3959 (srv03_sp2_rtm.070216-1710)
FileDescription: NT Plug and Play PCI Enumerator
LegalCopyright: ? Microsoft Corporation. All rights reserved.

kd> lm v m pci (PCI DRIVER FROM OTHER INSTALLATION
SYSTEM BOOTED FINE)
start end module name
f741c000 f7432000 pci (deferred)
Image path: pci.sys
Image name: pci.sys
Timestamp: Thu Mar 24 18:34:14 2005 (42435C86)
CheckSum: 000211F0
ImageSize: 00016000
File version: 5.2.3790.1830
Product version: 5.2.3790.1830
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft? Windows? Operating System
InternalName: pci.sys
OriginalFilename: pci.sys
ProductVersion: 5.2.3790.1830
FileVersion: 5.2.3790.1830 (srv03_sp1_rtm.050324-1447)
FileDescription: NT Plug and Play PCI Enumerator
LegalCopyright: ? Microsoft Corporation. All rights reserved.

Queries:–

Is this something known with PCI driver or there is still something which I
might be missing here? (someone from Microsoft)

Thanks for bearing.

Regards
Deepak

On Tue, Nov 9, 2010 at 7:11 PM, Deepak Gupta wrote:

>
>
>> Windows kernel during its init.
>>
>> It joins the 2 sets a) all currently present physical disk device objects
>> b) the list of disks from the loader block built by NTLDR. To do row-by-row
>> compare, it reads the MBR signature from the device object and then compare
>> it with the one provided by NTLDR.
>>
>> The result of join is \ArcName object directory, with symlinks like
>> multi(…) -> \Device\Harddisk1\Partition0.
>>
>>
> MBR signature or BootSector Signature. I assume these sets are linked per
> partition basis, right.
>
> Regards
> Deepak
>