Re: Why is remote system information calling ioctl for my driver?

Thanks for the excellent answer, Luca. I also found that it's keying off of
the SerialPortIndex registry key to decide if the driver should be probed
this way. I changed that key name to something else, and System Information
is now hands off of my driver.

Marco

"Luca Calligaris" wrote:

The System Information tool calls those IOCTL's to gain information about
the serial device, as it is designed to do.

IOCTL's are defined by a macro (look at windev.h):

#define CTL_CODE(DeviceType, Function, Method, Access) (
((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method))

Your codes have DeviceType==0x1B (FILE_DEVICE_SERIAL_PORT),
Access==0 (FILE_ANY_ACCESS), and Method==0 (METHOD_BUFFERED)
(all this stuff is again defined in windev.h) which means that
are specific for the serial driver. The 'functions' are:

0x001b0050 => Function == 0x50>>2 == 0x14
0x001b0038 => Function == 0x38>>2 == 0x0E
0x001b0040 => Function == 0x40>>2 == 0x10

If you look at pegdser.h you'll end up with:

0x001b0050 => IOCTL_SERIAL_GET_DCB
0x001b0038 => IOCTL_SERIAL_GET_PROPERTIES
0x001b0040 => IOCTL_SERIAL_GET_TIMEOUTS

From the debug output we can see that IOCTL's fail with error 87
(ERROR_INVALID_PARAMETER).

In the MDD/PDD layered architecture those IOCTL_SERIAL_GET_SOMETHING
are basically handled in the MDD which checks the IOCTL parameters and
simply returns
cached data (apart for IOCTL_SERIAL_GET_PROPERTIES which actually flows down
to the PDD).

From the debug output I see a 'CheckIoctlParms' function call which is not
in
the standard MDD layer, so I suspect that your driver is not using that
layer
and your impementation is not checking correctly those IOCTL's parameters.
Take a look at mdd.c in the standard serial MDD2 layer to see how they are
handled.


--

Luca Calligaris
www.eurotech.it

"Marco" <Marco@xxxxxxxxxxxxxxxxxxxxxxxxx> ha scritto nel messaggio
news:C23663B2-E968-4255-9BA4-B29BF363ADCA@xxxxxxxxxxxxxxxx
Hi,

I'm developing a custom serial port device driver, and it seems to be
working fine for the most part. I'm running into a problem wrt the remote
tools -> system information feature in PB. When I run it without my
driver
loaded, it completes fine and I get valid system information. When I run
it
with my driver loaded, it looks like my driver is being opened and some
ioctl
calls are being attempted...

PID:400002 TID:210000e UARTMDB: -MDB_IOControl CheckIoctlParms failed on
code 0x001B0050, error 87
PID:400002 TID:210000e UARTMDB: -MDB_IOControl CheckIoctlParms failed on
code 0x001B0038, error 87
PID:400002 TID:210000e UARTMDB: -MDB_IOControl CheckIoctlParms failed on
code 0x001B0040, error 87

From these errors, I can tell that the ioctl codes are:

0x001b0050
0x001b0038
0x001b0040

A few questions here:

1. Is this normal behavior for the system information util to try to ioctl
a
driver?
2. Is there a way to disable this?
3. Where can I find out what IOCTLs these codes belong to?

Thanks,
Marco



.

Relevant Pages

  • Re: Why is remote system information calling ioctl for my driver?
    ... Changing the key name doesn't keep the System Information ... don't think the ioctl probing was causing the System Information util to fail ... How does it decide that my driver is a serial port ... the SerialPortIndex registry key to decide if the driver should be probed ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Why is remote system information calling ioctl for my driver?
    ... don't think the ioctl probing was causing the System Information util to ... How does it decide that my driver is a serial port ... the SerialPortIndex registry key to decide if the driver should be probed ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Kernel mode to user mode
    ... where they make sense in the context of using IoCtls for data passing also. ... An app passes an IoCtl to a driver initiating a series of tests that will ...
    (microsoft.public.development.device.drivers)
  • [RFC] dev_acpi: device driver for userspace access to ACPI
    ... The basic concept of operation is that the ioctl operates on the ACPI ... The sample, proof-of-concept app, is called acpitree. ... You can find the driver and sample app here: ...
    (Linux-Kernel)
  • Re: Accessing Ndis miniport from user mode application
    ... sticking to WMI, you confine yourself to strictly defined model - there are ... driver can indicate. ... to you - as I told you already, you should go for IOCTL model. ... Accessing custom OIDS through WMI. ...
    (microsoft.public.development.device.drivers)