Having this weird problem with more than four IOCTLS. I am looking at the IOCTL example in the DDK for inspiration and the IOCTLS are defined in the 0x900 range as
900,901,902,903
The problem occurs when I try to define more than this, eg 904. In my driver I have a switch statement to handle the IRP and when I submit 904 it fires the default case, which just DbgPrints(“Unknown IOCTL”);
I have trawled the MSDN and the only thing of relevance I can see is that for Vendor specific IOCTLs you need to set the custom bit, but I think this is achieved by having your function code in the range x800 - FFFF
Has anyone got an example of more than four custom IOCTLs than can confirm this works? It is strange that the MSDN example only goes to four, and then when you try and add to it you run into difficulties.
Thanks in advance
you can debug it simply - print the value of ioctl code in your app and driver. I am sorry to ask you that ,are you using the same ioctl header?
send the ioctl handler code and header snippet if you could not identify.
sree
xxxxx@yahoo.co.uk wrote:
Having this weird problem with more than four IOCTLS. I am looking at the IOCTL example in the DDK for inspiration and the IOCTLS are defined in the 0x900 range as
900,901,902,903
The problem occurs when I try to define more than this, eg 904. In my driver I have a switch statement to handle the IRP and when I submit 904 it fires the default case, which just DbgPrints(“Unknown IOCTL”);
I have trawled the MSDN and the only thing of relevance I can see is that for Vendor specific IOCTLs you need to set the custom bit, but I think this is achieved by having your function code in the range x800 - FFFF
Has anyone got an example of more than four custom IOCTLs than can confirm this works? It is strange that the MSDN example only goes to four, and then when you try and add to it you run into difficulties.
windows driver has no IOCTL count limitation. Of course you can define
more than four private IOCTLs. You can look at WDK sample code:
{WDK_PATH}\src\1394\driver
Best regards – Wayne
I am printing the IOCTL in the user mode app and the kernel mode driver. They tally until you get to 904, then there is a difference, usually by 4
eg -16954…long…number…8 sent from user mode ending in 8
-16954…long…number…4 received in kernel ending in 4
I confess the IOCTLS are defined in seperate files, but one is a straight copy and paste of the other and I checked this and recompiled everything and still got this weird error. Thanks for your advice I shall look at the 1394 example, and change to use the one header file for defining the IOCTLS.
That’s because you cannot just invent your own values. These values have a
meaning, they include information about the buffering methods and access
modes. You need to use the CTL_CODE macro. Read the topic “Defining I/O
Control Codes” in the WDK.
//Daniel
wrote in message news:xxxxx@ntdev…
> Having this weird problem with more than four IOCTLS. I am looking at the
> IOCTL example in the DDK for inspiration and the IOCTLS are defined in the
> 0x900 range as
>
> 900,901,902,903
>
> The problem occurs when I try to define more than this, eg 904. In my
> driver I have a switch statement to handle the IRP and when I submit 904
> it fires the default case, which just DbgPrints(“Unknown IOCTL”);
>
> I have trawled the MSDN and the only thing of relevance I can see is that
> for Vendor specific IOCTLs you need to set the custom bit, but I think
> this is achieved by having your function code in the range x800 - FFFF
>
> Has anyone got an example of more than four custom IOCTLs than can confirm
> this works? It is strange that the MSDN example only goes to four, and
> then when you try and add to it you run into difficulties.
>
> Thanks in advance
>
>
>
I am.
>“I am looking at the IOCTL example in the DDK for inspiration”
I have taken the example IOCTLS from the DDK, and just added one to the list. This additional one is not coming into the driver correctly, but it is defined correctly as per the MSDN.
send the header and ioctl handler code snippet
sree
xxxxx@yahoo.co.uk wrote:
Having this weird problem with more than four IOCTLS. I am looking at the IOCTL example in the DDK for inspiration and the IOCTLS are defined in the 0x900 range as
900,901,902,903
The problem occurs when I try to define more than this, eg 904. In my driver I have a switch statement to handle the IRP and when I submit 904 it fires the default case, which just DbgPrints(“Unknown IOCTL”);
I have trawled the MSDN and the only thing of relevance I can see is that for Vendor specific IOCTLs you need to set the custom bit, but I think this is achieved by having your function code in the range x800 - FFFF
Has anyone got an example of more than four custom IOCTLs than can confirm this works? It is strange that the MSDN example only goes to four, and then when you try and add to it you run into difficulties.
There has been a lot of theorizing, hemming, and hawing in this thread
that could have been avoided if you had done the sensible thing and
shown us your code. Show us the #include files that define the ioctl
codes, show us your application code that calls DeviceIoControl, and
show us the driver code with the “switch” statement for handling them.
Your “4” is suspicious, because the low-order two bits of the ioctl code
are used to define the I/O method. That suggests a usage problem.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
How have you declared the IOCTL ??? Have you used the CTL code macro ?? You can look for “CTL_CODE” under ddk documentation for any help on the same. Basically the macro is used as follows
#define IOCTL_A CTL_CODE(FILE_DEVICE_UNKNOWN, 0x901, METHOD_BUFFERED, FILE_READ_DATA | FILE_WRITE_DATA)
#define IOCTL_B CTL_CODE(FILE_DEVICE_UNKNOWN, 0x902, METHOD_BUFFERED, FILE_READ_DATA | FILE_WRITE_DATA)
#define IOCTL_C CTL_CODE(FILE_DEVICE_UNKNOWN, 0x903, METHOD_BUFFERED, FILE_READ_DATA | FILE_WRITE_DATA)
#define IOCTL_D CTL_CODE(FILE_DEVICE_UNKNOWN, 0x904, METHOD_BUFFERED, FILE_READ_DATA | FILE_WRITE_DATA)
#define IOCTL_E CTL_CODE(FILE_DEVICE_UNKNOWN, 0x905, METHOD_BUFFERED, FILE_READ_DATA | FILE_WRITE_DATA)
The parameters of CTL_CODE macro may change depending on your implementation.