In my storage filter driver I need to create (and return to caller via custom IOCTL) a drive list, showing drives on the system, with their related interface type (ATA/SATA/USB, etc.), as well as Primary and Secondary Port Base for the ATA/SATA register files, and master/slave if ATA.
I have done this in the past via Hardware PCI Enum, followed by inquiry, but that is just painful.
All of the above information has obviously been acquired by the OS Pnp, drivers, etc.
Does anyone have a suggested method that will allow me to find these attributes from my storage filter driver in a more simple and direct fashion.
No kernel mode APIs to do this.
User mode APIs:
- IOCTL_SCSI_GET_ADDRESS for master/slave on ATA - one of the values in 0
for Master and 1 for Slave
- CM_xxx APIs to get the port base
- the notion of Primary and Secondary just does not exist in SATA Enhanced
mode on non-Intel chipsets or on RAID chips.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> In my storage filter driver I need to create (and return to caller via custom
IOCTL) a drive list, showing drives on the system, with their related interface
type (ATA/SATA/USB, etc.), as well as Primary and Secondary Port Base for the
ATA/SATA register files, and master/slave if ATA.
>
> I have done this in the past via Hardware PCI Enum, followed by inquiry, but
that is just painful.
>
> All of the above information has obviously been acquired by the OS Pnp,
drivers, etc.
>
> Does anyone have a suggested method that will allow me to find these
attributes from my storage filter driver in a more simple and direct fashion.
>
Thanks for your info thus far.
By Primary and Secondary Port base, I was referring to the following:
ATA/SATA drives have two ranges of port addresses. In legacy mode on the first ATA channel it is 0x1F0-0x1F7 for the first range, and 0x3F0-0x3F3 for the second range. In native mode however, the port base addresses are not fixed, and can be configured for any valid port range by PCI.
I am looking for a generic solution to finding out this information. It does not require Kernel APIs, but that would be helpful.
How do I find a) the first port range base address, second port address range base, abd b) type of interface (ATA or SATA), and C) type of device (ATA or ATAPI).
I had presumed that kernel APIs would be most likely, but it is not required.
xxxxx@timestore.net wrote:
By Primary and Secondary Port base, I was referring to the following:
ATA/SATA drives have two ranges of port addresses. In legacy mode on the first ATA channel it is 0x1F0-0x1F7 for the first range, and 0x3F0-0x3F3 for the second range. In native mode however, the port base addresses are not fixed, and can be configured for any valid port range by PCI.
I am looking for a generic solution to finding out this information. It does not require Kernel APIs, but that would be helpful.
How do I find a) the first port range base address, second port address range base, abd b) type of interface (ATA or SATA), and C) type of device (ATA or ATAPI).
I had presumed that kernel APIs would be most likely, but it is not required.
Nope, that information is simply not available, because it isn’t of any
use. Users don’t care, applications don’t care, drivers don’t care.
One way to do this is to troll the registry. If you look in
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System, I think you can find at
least part of what you seek. On my system,
MultifunctionAdapter\9\DiskController\0 represents my ATA controller.
The “Configuration Data” key is a resource descriptor which shows I/O
port 3F0 for 8 bytes.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks for the tips. Examining my system more closely, it looks like I need to parse the info in HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\RESOURCEMAP\PnP Manager\PnpManager
Obviously, I need this information, or this topic would not have come up.
I live in the world of Computer Forensics (looking for evidence of criminal or terrorist activity on Computers - often well hidden or encrypted or both). Sometimes we have unusual needs that are extremely difficult to explain. Few care if a drive supports HPA, for example (and very few even know what it is or how to access this hidden and protected partition on a drive). That does not mean that the capability is not important. Just as rootkits do not obey the rules, sometimes unusual approaches are required by us to defeat them. This is not an area where papers ever get published. Sorry I can’t be more specific in a public forum, but some of the details are classified.
As explained previously, I know how to do this the hard way, and it works. I am just looking for the “right” or "best’ way, meaning more friendly to the Windows OS, defined interfaces, etc.