ramdisk driver

NTDEV
1

Hello.

I am writing a ramdisk WDM driver that should behave like a “physical disk”, so that disk.sys would recognize at is a disk, and part manager and ftdisk would be able to communicate with it, so I will be able to partition the disk, and do all the operations available on a real physical disk.

I wrote a bus driver, which creates a child PDO device representing a disk.

My problems are:

The device is created, and I can see that disk.sys has created a device

(\device\harddisk1\DRX) that attaches above it in the stack. I can also see it in the device manager as a new disk, but I can not see it through the “disk manager” application.

I have noticed several things:

I get IOCTL_SCSI_GET_ADDRESS several times, but because I am a ramdisk, I don’t have a “scsi” entry in the registry. I have looked into the classpnp source code that comes with the DDK, and it looks like it takes the results of IOCTL_SCSI_GET_ADDRESS, and opens “HKLM\HARDWARE\DEVICEMAP\Scsi\ScsiPortX…” according to the result I return. I have tried to manually add entries through regedit to “HKLM\HARDWARE\DEVICEMAP\Scsi\ScsiPortX…” in order to represent my device, but it fails with “Access Denied”.

Another thing I notice, is that when the device is created, and recognized by the pnp manager as a disk device, it starts getting initialized, I get IRP_MN_START_DEVICE,

After that I get IOCTL_DISK_GET_DRIVE_GEOMETRY, IOCTL_SCSI_GET_ADDRESS, and after that IRP_MN_REMOVE_DEVICE.

I am NOT deleting the PDO for my device with the remove request, because I am emulating a state where the physical disk is STILL PRESENT.

Next a new series of IRPs come like at the first time, but this time after the IRP_MN_START_DEVICE, i don’t get an IRP_MN_REMOVE_DEVICE.

Is this behavior normal? What can I understand from the device removal?

Does anybody know what are the requirements to interact with disk.sys and ftdisk, and being visible in the disk management utility as a disk?

Who manages the to “HKLM\HARDWARE\DEVICEMAP\Scsi\ScsiPortX…” keys? Who creates them?

Thanks -

John

2

“john qwerty” wrote in message
news:xxxxx@ntdev…
>
…
>
> Is this behavior normal? What can I understand from the device removal?
>

Yes, it IS normal, believe it or not. IIRC, this has something to do with
the disk stack getting created, torn down, and re-created during start up.
This sequence has tripped up a lot of people, including me. Sorry, but I
don’t seem to recall the reason this happens (maybe one of our colleagues
from Redmond will fill in the blanks for us here?).

You really have to follow the guidelines written in the DDK about how bus
drivers handle removes very closely. As you said, “since your device wasn’t
going away” you don’t do anything. That’s the right thing.

>
>
>Does anybody know what are the requirements to interact with disk.sys and
ftdisk, and being visible in the
> disk management utility as a disk?
>

Ugh. I’m sorry to say that I don’t know of any place this is written down.
Everyone I know who has done this has just hammered their way through it.

Incidentally, the question you’re asking is a long-standing question from
the development community: “How do you write a proper disk port driver?”
For one reason or another, Microsoft hasn’t yet provided complete
documentation in this area.

>Who manages the to “HKLM\HARDWARE\DEVICEMAP\Scsi\ScsiPortX…” keys? Who
creates them?

IIRC, as the name suggests these are created by the Port Driver.

Peter
OSR

3

You should consider implementing it as a SCSI miniport.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of john qwerty
Sent: Wednesday, August 14, 2002 9:49 AM
To: NT Developers Interest List
Subject: [ntdev] ramdisk driver

Hello.

I am writing a ramdisk WDM driver that should behave like a “physical
disk”, so that disk.sys would recognize at is a disk, and part manager
and ftdisk would be able to communicate with it, so I will be able to
partition the disk, and do all the operations available on a real
physical disk.
I wrote a bus driver, which creates a child PDO device representing a
disk.

My problems are:

The device is created, and I can see that disk.sys has created a device
(\device\harddisk1\DRX) that attaches above it in the stack. I can also
see it in the device manager as a new disk, but I can not see it through
the “disk manager” application.
I have noticed several things:

I get IOCTL_SCSI_GET_ADDRESS several times, but because I am a ramdisk,
I don’t have a “scsi” entry in the registry. I have looked into the
classpnp source code that comes with the DDK, and it looks like it takes
the results of IOCTL_SCSI_GET_ADDRESS, and opens
“HKLM\HARDWARE\DEVICEMAP\Scsi\ScsiPortX…” according to the result I
return. I have tried to manually add entries through regedit to
“HKLM\HARDWARE\DEVICEMAP\Scsi\ScsiPortX…” in order to represent my
device, but it fails with “Access Denied”.

Another thing I notice, is that when the device is created, and
recognized by the pnp manager as a disk device, it starts getting
initialized, I get IRP_MN_START_DEVICE,
After that I get IOCTL_DISK_GET_DRIVE_GEOMETRY, IOCTL_SCSI_GET_ADDRESS,
and after that IRP_MN_REMOVE_DEVICE.
I am NOT deleting the PDO for my device with the remove request, because
I am emulating a state where the physical disk is STILL PRESENT.
Next a new series of IRPs come like at the first time, but this time
after the IRP_MN_START_DEVICE, i don’t get an IRP_MN_REMOVE_DEVICE.

Is this behavior normal? What can I understand from the device removal?

Does anybody know what are the requirements to interact with disk.sys
and ftdisk, and being visible in the disk management utility as a disk?
Who manages the to “HKLM\HARDWARE\DEVICEMAP\Scsi\ScsiPortX…” keys?
Who creates them?

Thanks -
John

You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%

4

When you create your PDO, don’t name it. Use the following instructions
from the DDK while creating your PDO. This should at least get LDM to
see your disk.

Rupin

4.4.1 Naming Device Objects and Registering Device Interfaces

Any driver of a physical, logical, or virtual device to which user-mode
code can direct I/O requests must supply some sort of name for its
user-mode clients. However, PnP drivers do not assign names to device
objects in the same way as drivers in Windows NT(r) 4.0 and earlier.
Instead, PnP drivers should register and enable a device interface,
associated with a GUID, for each device object to which such I/O
requests might be sent.

The following are the steps a device’s drivers must follow to register
an interface:

  1. When the PnP bus driver or other lowest-level driver calls
    IoCreateDevice
    mk:htm> to create the PDO, it should pass the
    FILE_AUTOGENERATED_DEVICE_NAME and FILE_DEVICE_SECURE_OPEN flags, along
    with a NULL string for the device name. In response, Windows(r) chooses
    a unique device name for the PDO.
    2. When intermediate and higher-level drivers (PnP function and
    filter drivers) call IoCreateDevice, they, too, should pass the
    FILE_DEVICE_SECURE_OPEN flag. These drivers must not name their device
    objects.
    3. After creating the device object and attaching it to the device
    stack, the driver should call IoRegisterDeviceInterface
    mk:htm> , passing a device interface class GUID that identifies the
    interface being registered. Typically, the function driver makes this
    call from its AddDevice routine. The system defines GUIDs for common
    device interface classes in the device-specific header files.

    The I/O Manager creates a registry key for the device interface
    and returns a symbolic link to the interface.

    4. If the driver can successfully start the device, it enables the
    interface by calling IoSetDeviceInterfaceState
    mk:htm> , passing the symbolic link. This call should be done as the driver
    handles the PnP IRP_MN_START_DEVICE <javascript:hhobj_1.click>
    request.

    When an application or end user calls a Win32(r) function to connect to
    a printer port, such as LPT1, the Win32 subsystem translates the
    application I/O request into a call to one of the I/O Manager’s system
    services, passing the symbolic link that represents the printer port.

    -----Original Message-----
    From: john qwerty [mailto:xxxxx@hotmail.com]
    Sent: Wednesday, August 14, 2002 12:49 PM
    To: NT Developers Interest List
    Subject: [ntdev] ramdisk driver

    Hello.

    I am writing a ramdisk WDM driver that should behave like a
    “physical disk”, so that disk.sys would recognize at is a disk, and part
    manager and ftdisk would be able to communicate with it, so I will be
    able to partition the disk, and do all the operations available on a
    real physical disk.

    I wrote a bus driver, which creates a child PDO device
    representing a disk.

    My problems are:

    The device is created, and I can see that disk.sys has created a
    device

    (\device\harddisk1\DRX) that attaches above it in the stack. I
    can also see it in the device manager as a new disk, but I can not see
    it through the “disk manager” application.

    I have noticed several things:

    I get IOCTL_SCSI_GET_ADDRESS several times, but because I am a
    ramdisk, I don’t have a “scsi” entry in the registry. I have looked into
    the classpnp source code that comes with the DDK, and it looks like it
    takes the results of IOCTL_SCSI_GET_ADDRESS, and opens
    “HKLM\HARDWARE\DEVICEMAP\Scsi\ScsiPortX…” according to the result I
    return. I have tried to manually add entries through regedit to
    “HKLM\HARDWARE\DEVICEMAP\Scsi\ScsiPortX…” in order to represent my
    device, but it fails with “Access Denied”.

    Another thing I notice, is that when the device is created, and
    recognized by the pnp manager as a disk device, it starts getting
    initialized, I get IRP_MN_START_DEVICE,

    After that I get IOCTL_DISK_GET_DRIVE_GEOMETRY,
    IOCTL_SCSI_GET_ADDRESS, and after that IRP_MN_REMOVE_DEVICE.

    I am NOT deleting the PDO for my device with the remove request,
    because I am emulating a state where the physical disk is STILL PRESENT.

    Next a new series of IRPs come like at the first time, but this
    time after the IRP_MN_START_DEVICE, i don’t get an IRP_MN_REMOVE_DEVICE.

    Is this behavior normal? What can I understand from the device
    removal?

    Does anybody know what are the requirements to interact with
    disk.sys and ftdisk, and being visible in the disk management utility as
    a disk?

    Who manages the to
    “HKLM\HARDWARE\DEVICEMAP\Scsi\ScsiPortX…” keys? Who creates them?

    Thanks -

    John

    —
    You are currently subscribed to ntdev as: rupin.mohan@hp.com
    To unsubscribe send a blank email to
    %%email.unsub%%</javascript:hhobj_1.click></mk:></mk:></mk:>
5

I am going to make a little noise here :slight_smile:

It is so remarkably simple to implement a RAMDISK as a SCSI miniport.
You need not be concerned about PDO, PNP and anything else that the
upper layer class drivers provide. The goal of a RAMDISK is to use RAM
to emulate disk sectors. Since the SCSI specification has been
standardized for many years, the CDB interface is rock solid and well
documented and makes implementing a disk type device “brain-dead” easy.

By making your own class driver, you run the risk of some service pack
or hot-fix breaking your code. The SCSI miniport model can be ported
very easy across almost any imaginable platform; just isolate the OS
specific stuff from the generic SCSI RAMDISK specific stuff.

By using a SCSI miniport, you leverage the class driver code that has
been well tested by Microsoft.

Sorry for the rant; I will crawl back in my cave now.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mohan, Rupin
Sent: Friday, August 16, 2002 12:57 PM
To: NT Developers Interest List
Subject: [ntdev] RE: ramdisk driver

When you create your PDO, don’t name it. Use the following instructions
from the DDK while creating your PDO. This should at least get LDM to
see your disk.

Rupin

4.4.1 Naming Device Objects and Registering Device Interfaces

Any driver of a physical, logical, or virtual device to which user-mode
code can direct I/O requests must supply some sort of name for its
user-mode clients. However, PnP drivers do not assign names to device
objects in the same way as drivers in Windows NTR 4.0 and earlier.
Instead, PnP drivers should register and enable a device interface,
associated with a GUID, for each device object to which such I/O
requests might be sent.
The following are the steps a device’s drivers must follow to register
an interface:

  1. When the PnP bus driver or other lowest-level driver calls
    mk:htm> IoCreateDevice to create the PDO, it should pass the
    FILE_AUTOGENERATED_DEVICE_NAME and FILE_DEVICE_SECURE_OPEN flags, along
    with a NULL string for the device name. In response, WindowsR chooses a
    unique device name for the PDO.
    2. When intermediate and higher-level drivers (PnP function and
    filter drivers) call IoCreateDevice, they, too, should pass the
    FILE_DEVICE_SECURE_OPEN flag. These drivers must not name their device
    objects.
    3. After creating the device object and attaching it to the device
    stack, the driver should call
    mk:htm> IoRegisterDeviceInterface, passing a device interface class GUID
    that identifies the interface being registered. Typically, the function
    driver makes this call from its AddDevice routine. The system defines
    GUIDs for common device interface classes in the device-specific header
    files.
    The I/O Manager creates a registry key for the device interface and
    returns a symbolic link to the interface.
    4. If the driver can successfully start the device, it enables the
    interface by calling
    mk:htm> IoSetDeviceInterfaceState, passing the symbolic link. This call
    should be done as the driver handles the PnP IRP_MN_START_DEVICE
    <javascript:hhobj_1.click> request.
    When an application or end user calls a Win32R function to connect to a
    printer port, such as LPT1, the Win32 subsystem translates the
    application I/O request into a call to one of the I/O Manager’s system
    services, passing the symbolic link that represents the printer port.
    -----Original Message-----
    From: john qwerty [mailto:xxxxx@hotmail.com]
    Sent: Wednesday, August 14, 2002 12:49 PM
    To: NT Developers Interest List
    Subject: [ntdev] ramdisk driver
    Hello.

    I am writing a ramdisk WDM driver that should behave like a “physical
    disk”, so that disk.sys would recognize at is a disk, and part manager
    and ftdisk would be able to communicate with it, so I will be able to
    partition the disk, and do all the operations available on a real
    physical disk.
    I wrote a bus driver, which creates a child PDO device representing a
    disk.

    My problems are:

    The device is created, and I can see that disk.sys has created a device
    (\device\harddisk1\DRX) that attaches above it in the stack. I can also
    see it in the device manager as a new disk, but I can not see it through
    the “disk manager” application.
    I have noticed several things:

    I get IOCTL_SCSI_GET_ADDRESS several times, but because I am a ramdisk,
    I don’t have a “scsi” entry in the registry. I have looked into the
    classpnp source code that comes with the DDK, and it looks like it takes
    the results of IOCTL_SCSI_GET_ADDRESS, and opens
    “HKLM\HARDWARE\DEVICEMAP\Scsi\ScsiPortX…” according to the result I
    return. I have tried to manually add entries through regedit to
    “HKLM\HARDWARE\DEVICEMAP\Scsi\ScsiPortX…” in order to represent my
    device, but it fails with “Access Denied”.

    Another thing I notice, is that when the device is created, and
    recognized by the pnp manager as a disk device, it starts getting
    initialized, I get IRP_MN_START_DEVICE,
    After that I get IOCTL_DISK_GET_DRIVE_GEOMETRY, IOCTL_SCSI_GET_ADDRESS,
    and after that IRP_MN_REMOVE_DEVICE.
    I am NOT deleting the PDO for my device with the remove request, because
    I am emulating a state where the physical disk is STILL PRESENT.
    Next a new series of IRPs come like at the first time, but this time
    after the IRP_MN_START_DEVICE, i don’t get an IRP_MN_REMOVE_DEVICE.

    Is this behavior normal? What can I understand from the device removal?

    Does anybody know what are the requirements to interact with disk.sys
    and ftdisk, and being visible in the disk management utility as a disk?
    Who manages the to “HKLM\HARDWARE\DEVICEMAP\Scsi\ScsiPortX…” keys?
    Who creates them?

    Thanks -
    John
    —
    You are currently subscribed to ntdev as: rupin.mohan@hp.com
    To unsubscribe send a blank email to %%email.unsub%%
    —
    You are currently subscribed to ntdev as: xxxxx@storagecraft.com
    To unsubscribe send a blank email to %%email.unsub%%</javascript:hhobj_1.click></mk:></mk:></mk:>