Windows IOCTL Reference |
Extracted from DDK 7.1.0 |
Entries: 760 |

An IEEE 1394 driver uses the IRP_MJ_DEVICE_CONTROL IRP, withIoControlCodeIOCTL_1394_CLASS, to communicate with the bus driver. The driver has access to all operations provided by the IEEE 1394 bus and its host controller through this request.

An IEC-61883 client driver uses theIRP_MJ_INTERNAL_DEVICE_CONTROLIRP withIoControlCodeIOCTL_61883_CLASS to communicate with 1394 driver stack using the IEC-61883 protocol. The driver has access to all operations provided by the IEC-61883 protocol driver through this request.

A driver for a device can use the IOCTL_ACPI_ASYNC_EVAL_METHOD device control request to asynchronously evaluate an ACPI control method that is supported by the device. The driver should callIoBuildDeviceIoControlRequestand pass the following input and output parameters to build this request.

A driver for a device can use the IOCTL_ACPI_EVAL_METHOD device control request to synchronously evaluate an ACPI control method that is supported by the device. The driver should callIoBuildDeviceIoControlRequestand pass the following input and output parameters to build this request.

The IOCTL_ACPI_ENUM_CHILDREN device control request can be used to enumerate the path and name of devices or named child objects in the ACPI namespace of the device to which this request is sent. A driver should callIoBuildDeviceIoControlRequestand pass the following input and output parameters to build this request.

A driver for a device can use the IOCTL_ACPI_EVAL_METHOD device control request to synchronously evaluate an ACPI control method that is supported by the device. The driver should callIoBuildDeviceIoControlRequestand pass the following input and output parameters to build this request.

A driver for a device can use the IOCTL_ACPI_EVAL_METHOD_EX device control request to synchronously evaluate an ACPI control method that is supported by a child device in the namespace of the device. The driver should callIoBuildDeviceIoControlRequestand pass the following input and output parameters to build this request.

An AV/C subunit driver uses theIRP_MJ_INTERNAL_DEVICE_CONTROLIRP, with theIoControlCodemember set to IOCTL_AVCSTRM_CLASS, to communicate withavcstrm.sys. The driver has access to all operations provided by the AV/C Streaming filter driver (avcstrm.sys) through this request.

The IOCTL_AVC_BUS_RESET I/O control code allows the caller to complete any previous IOCTL_AVC_UPDATE_VIRTUAL_SUBUNIT_INFO and IOCTL_AVC_REMOVE_VIRTUAL_SUBUNIT_INFO control requests that did not use the AVC_SUBUNIT_ADDR_TRIGGERBUSRESET flag. It is available to user mode as well as kernel-mode components through the IRP_MJ_DEVICE_CONTROL dispatch.

The IOCTL_AVC_REMOVE_VIRTUAL_SUBUNIT_INFO I/O control code controls the enumeration of virtual subunits. It is available to user mode as well as kernel-mode components through the IRP_MJ_DEVICE_CONTROL dispatch. For driver-to-driver communication, it is a METHOD_BUFFERED IOCTL, so set the IRP fields accordingly (IrpStack->Parameters.DeviceIoControl.InputBufferLength and Irp->AssociatedIrp.SystemBuffer).

The IOCTL_AVC_UPDATE_VIRTUAL_SUBUNIT_INFO I/O control code controls the enumeration of virtual subunits. It is available to user mode as well as kernel-mode components through the IRP_MJ_DEVICE_CONTROL dispatch. For driver-to-driver communication, it is a METHOD_BUFFERED IOCTL, so set the IRP fields accordingly (IrpStack->Parameters.DeviceIoControl.InputBufferLength and Irp->AssociatedIrp.SystemBuffer).

The IOCTL_BIOMETRIC_CALIBRATE IOCTL directs the driver to perform any necessary steps to calibrate the device for use. Internally, the driver may also collect and return vendor specific calibration data to be analyzed by an application. Vendor-supplied WBDI drivers must support this IOCTL.

The IOCTL_BTH_SDP_SUBMIT_RECORD request allows a profile driver to add an SDP record to the local SDP
server, allowing the client to advertise that a service is available on the local computer. The profile
driver callsIOCTL_BTH_SDP_REMOVE_RECORDto
stop advertising the server on the local SDP server.

The IOCTL_BTH_SDP_SUBMIT_RECORD_WITH_INFO request adds an SDP record to the local SDP server along
with attributes that are not part of the SDP record itself. After this call completes successfully, the
profile driver can advertise that a service is available on the local computer. The profile driver callsIOCTL_BTH_SDP_REMOVE_RECORDto
stop advertising the service on the local SDP server.

Returns the SCSI inquiry data for all devices on a given SCSI host bus adapter (HBA). If the IOCTL is employed in user space, the program must have opened a handle to the HBA, which can be enumerated by various means, such as SetupDixxx calls. You can useIOCTL_STORAGE_QUERY_PROPERTYto find information about a specific device on the HBA. To determine the size of the output buffer that is required, the caller should send this IOCTL request in a loop. Every time that the storage stack rejects the IOCTL with an error message that indicates that the buffer was too small, the caller should double the buffer size.

Queries the device for the first complete session number, the last complete session number, and the last complete session starting address. This request is the same as anIOCTL_CDROM_READ_TOC_EXrequest with a format of CDROM_READ_TOC_EX_FORMAT_SESSION. For more information on the CDROM_READ_TOC_EX_FORMAT_SESSION format, see the description of theFormatmember of theCDROM_READ_TOC_EXstructure.

Queries the target device for the table of contents (TOC), the program memory area (PMA), and the absolute time in pregroove (ATIP). If the media is not a CD-ROM and does not support a TOC, this IOCTL returns information similar to that of a CD-ROM TOC. This is required for compatibility with some legacy initiator environments.

TheIOCTL_CDROM_SEND_OPC_INFORMATIONcontrol code can be used in file systems and other implementations that want to perform the Optimum Power Calibration (OPC) procedure in advance, so that the first streaming write does not have to wait for the procedure to finish. The optical drive performs the OPC procedure to determine the optimum power of the laser during write. The procedure is necessary to ensure quality, but it wears out the media and should not be performed too often.

Returns Region Playback Control (RPC) information for a DVD device, such as whether the player supports the RPC2 standard, the current region code of the player, and the remaining number of times the player's region code can be changed by the user. This IOCTL also indicates the region code of the currently mounted disc. This only works if a DVD is in the drive. TheIOCTL_DVD_READ_KEYoperation should be used to obtain only the device region code. If the drive region has not been set previously (if it is still at factory default) and if the inserted media has a region, the device region will be set to the current media region.

Returns a copy-protection key of the specified type: challenge key, bus key, title key, read RPC key, set RPC key, or disk key. A challenge key or bus key is sent back to the device to complete the related step in a DVD authentication sequence. After the authentication sequence is completed, a title key is used to encrypt and decrypt user data transferred from a DVD disc and a disk key is used to encrypt and decrypt title key data. If the drive region has not been set previously (if it is still at factory default) and if the inserted media has a region, the device region will be set to the current media region.

Sends the specified key to a DVD device -to complete the related step in an authentication sequence. The IOCTL_DVD_SEND_KEY2 request has write access to the device and can send a broader range of key types thanIOCTL_DVD_SEND_KEY.

Sets the adapter to the specified operating mode. Miniport drivers are required to support this nonmodal request because it resets the current mode. The miniport driver must also consider the two high order flags which are used to additionally control the mode set operation. SeeVIDEO_MODEfor further information.

This request retrieves tuple data that is stored in a PC Card's or CardBus card's attribute memory. The caller must specify the number of the socket where the PC Card or CardBus card is inserted, the location of an output buffer, and the number of bytes of tuple data to be read.

The IOCTL_HID_DISABLE_SECURE_READ request cancels anIOCTL_HID_ENABLE_SECURE_READrequest for aHID collection. Only a "trusted" user-mode application (an application withSeTcbPrivilegeprivileges) can successfully use this request. Kernel-mode drivers haveSeTcbPrivilegeprivileges by default, but user-mode applications do not.

The IOCTL_HID_ENABLE_SECURE_READ request enables a secure read for open files of aHID collection. Only a "trusted" user-mode application (an application withSeTcbPrivilegeprivileges) can successfully use this request. Kernel-mode drivers haveSeTcbPrivilegeprivileges by default, but user-mode applications do not.

The IOCTL_HID_GET_MANUFACTURER_STRING request obtains atop-level collection'sembedded string that identifies the manufacturer of the device. The retrieved string is a NULL-terminated wide character string in a human readable format.

The IOCTL_HID_GET_STRING request obtains a manufacturer ID, product ID, or serial number for atop-level collection. The retrieved string is a NULL-terminated wide character string in a human readable format.

The IOCTL_IEEE1284_NEGOTIATE request sets the read and write protocols that are used for a parallel device. This request requires that the parallel port, to which the parallel device is attached, be locked and the parallel device be selected. The system-supplied bus driver for parallel ports negotiates with the parallel device to determine the fastest modes that are supported by both the host chipset and the parallel device from among the modes that are specified by the client. The parallel port bus driver sets the default read and write modes to the negotiated modes.

The IOCTL_INTERNAL_DISCONNECT_IDLE request disconnects the IEEE 1284 operating modes that are set for a parallel device. The system-supplied bus driver for parallel ports sets the default operating mode to IEEE 1284-compatible.

The IOCTL_INTERNAL_GET_MORE_PARALLEL_PORT_INFO request returns information about a parallel port. This information supplements the information that a client obtains by using anIOCTL_INTERNAL_GET_PARALLEL_PORT_INFOrequest. The additional information about the parallel port includes the type of system interface, the bus number, and the interrupt resources used by the port.

The IOCTL_INTERNAL_GET_PARALLEL_PORT_INFO request returns information about a parallel port. The information specifies the resources assigned to the parallel port, the capabilities of the port, and pointers toparallel port callback routines.

The IOCTL_INTERNAL_I8042_KEYBOARD_START_INFORMATION request passes a pointer to a keyboard interrupt object. I8042prt sends this request synchronously to the top of the device stack after the keyboard interrupt object is created. Upper-level filter drivers that need to synchronize their callback operation with the I8042prt keyboard ISR can use the pointer to the keyboard interrupt object. For more information about this request, seeSynchronize the Operation of a Filter Driver with a Device's ISR.

The IOCTL_INTERNAL_I8042_KEYBOARD_WRITE_BUFFER request writes data to the i8042 port controller to control operation of a keyboard device. A filter driver can use this request to control the operation of a keyboard.

The IOCTL_INTERNAL_I8042_MOUSE_START_INFORMATION request passes a pointer to a mouse interrupt object. I8042prt sends this request synchronously to the top of the device stack after the mouse interrupt object is created. Upper-level filter drivers that need to synchronize their callback operation with the mouse ISR can use the pointer to the mouse interrupt object. For more information about this request, seeSynchronize the Operation of a Filter Driver with a Device's ISR.

The IOCTL_INTERNAL_I8042_MOUSE_WRITE_BUFFER request writes data to the i8042 port controller to control operation of a mouse device. An upper-level filter driver can use this request to control the operation of a mouse.

The IOCTL_INTERNAL_MOUSE_DISCONNECT request is completed by Moufiltr with an error status of STATUS_NOT_IMPLEMENTED. (Note that a Plug and Play mouse device can be added or removed by the Plug and Play manager.)

The IOCTL_INTERNAL_PARALLEL_CONNECT_INTERRUPT request connects an optional interrupt service routine and an optionaldeferred port checkroutine to a parallel port. Only kernel-mode drivers can use this request.

The IOCTL_INTERNAL_PARALLEL_DISCONNECT_INTERRUPT request disconnects an interrupt service routine (and an optional deferred port check service routine) that was connected by using anIOCTL_INTERNAL_PARALLEL_CONNECT_INTERRUPTrequest. Only kernel-mode drivers can connect and disconnect an interrupt routine.

The IOCTL_INTERNAL_PARALLEL_PORT_FREE request frees a parallel port. After using a parallel port, a client must free it. Microsoft recommends using the system-suppliedPPARALLEL_FREE_ROUTINEcallback to free a parallel port because there is no functional advantage to using an IOCTL_INTERNAL_PARALLEL_PORT_FREE request to free the port.

The IOCTL_INTERNAL_PARCLASS_CONNECT request returns information about a parallel port and the callback routines that the system-supplied bus driver for parallel ports provides to operate the parallel port.

The IOCTL_INTERNAL_PARCLASS_DISCONNECT request disconnects a client from a parallel device. After disconnecting from a parallel device, a client must not use any information obtained from a previousIOCTL_INTERNAL_PARCLASS_CONNECTrequest.

The IOCTL_INTERNAL_SERENUM_REMOVE_SELF request invalidates the bus relations of the filter DO that are associated with a target PDO. (Physically, this request invalidates the bus relations of the RS-232 port to which the target device is attached.)

TheIOCTL_INTERNAL_USB_RESET_PORTI/O control request is used by a driver to reset the upstream port of the device it manages. After a successful reset, the bus driver reselects the configuration and any alternative interface settings that the device had before the reset occurred. All pipe handles, configuration handles and interface handles remain valid.

WhenCIRClassdiscovers an instance of a CIR Port device as a result of its device interface being enabled,CIRClasswill send a handshake IOCTL (IOCTL_IR_HANDSHAKE) to the newly-created port device object instance. This IOCTL informs the CIR Port driver thatCIRClasshas detected its device.

The IOCTL_IR_RESET_DEVICE request resets the given device. When a device is reset, the port driver cancels all pending transmit and receive IOCTLs. Additionally, the power driver should re-initialize the hardware to the default state.

The IOCTL_IR_USER_CLOSE request is part of basic device communication. This IOCTL is sent fromIRCLASSwhen a user has indirectly closed the port driver. This IOCTL is informational only, enabling the port to do any cleanup that is required when a user closes it.

The IOCTL_IR_USER_OPEN is part of basic device communication. This IOCTL is sent from the class driver when a user has indirectly opened the port driver through IRCLASS. This IOCTL is informational only, enabling the port to do any initialization or bookkeeping that is required to handle requests not directly originating from IRCLASS.

An application can use IOCTL_KS_DISABLE_EVENT to rescind a previous request notification. The application specifies IOCTL_KS_DISABLE_EVENT in theIoControlparameter of a call toKsSynchronousDeviceControl.

An application can use IOCTL_KS_ENABLE_EVENT to request notification of a KS event type, or to determine the events supported by a KS object. The application specifies IOCTL_KS_ENABLE_EVENT in theIoControlparameter of a call toKsSynchronousDeviceControl.

A kernel-mode client can use IOCTL_KS_HANDSHAKE to negotiate an interface between unconnected AVStream pins. The client callsKsSynchronousDeviceControlwith IOCTL_KS_HANDSHAKE and the parameters described below.

An application can use IOCTL_KS_PROPERTY to get or set properties, or to determine the properties supported by a KS object. The application passes IOCTL_KS_PROPERTY with the parameters described below to theKsSynchronousDeviceControlfunction.

An application can use IOCTL_KS_RESET_STATE to return a pin to the state it was in atAcquire-time. The application passes IOCTL_KS_RESET_STATE with the parameters described below to theKsSynchronousDeviceControlfunction.

This IOCTL is used by a user-mode application or kernel-mode driver that requires notification when something of interest happens in the virtual miniport. This IOCTL might be used, for example, when a vendor-specific, time-consuming operation such as device discovery completes.

Support for this IOCTL by the mount manager clients is optional. The mount manager uses this IOCTL to alert the client driver that a persistent name has been assigned to its volume. The input for this IOCTL is the persistent name assigned.

Support for this IOCTL by the mount manager clients is optional. It alerts the mount manager client that a persistent name associated with it has been deleted. The input for this IOCTL is the persistent name that was deleted.

Support for this IOCTL by the mount manager clients is optional. Some mount manager clients are able to keep track of their drive letters across reboots of the system without the help of the mount manager. Such clients can send a suggested drive letter name to the mount manager in response to this IOCTL. The mount manager uses the suggested name if the mount manager's database does not already contain a persistent drive letter name for the client's volume. Otherwise, it ignores the suggestion and uses the drive letter name in its persistent name database.

When a volume arrives in the system, it registers for the MOUNTDEV_MOUNTED_DEVICE_GUID interface class and the mount manager receives a Plug and Play notification (seeMount Manager I/O Control Codesfor a discussion of this process). When the mount manager receives this notification, it queries the client driver that manages the volume for the volume's unique ID. In some cases, however, particularly with clusters, the client notifies the mount manager of the arrival of its volume, but then does not respond when queried for the volume's unique ID. The mount manager keeps these volumes in adead mounted devicelist. Clients can use the IOCTL_MOUNTMGR_CHECK_UNPROCESSED_VOLUMES IOCTL to request that the mount manager rescan its dead mounted device list and make another attempt to query the clients on the list for the unique IDs of their respective volumes.

The mount manager clients can use this IOCTL to request that the mount manager create a persistent symbolic link name for the indicated volume. For a discussion of the various sorts of persistent symbolic links managed by the mount manager, seeSupporting Mount Manager Requests in a Storage Class Driver.

This IOCTL returns triples that consist of a persistent symbolic link name for the volume (that is, a mount point), a unique ID for the volume, and a nonpersistent device name (such as "\Device\HarddiskVolume1") for the volume. The input to this IOCTL is aMOUNTMGR_MOUNT_POINTstructure that contains a single triple.

This IOCTL directs the mount manager to keep a symbolic link active after the Plug and Play manager has given notification that its corresponding volume has gone offline. When the volume goes back online, the mount manager reassigns the symbolic link to the volume. No other volume is allowed to claim the symbolic link while its original owner is offline.

This IOCTL returns triples that consist of a persistent symbolic link name for the volume (that is, a mount point), a unique ID for the volume, and a nonpersistent device name (such as "\Device\HarddiskVolume1") for the volume. The input to this IOCTL is aMOUNTMGR_MOUNT_POINTstructure that contains a single triple.

This IOCTL returns triples that consist of a persistent symbolic link name for the volume (that is, a mount point), a unique ID for the volume, and a nonpersistent device name (such as "\Device\HarddiskVolume1") for the volume. The input to this IOCTL is aMOUNTMGR_MOUNT_POINTstructure that contains a single triple.

This IOCTL allows a client to simulate a Plug and Play device interface arrival notification with the given volume name. If a client does not register a device interface of type MOUNTDEV_MOUNTED_DEVICE_GUID, the mount manager is not alerted of its arrival. However, the client can alert the mount manager of its volume's arrival directly by means of this IOCTL.

An application can use IOCTL_NDIS_QUERY_GLOBAL_STATS to obtain information from a network adapter. The
application passes IOCTL_NDIS_QUERY_GLOBAL_STATS, along with anObject Identifier(OID), in theDeviceIoControlfunction.

An application can use IOCTL_NDIS_QUERY_GLOBAL_STATS to obtain information from a network adapter. The
application passes IOCTL_NDIS_QUERY_GLOBAL_STATS, along with anObject Identifier(OID), in theDeviceIoControlfunction.

The IOCTL_PAR_IS_PORT_FREE request determines if a parallel device's parent parallel port is free at the time the system-supplied bus driver for parallel ports processes the request. This request is provided primarily for user-mode clients.

The IOCTL_PAR_SET_WRITE_ADDRESS request sets an extended capabilities port (ECP) or enhanced parallel port (EPP) write address (channel) for a parallel device. The parallel port bus driver queues this request on a work queue for the parallel device.

The filter-hook driver uses this IOCTL to set up an IRP that the filter-hook driver submits to
the IP filter driver. The filter-hook driver passes this IOCTL along with related parameters in theIoBuildDeviceIoControlRequestfunction to set up the IRP.

The IOCTL_PMI_REGISTER_EVENT_NOTIFY request registers the IOCTL initiator to be notified about a power meter event. When the event occurs, the Power Meter Interface (PMI) completes the IOCTL request and returns information about the event.

The IOCTL_REDIR_QUERY_PATH control code is sent by the multiple UNC provider (MUP) to network redirectors to determine which provider can handle a specific UNC path in a name-based operation, typically an IRP_MJ_CREATE request. This request is referred to as "prefix resolution."

The IOCTL_REDIR_QUERY_PATH_EX control code is sent by the multiple UNC provider (MUP) on Windows Vista or later to network redirectors to determine which provider can handle a specific UNC path in a name-based operation, typically an IRP_MJ_CREATE request. This request is referred to as "prefix resolution."

Returns the address information, such as the target ID (TID) and the logical unit number (LUN) of a particular SCSI target. A legacy class driver can issue this request to the port driver to obtain the address of its device. This request is not relevant to storage class drivers that support Plug and Play because the port driver supplies the address information on behalf of the class driver.

Returns the capabilities and limitations of the underlying SCSI HBA. The most important information is returned in theMaximumTransferLengthandAlignmentMaskmembers. Class drivers and users ofIOCTL_SCSI_PASS_THROUGHandIOCTL_SCSI_PASS_THROUGH_DIRECTare required to honor these limitations.

Returns the SCSI inquiry data for all devices on a given SCSI host bus adapter (HBA). If the IOCTL is employed in user space, the program must have opened a handle to the HBA, which can be enumerated by various means, such as SetupDixxx calls. You can useIOCTL_STORAGE_QUERY_PROPERTYto find information about a specific device on the HBA. To determine the size of the output buffer that is required, the caller should send this IOCTL request in a loop. Every time that the storage stack rejects the IOCTL with an error message that indicates that the buffer was too small, the caller should double the buffer size.

Sends a special control function to an HBA-specific miniport driver. Results vary, depending on the particular miniport driver to which this request is forwarded. If the caller specifies a nonzeroLength, either the input or output buffer must be at least (sizeof(SRB_IO_CONTROL) +DataBufferLength)).

The NV Cache Management operations that are defined here can be invoked by user-mode application code running with administrator privileges, using DeviceIoControl and theIOCTL_SCSI_MINIPORTcontrol code. Or, the caller can be kernel-mode driver code usingIoBuildDeviceIoControlRequestand the IOCTL_SCSI_MINIPORT control code.

The IOCTL_SERIAL_GET_LINE_CONTROL request returns information about the line control set for a serial device. The line control parameters include the number of stop bits, the number of data bits, and the parity.

The IOCTL_SERIAL_GET_STATS request returns information about the performance of a serial device. The statistics include the number of characters transmitted, the number of characters received, and useful error statistics. The driver continuously increments performance values.

The IOCTL_SERIAL_IMMEDIATE_CHAR request causes a specified character to be transmitted as soon as possible. The immediate character request completes immediately after any other write that might be in progress. Only one immediate character request can be pending at a time.

The IOCTL_SERIAL_INTERNAL_BASIC_SETTINGS request sets a serial device to a basic operating mode. Serial's basic operating mode reads and writes one byte at a time, and does not use handshake flow control or time-outs. The basic operation mode is suitable for use by a driver that uses a subset of the 16550 UART interface. Examples of such drivers include a mouse driver or a graphics pad driver for older hardware that use a 16450 UART.

User-mode applications use this IOCTL to send Secure Digital (SD) card commands to an SD card. For a description of these commands, see theSD Memory Card Part 1 Physical Layer Specification, and theSD Memory Card Part 3 Securityspecification.

User-mode applications use this IOCTL to perform basic operations on a Secure Digital (SD) card, such as setting the password on the card, resetting the card, or locking and unlocking the card. For a description of this command, see theSecure Digital I/O (SDIO)specification.

User-mode applications use this IOCTL to retrieve a protocol value that identifies the card as either an SD card or an MMC card. For a description of this command, see theSecure Digital I/O (SDIO)specification.

The IOCTL_SMARTCARD_GET_ATTRIBUTE request queries smart card and smart card reader attributes. For a list of all defined attributes, refer to Part 3 of theInteroperability Specification for ICCs and Personal Computer Systems.

The IOCTL_SMARTCARD_GET_LAST_ERROR request retrieves the error code of the most previous operation because there is no option to return an error code immediately after an overlapped operation is complete.

Determines whether the media has changed on a removable-media device - the caller has opened with FILE_READ_ATTRIBUTES. Because no file system is mounted when a device is opened in this way, this request can be processed much more quickly than an IOCTL_STORAGE_CHECK_VERIFY request.

Returns the properties of a storage device or adapter. The request indicates the kind of information
to retrieve, such as the inquiry data for a device or the capabilities and limitations of an adapter.IOCTL_STORAGE_QUERY_PROPERTYcan also be used
to determine whether the port driver supports a particular property or which fields in the property descriptor can
be modified with a subsequent change-property request.

Causes media to be loaded in a device that the caller has opened with FILE_READ_ATTRIBUTES. Because no file system is mounted when a device is opened in this way, this request can be processed much more quickly than anIOCTL_STORAGE_LOAD_MEDIArequest.

The generic storage class driver (classpnp.sys) exposes an I/O control (IOCTL) interface for issuing Persistent Reserve In commands. The behavior of the storage device when a Persistent Reserve In command is received is described in theSCSI Primary Commands - 2 (SPC-2)specification. The IOCTL interface requires the caller to have read access to the physical device for Persistent Reserve In commands. User-mode applications, services, and kernel-mode drivers can use this IOCTL to control persistent reservations. If called from a driver, this IOCTL must be called from a thread running at IRQL < DISPATCH_LEVEL. This IOCTL is defined with FILE_READ_ACCESS, requiring a device handle to have read permissions to issue the Persistent Reserve In command.

The generic storage class driver (classpnp.sys) exposes an I/O control (IOCTL) interface for issuing Persistent Reserve Out commands. The behavior of the storage device when a Persistent Reserve Out command is received is described in theSCSI Primary Commands - 2 (SPC-2)specification. The IOCTL interface requires the caller to have read/write access to the physical device for Persistent Reserve Out commands. User-mode applications, services, and kernel-mode drivers can use this IOCTL to control persistent reservations. If called from a driver, this IOCTL must be called from a thread running at IRQL < DISPATCH_LEVEL. This IOCTL is defined with FILE_READ_ACCESS and FILE_WRITE_ACCESS, requiring a device handle to have both read and write permissions to issue the Persistent Reserve Out command.

Polls for a prediction of device failure. This request works with the IDE disk drives that support self-monitoring analysis and reporting technology (SMART). If the drive is a SCSI drive, the class driver attempts to verify if the SCSI disk supports the equivalent IDE SMART technology by check the inquiry information on the Information Exception Control Page, X3T10/94-190 Rev 4.

Returns the properties of a storage device or adapter. The request indicates the kind of information
to retrieve, such as the inquiry data for a device or the capabilities and limitations of an adapter.IOCTL_STORAGE_QUERY_PROPERTYcan also be used
to determine whether the port driver supports a particular property or which fields in the property descriptor can
be modified with a subsequent change-property request.

Resets an I/O bus and, indirectly, each device on the bus. Resetting the bus clears all device reservations and transfer speed settings, which must then be renegotiated, making it a time-consuming operation that should be used very rarely. The caller requires only read access to issue a bus reset.

If possible, resets a non-SCSI storage device without affecting other devices on the bus. Device reset for SCSI devices is not supported. The caller requires only read access to issue a device reset and, to comply, the device must be capable of responding to I/O requests. If the device reset succeeds, pending I/O requests are canceled.

Erases the current tape partition, either as a TAPE_ERASE_LONG (in other words, a "secure") operation that overwrites data with a pattern or as a TAPE_ERASE_SHORT (in other words, a "quick") operation that writes an end-of-recorded-data mark at the current position.

Returns information about the tape drive's capabilities, such as its default block size, maximum and minimum block sizes, maximum partition count, whether the drive has EEC, compression, data padding, and report-setmark capabilities, that is, which configurable features the drive supports, including the EOT warning zone size.

Adjusts a tape drive's configurable parameters. The miniclass driver can ignore parameters that its device does not support. The calling application is responsible for determining whether a device supports a particular feature before attempting to set it.

Returns a block of x86-specific executable code to be used by a high-resolution SVGA display driver for bank switching. Miniport drivers for VGA-compatible adapters are required to support this modal request; optional for other miniport drivers.

Determines whether a child device is currently enabled. Although miniport driver support for this modal request is optional, it is highly recommended. Otherwise, Windows 2000 and later must call the BIOS to perform the operation, which is very inefficient and can adversely affect system robustness. If the BIOS cannot handle this request, then Windows 2000 or later considers the child device to be active.

Gets the capabilities of the device's television connector and/or copy protection hardware, or sets the desired functionality on the copy protection hardware. Adapters that support TV connectors should provide support for this modal IOCTL. SeeTV Connector and Copy Protection Support in Video Miniport Driversfor details.

Maps the video hardwareframe bufferand video RAM into the virtual address space of the requester. Miniport drivers are required to handle this IOCTL and to map all video memory in the caller's address space withVideoPortMapMemory.

Returns the color-capabilities information found in the VDDP description file for the adapter. Support for this nonmodal request is optional. However, if a miniport driver supports this request, it cannot return a subset of the color-capabilities information.

Returns the size, position, and visibility of the cursor. Miniport drivers for VGA-compatible adapters are required to support this modal request; optional for other miniport drivers. The cursor position is specified by top and bottom scan lines, instead of row and column information, for VGA-compatible adapters.

[This control code is available for use in the operating systems specified in the Requirements section. Support for this control code was removed in Windows Server 2008 and Windows Vista. Use theWmiMonitorBrightnessclass instead.]

Returns the number of video modes supported by the adapter and the size in bytes of the video mode information, which can be used to allocate a buffer for anIOCTL_VIDEO_QUERY_AVAIL_MODESrequest. Miniport drivers are required to support this nonmodal request.

Performs a display device switch, a state change in which the video signal going to one display device is sent to another, possibly different type of display device. After the display device switch, the video signal can be sent to one or both display devices. When the video port driver receives a notification to switch display devices, it sends this IOCTL to the miniport driver. Normally, this IOCTL is sent afterIOCTL_VIDEO_VALIDATE_CHILD_STATE_CONFIGURATIONindicates that the miniport driver is ready to make the switch. If the miniport driver is capable of switching display devices, it should do so and set theStatusmember ofStatusBlockto NO_ERROR.

Sets the adapter's color registers to the specified RGB values. If the adapter has a color look up table (CLUT), sometimes called a palette, the miniport driver is required to support this modal request.

Sets the adapter to the specified operating mode. Miniport drivers are required to support this nonmodal request because it resets the current mode. The miniport driver must also consider the two high order flags which are used to additionally control the mode set operation. SeeVIDEO_MODEfor further information.

Sets the pointer attributes. Support for this modal request is optional. A supporting miniport driver can fail this request (for example, if the attributes specify a larger pointer than the miniport driver can supply). When a miniport driver fails this request, the corresponding display driver must manage the pointer.

This IOCTL is called by a process that will share user-mode video memory as a linearframe buffer. Miniport drivers handle this IOCTL by mapping the frame buffer into the caller's address space withVideoPortMapBankedMemory. Otherwise this IOCTL is the same asIOCTL_VIDEO_MAP_VIDEO_MEMORY.

Queries the miniport driver to determine whether it is ready for a display device switch. This switch is a state change in which the video signal going to one display device is sent to another, possibly different type of display device. After the display device switch, the video signal can be sent to one or both display devices. When the video port driver receives a request to switch display devices (by, for example, a hotkey being pressed), it sends this IOCTL to the video miniport driver. The value returned by the miniport driver indicates whether the video port driver should proceed with the display device switch.

The IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES control code is sent to force a flush of a file system before a volume shadow copy occurs. This IOCTL is issued as an IRP_MJ_DEVICE_CONTROL request that is sent only to the volume device object of a local file system and to file system filter drivers that may have attached to that volume. This IOCTL is most commonly sent by the Volume Shadow Copy Service, but it can also be issued by other user-mode applications or processes. It is also possible under special circumstances for this IOCTL to be sent by the Volume Shadow Copy Driver (volsnap.sys) during a hibernation request or before a crash dump. This IOCTL is sent to file system filter drivers, file system drivers, and other device drivers (storage filter drivers and storage drivers, for example) located below the file systems.