27 out of 69 rated this helpful - Rate this topic

DeviceIoControl function

Applies to: desktop apps only

Sends a control code directly to a specified device driver, causing the corresponding device to perform the corresponding operation.

Syntax

BOOL WINAPI DeviceIoControl(
  __in         HANDLE hDevice,
  __in         DWORD dwIoControlCode,
  __in_opt     LPVOID lpInBuffer,
  __in         DWORD nInBufferSize,
  __out_opt    LPVOID lpOutBuffer,
  __in         DWORD nOutBufferSize,
  __out_opt    LPDWORD lpBytesReturned,
  __inout_opt  LPOVERLAPPED lpOverlapped
);

Parameters

hDevice [in]

A handle to the device on which the operation is to be performed. The device is typically a volume, directory, file, or stream. To retrieve a device handle, use the CreateFile function. For more information, see Remarks.

dwIoControlCode [in]

The control code for the operation. This value identifies the specific operation to be performed and the type of device on which to perform it.

For a list of the control codes, see Remarks. The documentation for each control code provides usage details for the lpInBuffer, nInBufferSize, lpOutBuffer, and nOutBufferSize parameters.

lpInBuffer [in, optional]

A pointer to the input buffer that contains the data required to perform the operation. The format of this data depends on the value of the dwIoControlCode parameter.

This parameter can be NULL if dwIoControlCode specifies an operation that does not require input data.

nInBufferSize [in]

The size of the input buffer, in bytes.

lpOutBuffer [out, optional]

A pointer to the output buffer that is to receive the data returned by the operation. The format of this data depends on the value of the dwIoControlCode parameter.

This parameter can be NULL if dwIoControlCode specifies an operation that does not return data.

nOutBufferSize [in]

The size of the output buffer, in bytes.

lpBytesReturned [out, optional]

A pointer to a variable that receives the size of the data stored in the output buffer, in bytes.

If the output buffer is too small to receive any data, the call fails, GetLastError returns ERROR_INSUFFICIENT_BUFFER, and lpBytesReturned is zero.

If the output buffer is too small to hold all of the data but can hold some entries, some drivers will return as much data as fits. In this case, the call fails, GetLastError returns ERROR_MORE_DATA, and lpBytesReturned indicates the amount of data received. Your application should call DeviceIoControl again with the same operation, specifying a new starting point.

If lpOverlapped is NULL, lpBytesReturned cannot be NULL. Even when an operation returns no output data and lpOutBuffer is NULL, DeviceIoControl makes use of lpBytesReturned. After such an operation, the value of lpBytesReturned is meaningless.

If lpOverlapped is not NULL, lpBytesReturned can be NULL. If this parameter is not NULL and the operation returns data, lpBytesReturned is meaningless until the overlapped operation has completed. To retrieve the number of bytes returned, call GetOverlappedResult. If hDevice is associated with an I/O completion port, you can retrieve the number of bytes returned by calling GetQueuedCompletionStatus.

lpOverlapped [in, out, optional]

A pointer to an OVERLAPPED structure.

If hDevice was opened without specifying FILE_FLAG_OVERLAPPED, lpOverlapped is ignored.

If hDevice was opened with the FILE_FLAG_OVERLAPPED flag, the operation is performed as an overlapped (asynchronous) operation. In this case, lpOverlapped must point to a valid OVERLAPPED structure that contains a handle to an event object. Otherwise, the function fails in unpredictable ways.

For overlapped operations, DeviceIoControl returns immediately, and the event object is signaled when the operation has been completed. Otherwise, the function does not return until the operation has been completed or an error occurs.

Return value

If the operation completes successfully, the return value is nonzero.

If the operation fails or is pending, the return value is zero. To get extended error information, call GetLastError.

Remarks

To retrieve a handle to the device, you must call the CreateFile function with either the name of a device or the name of the driver associated with a device. To specify a device name, use the following format:

\\.\DeviceName

DeviceIoControl can accept a handle to a specific device. For example, to open a handle to the logical drive A: with CreateFile, specify \\.\a:. Alternatively, you can use the names \\.\PhysicalDrive0, \\.\PhysicalDrive1, and so on, to open handles to the physical drives on a system.

You should specify the FILE_SHARE_READ and FILE_SHARE_WRITE access flags when calling CreateFile to open a handle to a device driver. However, when you open a communications resource, such as a serial port, you must specify exclusive access. Use the other CreateFile parameters as follows when opening a device handle:

  • The fdwCreate parameter must specify OPEN_EXISTING.
  • The hTemplateFile parameter must be NULL.
  • The fdwAttrsAndFlags parameter can specify FILE_FLAG_OVERLAPPED to indicate that the returned handle can be used in overlapped (asynchronous) I/O operations.

For lists of supported control codes, see the following topics:

Examples

For an example that uses DeviceIoControl, see Calling DeviceIoControl.

Requirements

Minimum supported client

Windows XP

Minimum supported server

Windows Server 2003

Header

Winbase.h (include Windows.h)

Library

Kernel32.lib

DLL

Kernel32.dll

See also

CreateEvent
CreateFile
Device Input and Output Control (IOCTL)
GetOverlappedResult
GetQueuedCompletionStatus
OVERLAPPED

 

 

Send comments about this topic to Microsoft

Build date: 2/7/2012

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
My experiment

If use lpOverlapped parameter, lpOverlapped must keep valid even if you don't care final result.

It look like kernel trace the parameter and write data.

lpOutBuffer can be an input buffer
For some IOCTL codes, lpOutBuffer can be used as input buffer. This is especially valuable for transfering some larger amount of bulk data while you have to provide an extra address using lpInBuffer.
Missing control code
What about the IOCTL_CDROM_DISC_INFO control code?
lpBytesReturned not optional
lpBytesReturned appears not to be optional as stated. In some uses of DeviceIoControl, at least, passing NULL for this parameter causes an exception.
Privileges
Privileges necessary for opening a device handle and issuing particular IOCTLs depend on the device's ACL, which can be different on per-device basis. An unprivileged user can open a handle with all access to some device, if it's got an appropriate ACL. For example, to a COM port.
Error in content
"This has changed on Vista, Windows 7 (UAC) where you MUST have administrator rights to obtain device handles."

This is (of course) incorrect - i am opening several handles to devices, pipes and even TCP-Sockets here --> Windows 7, UAC is activated and my application is running WITHOUT admin-rights ... works perfectly. The above behaviour may be present on Windows Vista but is most certainly NOT present on Windows 7 RTM


eriklitze reply:

The description should have been more clear. You can still open a device handle using FILE_READ_ATTRIBUTES without administrative rights. However you can't open volume handles using GENERIC_WRITE access without having Administrative token. Windows XP both standard users and Administrators can open volume handles regardless. Windows Vista, Windows 7(UAC) you can't gain access in the same way to volume handles.
More Info...


You need administrative access for GENERIC_WRITE on Vista and later.

C# Sample for Sparse Files
I used the above in my blog entry showing a C# sample of how to create and use NTFS sparse files from .NET: http://blogs.msdn.com/codedebate/archive/2007/12/18/6797175.aspx