Tigerzd请进，RE:2000下的虚拟设备驱动程序如何向一个PNP设备发送I/O请求？急！急！急！

对不起，上面的描述不是太精确，现在我再把问题描述清楚一点，请你耐心看下去：
1。用Driver Wizard创建一个设备驱动程序（project type is NT4.0  4.0）,驱动程序运行一切OK。

2。现在我需要在Driver中向一个USB modem发送请求:
    创建一个KLowerDevice的类实例，
    create an IRP(MajorFunction is IRP_MJ_DEVICE_CONTROL,
                  IoctlCode为 IOCTL_SERIAL_GET_BAUD_RATE),
    call KLowerDevice::Call
    

3。USB modem 安装后占用COM4,程序运行到create an instance of KLowerDevice(COM4)成功，但发送一个IoctlCode为 IOCTL_SERIAL_GET_BAUD_RATE返回值为操作失败，

4。但如果create an instance of KLowerDevice(COM1即电脑本身所带COM口)发送IoctlCode为 IOCTL_SERIAL_GET_BAUD_RATE操作成功，

现在问题的核心就是电脑本身所带COM口与一个PNP设备所create的COM口
有何区别？为什麽同样的操作二者会有不一样的结果？




[编辑 -  8/8/02 by  goesby]

[编辑 -  8/8/02 by  goesby]

我建议你如下做：
1、设备管理器COM4工作正常吗？
2、IOCTL_SERIAL_GET_BAUD_RATE在COM1完成什么功能？你的USB Modem又是怎么模拟的？
3、IOCTL_SERIAL_GET_BAUD_RATE发送到你的USB Modem了吗？

我按照你所讲的，结果如下：
1。写一个应用程序，OpenFile，向COM4发送IoctlCode为 IOCTL_SERIAL_GET_BAUD_RATE,得到了正确的baud rate,这就证明它所Create的COM4可以正常工作。

2。在我的driver里，我是以COM4为LowerDevice创建一个KLowerDevice
的类实例，事实证明这样并未启动它，而对于COM1,这样做就可以。我的 driver project type is NT4.0 ,有什麽办法在非WDM式driver中来启动一个PNP设备？

既然你“写一个应用程序，OpenFile，向COM4发送IoctlCode为 IOCTL_SERIAL_GET_BAUD_RATE,得到了正确的baud rate,这就证明它所Create的COM4可以正常工作。”那么就好办啦，在驱动程序的PASSIVE_LEVEL调用ZwCreatFile打开Com4，用ZwDeviceIoControl发送IOCTL_SERIAL_GET_BAUD_RATE肯定可以的。
 :)

在2000 申明啊：
ZwDeviceIoControlFile
ZwDeviceIoControlFile sends a control code directly to a specified device driver, causing the corresponding driver to perform the specified operation.

NTSTATUS
  ZwDeviceIoControlFile(
    IN HANDLE  FileHandle,
    IN HANDLE  Event,
    IN PIO_APC_ROUTINE  ApcRoutine,
    IN PVOID  ApcContext,
    OUT PIO_STATUS_BLOCK  IoStatusBlock,
    IN ULONG  IoControlCode,
    IN PVOID  InputBuffer,
    IN PVOID  InputBufferLength,
    OUT PVOID  OutputBuffer,
    OUT PVOID  OutputBufferLength
    );
Parameters
FileHandle
Handle returned by ZwCreateFile or ZwOpenFile for the file object representing the device to which the control information should be given or from which information should be returned. The file object must have been opened for asynchronous I/O if the caller specifies an Event, ApcRoutine and ApcContext, or CompletionContext. For I/O to an underlying mass-storage device, the file object must have been opened for Direct Access to Storage Device (DASD) access.
Event
Optional handle to a caller-created event, which the caller will wait on for completion of the requested operation when the given event is set to the Signaled state. This parameter can be NULL. It must be NULL if the caller will wait on the FileHandle.
ApcRoutine
Address of an optional, caller-supplied APC routine to be called when the requested operation completes. This parameter can be NULL. It must be NULL if there is an I/O completion object associated with the file object.
ApcContext or CompletionContext
Pointer to a caller-determined context area if the caller supplies an APC or if an I/O completion object has been associated with the file object. When the operation completes, either ApcContext is passed to the APC if one was specified or CompletionContext is included as part of the completion message that the I/O Manager posts to the associated I/O completion object.
This parameter must be NULL if ApcRoutine is NULL and there is no I/O completion object associated with the file object.

IoStatusBlock
Pointer to a variable that receives the final completion status and information about the operation. For successful calls that return data, the number of bytes written to the OutputBuffer is returned in the Information member.
IoControlCode
IOCTL_XXX code that indicates which device I/O control operation is to be carried out on, usually by the underlying device driver. The value of this parameter determines the format(s) and required length(s) of the input and output buffers, as well as which of the following parameter pairs are required. For detailed information about the system-defined, device-type-specific IOCTL_XXX codes, see the Windows 2000 DDK documentation and Device Input and Output Control Codes in the Platform SDK documentation.
InputBuffer
Pointer to a caller-allocated buffer that contains device-specific information to be given to the target device. If IoControlCode specifies an operation that does not require input data, this pointer can be NULL.
InputBufferLength
Size in bytes of the buffer at InputBuffer. This value is ignored if InputBuffer is NULL.
OutputBuffer
Pointer to a caller-allocated buffer in which information is returned from the target device. If IoControlCode specifies an operation that does not produce output data, this pointer can be NULL.
OutputBufferLength
Size in bytes of the buffer at OutputBuffer. This value is ignored if OutputBuffer is NULL.
Return Value
ZwDeviceIoControlFile returns STATUS_SUCCESS if the underlying driver(s) successfully carried out the requested operation. Otherwise, the return value can be an error status code propagated from an underlying driver. Possible error status codes include the following:

STATUS_OBJECT_TYPE_MISMATCH
STATUS_INVALID_HANDLE
STATUS_INVALID_PARAMETER
STATUS_ACCESS_DENIED
STATUS_INSUFFICIENT_RESOURCES

Comments
ZwDeviceIoControlFile provides a consistent view of the input and output data to the system and to kernel-mode drivers, while providing applications and underlying drivers with a device-dependent method of specifying a communications interface.

For more information about system-defined IOCTL_XXX codes that kernel-mode drivers for particular types of devices must support, and about defining device-specific IOCTL_XXX or FS-specific FSCTL_XXX for new drivers, see the Windows 2000 DDK documentation and Device Input and Output Control Codes in the Platform SDK documentation.

If the caller opened the file for asynchronous I/O (with neither FILE_SYNCHRONOUS_XXX create/open option set), the specified event, if any, will be set to the signaled state when the device control operation completes. Otherwise, the file object specified by FileHandle will be set to the signaled state. If an ApcRoutine was specified, it is called with the ApcContext and IoStatusBlock pointers.

Callers of ZwDeviceIoControlFile must be running at IRQL PASSIVE_LEVEL.

See Also
IoCallDriver, IoBuildAsynchronousFsdRequest, IoBuildDeviceIoControlRequest, IoBuildSynchronousFsdRequest, ZwClose, ZwCreateFile, ZwOpenFile

Built on Thursday, August 17, 2000

thanks!