IOCTL problem

_Genius · August 20, 2010, 4:00pm

Hi, just don’t know why the user-mode could not send the specified command to kernel-mode component,

here's the source of user mode :  
#define BASE_IOCTL (FILE_DEVICE_UNKNOWN \<\< 16) | (FILE_READ_ACCESS \<\< 14) | METHOD_BUFFERED  
#define IOCTL_DBG BASE_IOCTL | (1 \<\< 2)  
  
#include <windows.h><br>#include <winioctl.h><br>#include <stdio.h><br><br>int __cdecl main(void)<br>{<br> char szTemp[256] = {0};<br>	HANDLE	hFile ;<br>	DWORD	dwReturn ;<br>	hFile = CreateFile("\\\\.\\DeVx",GENERIC_READ|GENERIC_WRITE,0,NULL,OPEN_EXISTING,0,NULL);<br>	if(hFile)<br>	{<br> DeviceIoControl(hFile,IOCTL_DBG,NULL,0,NULL,0,&amp;dwReturn,NULL);<br>	}<br>	CloseHandle(hFile);<br>	return 0;<br>}<br>```<br><br>&amp; here's the kernel-mode :<br><br>```<br>#include <ntddk.h><br><br>typedef char * PCHAR;<br><br>#define BASE_IOCTL (FILE_DEVICE_UNKNOWN &lt;&lt; 16) | (FILE_READ_ACCESS &lt;&lt; 14) | METHOD_BUFFERED<br>#define IOCTL_DBG BASE_IOCTL | (1 &lt;&lt; 2)<br><br>void ioDbg()<br>{	<br>	DbgPrint("\nioDbg - Successful - Congratulations!");	<br>}<br>NTSTATUS Unsupported_Function(PDEVICE_OBJECT DeviceObject, PIRP Irp)<br>{<br>	NTSTATUS NtStatus = STATUS_NOT_SUPPORTED;<br>	DbgPrint("\nUnsupported Function ...");<br>	return NtStatus ;<br>}<br>NTSTATUS eClose(PDEVICE_OBJECT DeviceObject, PIRP Irp)<br>{<br>	NTSTATUS NtStatus = STATUS_SUCCESS;<br>	DbgPrint("\neCLose()");<br>	return STATUS_SUCCESS;<br>}<br>NTSTATUS eCreate(PDEVICE_OBJECT DeviceObject, PIRP Irp)<br>{<br>	NTSTATUS NtStatus = STATUS_SUCCESS;<br>	DbgPrint("\neCreate");<br>	return NtStatus ;<br>}<br>NTSTATUS eIoControl(IN PDEVICE_OBJECT pDeviceObject, IN PIRP Irp)<br>{<br>	PIO_STACK_LOCATION	irpStack;<br>	NTSTATUS	NtStatus = STATUS_SUCCESS;<br>	PVOID inputBuffer;<br>	PVOID outputBuffer;<br>	ULONG inputBufferLength;<br>	ULONG outputBufferLength;<br>	ULONG ioctrlCode;<br>	Irp-&gt;IoStatus.Status = STATUS_SUCCESS;<br>	Irp-&gt;IoStatus.Information = 0;<br>	inputBuffer =	Irp-&gt;AssociatedIrp.SystemBuffer;<br>	outputBuffer	=	Irp-&gt;AssociatedIrp.SystemBuffer;<br><br>irpStack =	IoGetCurrentIrpStackLocation(Irp);<br>	inputBufferLength	=	irpStack-&gt;Parameters.DeviceIoControl.InputBufferLength;<br>	outputBufferLength	=	irpStack-&gt;Parameters.DeviceIoControl.OutputBufferLength;<br>	ioctrlCode =	irpStack-&gt;Parameters.DeviceIoControl.IoControlCode;<br>	DbgPrint("\neIoControl");<br>	switch(ioctrlCode)<br>	{<br> case	IOCTL_DBG:<br> ioDbg();<br> break;<br><br>default:<br> DbgPrint("\neIoControl - Error !");<br> break;<br>	}<br>	return STATUS_SUCCESS;<br><br>}<br>VOID	eUnload(PDRIVER_OBJECT DriverObject)<br>{<br>	UNICODE_STRING usDosDeviceName ;<br>	DbgPrint("\neUnload ...");<br>	RtlInitUnicodeString(&amp;usDosDeviceName,L"\\DosDevices\\DeVx");<br>	IoDeleteSymbolicLink(&amp;usDosDeviceName);<br>	IoDeleteDevice(DriverObject-&gt;DeviceObject);<br>}<br><br>NTSTATUS DriverEntry(IN PDRIVER_OBJECT pDriverObject, IN PUNICODE_STRING RegistryPath)<br>{<br>	int i ;<br>	NTSTATUS NtStatus ;<br>	PDEVICE_OBJECT	pDeviceObject = NULL;<br>	UNICODE_STRING	usDriverName, usDosDeviceName ;<br>	DbgPrint("\nDriverEntry");<br>	RtlInitUnicodeString(&amp;usDriverName,L"\\Device\\DeVx") ;<br>	RtlInitUnicodeString(&amp;usDosDeviceName,L"\\DosDevices\\DeVx");<br>	NtStatus = IoCreateDevice(pDriverObject, 0, &amp;usDriverName,FILE_DEVICE_UNKNOWN,FILE_DEVICE_SECURE_OPEN,FALSE,&amp;pDeviceObject);<br>	if(NT_SUCCESS(NtStatus))<br>	{<br> for(i=0 ; i<irp_mj_maximum_function i> pDriverObject-&gt;MajorFunction[i] = Unsupported_Function ;<br><br>pDriverObject-&gt;MajorFunction[IRP_MJ_CLOSE] =	eClose;<br> pDriverObject-&gt;MajorFunction[IRP_MJ_CREATE] =	eCreate;<br> pDriverObject-&gt;MajorFunction[IRP_MJ_DEVICE_CONTROL] =	eIoControl;<br><br>pDriverObject-&gt;DriverUnload =	eUnload; <br><br>IoCreateSymbolicLink(&amp;usDosDeviceName,&amp;usDriverName);<br>	}<br><br>return NtStatus ;<br>}<br>```<br><br>Simple IOCTL connection for just send an empty command to kernel-mode with IOCTL_DBG &amp; this simply refer to ioDbg() function which just shows a dbgprint statement to the kernel debugger .<br><br>If anyone could catch this sikt problem it's good to say here .<br><br>regards.</irp_mj_maximum_function></ntddk.h></stdio.h></winioctl.h></windows.h>

Don_Burn_1 · August 20, 2010, 4:09pm

Why in the world aren’t you using the CTL_CODE macro?

–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

wrote in message news:xxxxx@ntdev…
> Hi, just don’t know why the user-mode could not send the specified command
> to kernel-mode component,
>
> > here's the source of user mode : > #define BASE_IOCTL (FILE_DEVICE_UNKNOWN << 16) | (FILE_READ_ACCESS << > 14) | METHOD_BUFFERED > #define IOCTL_DBG BASE_IOCTL | (1 << 2) > > #include <windows.h> > #include <winioctl.h> > #include <stdio.h> > > int __cdecl main(void) > { > char szTemp[256] = {0}; > HANDLE hFile ; > DWORD dwReturn ; > hFile = > CreateFile("\\\\.\\DeVx",GENERIC_READ|GENERIC_WRITE,0,NULL,OPEN_EXISTING,0,NULL); > if(hFile) > { > DeviceIoControl(hFile,IOCTL_DBG,NULL,0,NULL,0,&dwReturn,NULL); > } > CloseHandle(hFile); > return 0; > } >
>
> & here’s the kernel-mode :
>
> > #include <ntddk.h> > > typedef char * PCHAR; > > #define BASE_IOCTL (FILE_DEVICE_UNKNOWN << 16) | (FILE_READ_ACCESS << 14) > | METHOD_BUFFERED > #define IOCTL_DBG BASE_IOCTL | (1 << 2) > > void ioDbg() > { > DbgPrint("\nioDbg - Successful - Congratulations!"); > } > NTSTATUS Unsupported_Function(PDEVICE_OBJECT DeviceObject, PIRP Irp) > { > NTSTATUS NtStatus = STATUS_NOT_SUPPORTED; > DbgPrint("\nUnsupported Function ..."); > return NtStatus ; > } > NTSTATUS eClose(PDEVICE_OBJECT DeviceObject, PIRP Irp) > { > NTSTATUS NtStatus = STATUS_SUCCESS; > DbgPrint("\neCLose()"); > return STATUS_SUCCESS; > } > NTSTATUS eCreate(PDEVICE_OBJECT DeviceObject, PIRP Irp) > { > NTSTATUS NtStatus = STATUS_SUCCESS; > DbgPrint("\neCreate"); > return NtStatus ; > } > NTSTATUS eIoControl(IN PDEVICE_OBJECT pDeviceObject, IN PIRP Irp) > { > PIO_STACK_LOCATION irpStack; > NTSTATUS NtStatus = STATUS_SUCCESS; > PVOID inputBuffer; > PVOID outputBuffer; > ULONG inputBufferLength; > ULONG outputBufferLength; > ULONG ioctrlCode; > Irp->IoStatus.Status = STATUS_SUCCESS; > Irp->IoStatus.Information = 0; > inputBuffer = Irp->AssociatedIrp.SystemBuffer; > outputBuffer = Irp->AssociatedIrp.SystemBuffer; > > irpStack = IoGetCurrentIrpStackLocation(Irp); > inputBufferLength = > irpStack->Parameters.DeviceIoControl.InputBufferLength; > outputBufferLength = > irpStack->Parameters.DeviceIoControl.OutputBufferLength; > ioctrlCode = irpStack->Parameters.DeviceIoControl.IoControlCode; > DbgPrint("\neIoControl"); > switch(ioctrlCode) > { > case IOCTL_DBG: > ioDbg(); > break; > > default: > DbgPrint("\neIoControl - Error !"); > break; > } > return STATUS_SUCCESS; > > } > VOID eUnload(PDRIVER_OBJECT DriverObject) > { > UNICODE_STRING usDosDeviceName ; > DbgPrint("\neUnload ..."); > RtlInitUnicodeString(&usDosDeviceName,L"\\DosDevices\\DeVx"); > IoDeleteSymbolicLink(&usDosDeviceName); > IoDeleteDevice(DriverObject->DeviceObject); > } > > NTSTATUS DriverEntry(IN PDRIVER_OBJECT pDriverObject, IN PUNICODE_STRING > RegistryPath) > { > int i ; > NTSTATUS NtStatus ; > PDEVICE_OBJECT pDeviceObject = NULL; > UNICODE_STRING usDriverName, usDosDeviceName ; > DbgPrint("\nDriverEntry"); > RtlInitUnicodeString(&usDriverName,L"\\Device\\DeVx") ; > RtlInitUnicodeString(&usDosDeviceName,L"\\DosDevices\\DeVx"); > NtStatus = IoCreateDevice(pDriverObject, 0, > &usDriverName,FILE_DEVICE_UNKNOWN,FILE_DEVICE_SECURE_OPEN,FALSE,&pDeviceObject); > if(NT_SUCCESS(NtStatus)) > { > for(i=0 ; i<irp_mj_maximum_function i>> pDriverObject->MajorFunction[i] = Unsupported_Function ; > > pDriverObject->MajorFunction[IRP_MJ_CLOSE] = eClose; > pDriverObject->MajorFunction[IRP_MJ_CREATE] = eCreate; > pDriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = eIoControl; > > pDriverObject->DriverUnload = eUnload; > > IoCreateSymbolicLink(&usDosDeviceName,&usDriverName); > } > > return NtStatus ; > } >
>
> Simple IOCTL connection for just send an empty command to kernel-mode with
> IOCTL_DBG & this simply refer to ioDbg() function which just shows a
> dbgprint statement to the kernel debugger .
>
> If anyone could catch this sikt problem it’s good to say here .
>
> regards.
>
>
>
>__________ Information from ESET NOD32 Antivirus, version of virus
> signature database 5383 (20100820)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

Information from ESET NOD32 Antivirus, version of virus signature database 5383 (20100820) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com</irp_mj_maximum_function></ntddk.h></stdio.h></winioctl.h></windows.h>

_Genius · August 20, 2010, 4:28pm

Thanks for the point, I changed them as the following :

#define IOCTL_DBG CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_IN_DIRECT, FILE_READ_DATA | FILE_WRITE_DATA)

both in user-mode & kernel-mode but seems the issue still exist

Peter_Viscarola_OSR · August 20, 2010, 4:35pm

(if you’re not reading this on the Forum, the OP’s forum name is set to be “Genius”)

Hey Genius (really nice name choice there… you probably want to change that)…

Maybe you’d like to tell us the symptoms of the problem you’re seeing, and what you’ve tried in terms of debugging.

“just don’t know why the user-mode could not send the specified command to kernel-mode component” doesn’t make that much sense to me. Do you mean “the create succeeds, but the IOCTL…” (a) fails (please provide error return code), (b) hangs, (c) something else?

Or do you mean something else entirely.

Tell us Genius

Peter
OSR

Tim_Roberts · August 20, 2010, 4:55pm

xxxxx@yahoo.com wrote:

Hi, just don’t know why the user-mode could not send the specified command to kernel-mode component,

Well, one MAJOR problem here is that you never complete ANY of the IRPs
you receive. So, when your user-mode app calls CreateFile, the
IRP_MJ_CREATE IRP will never return. They’ll all be hung forever,
waiting for a resolution that will never come.

Where on earth did you find the sample code you based this on? The WDK
contains hundreds of sample drivers that all show you the RIGHT way to
write a simple driver.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

mm1 · August 20, 2010, 4:55pm

Does this mean that you’re actually defining it in two separate places?

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Friday, August 20, 2010 4:28 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IOCTL problem

Thanks for the point, I changed them as the following :

#define IOCTL_DBG CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_IN_DIRECT,
FILE_READ_DATA | FILE_WRITE_DATA)

both in user-mode & kernel-mode but seems the issue still exist

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

_Genius · August 20, 2010, 5:09pm

@ mm :
Nope, it’s located in a single header file which is shared between both user mode source & kernel mode … .

@Tim Roberts :
Thanks for your point, but I just write it for test , I also added IoCompleteRequest for each major funciton you mentioned, but nothing changed … .

Where on earth did you find the sample code you based this on? The WDK contains hundreds of sample drivers that all show you the RIGHT way to write a simple driver.

actually writing a simple driver is not the matter, so where in WDK can I find an understandable sample driver for IOCTLs ?

@Peter Viscarola (OSR) :
There’s no hang, just nothing happened while starting the user application which starts to communicate with driver …, I will try to find the error code .

Don_Burn_1 · August 20, 2010, 5:14pm

src\general\ioctl is the sample that shows how IOCTL’s work including all
the varieties of METHOD_XXX.

–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

wrote in message news:xxxxx@ntdev…
>@ mm :
> Nope, it’s located in a single header file which is shared between both
> user mode source & kernel mode … .
>
> @Tim Roberts :
> Thanks for your point, but I just write it for test , I also added
> IoCompleteRequest for each major funciton you mentioned, but nothing
> changed … .
>> Where on earth did you find the sample code you based this on? The WDK
>> contains hundreds of sample drivers that all show you the RIGHT way to
>> write a simple driver.
>
> actually writing a simple driver is not the matter, so where in WDK can I
> find an understandable sample driver for IOCTLs ?
>
> @Peter Viscarola (OSR) :
> There’s no hang, just nothing happened while starting the user application
> which starts to communicate with driver …, I will try to find the error
> code .
>
>
>
>
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 5383 (20100820)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

Information from ESET NOD32 Antivirus, version of virus signature database 5383 (20100820)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Peter_Viscarola_OSR · August 20, 2010, 5:18pm

What does “nothing happened” mean? Did the application RUN? The the CREATE succeed?? Did the application issue the IOCTL?

ARE YOU USING THE DEBUGGER Genius?

Peter
OSR

Tim_Roberts · August 20, 2010, 5:30pm

xxxxx@yahoo.com wrote:

Hi, just don’t know why the user-mode could not send the specified command to kernel-mode component,

here's the source of user mode :  
#define BASE_IOCTL (FILE_DEVICE_UNKNOWN \<\< 16) | (FILE_READ_ACCESS \<\< 14) | METHOD_BUFFERED  
#define IOCTL_DBG BASE_IOCTL | (1 \<\< 2)  
 
#include <windows.h><br>&gt; #include <winioctl.h><br>&gt; #include <stdio.h><br>&gt;<br>&gt; int __cdecl main(void)<br>&gt; {<br>&gt; char szTemp[256] = {0};<br>&gt; HANDLE	hFile ;<br>&gt; DWORD	dwReturn ;<br>&gt; hFile = CreateFile("\\\\.\\DeVx",GENERIC_READ|GENERIC_WRITE,0,NULL,OPEN_EXISTING,0,NULL);<br>&gt; if(hFile)<br>&gt; {<br>&gt; DeviceIoControl(hFile,IOCTL_DBG,NULL,0,NULL,0,&amp;dwReturn,NULL);<br>&gt; }<br>&gt; CloseHandle(hFile);<br>&gt; return 0;<br>&gt; }<br><br>OK, I can see why you might be getting nothing. 0 is a perfectly valid<br>file handle. When CreateFile fails, it returns INVALID_HANDLE_VALUE,<br>which is -1. Your code will treat that as success and try the<br>DeviceIoControl, which will fail with a bad handle error, which you are<br>also not checking.<br><br>Try this:<br> hFile = CreateFile(...);<br> if( hFile == INVALID_HANDLE_VALUE )<br> {<br> printf( "CreateFile failed, error %d\n", GetLastError());<br> return -1;<br> }<br> DeviceIoControl( ... );<br> CloseHandle( hFile );<br><br>-- <br>Tim Roberts, xxxxx@probo.com<br>Providenza &amp; Boekelheide, Inc.</stdio.h></winioctl.h></windows.h>

Maxim_S_Shatskih · August 20, 2010, 5:36pm

> OK, I can see why you might be getting nothing. 0 is a perfectly valid

file handle. When CreateFile fails, it returns INVALID_HANDLE_VALUE,
which is -1.

Yes, but IIRC all other Win32 functions which create a kernel handle return NULL on failure, not INVALID_HANDLE_VALUE.

Have you ever really seen valid file handle == NULL?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

_Genius · August 20, 2010, 5:43pm

@ Tim Roberts :
You’re right, here’s the output from user-mode :

CreateFile failed, error 2

Peter Viscarola (OSR) :
It means both kernel & user applications running successfully but seems user-mode could not communicate with the driver.

I put the source codes!

anton_bassov · August 20, 2010, 5:57pm

> Have you ever really seen valid file handle == NULL?

No, simply because the process handle table has few entries already by the time your Main() is called…

Anton Bassov

Tim_Roberts · August 20, 2010, 6:10pm

Maxim S. Shatskih wrote:

> OK, I can see why you might be getting nothing. 0 is a perfectly valid
> file handle. When CreateFile fails, it returns INVALID_HANDLE_VALUE,
> which is -1.
Yes, but IIRC all other Win32 functions which create a kernel handle return NULL on failure, not INVALID_HANDLE_VALUE.

Have you ever really seen valid file handle == NULL?

No, but close. The handles for a console’s stdin, stdout and stderror
are 3, 11, and 15. The low bits probably have some special meaning.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim_Roberts · August 20, 2010, 6:11pm

xxxxx@yahoo.com wrote:

@ Tim Roberts :
You’re right, here’s the output from user-mode :

CreateFile failed, error 2

A quick browse of winerror.h will tell you that’s ERROR_FILE_NOT_FOUND.

How are you installing your driver?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

_Genius · August 20, 2010, 6:21pm

Simply by INSTDRV … .
Is it require to install via SCM ?

Don_Burn_1 · August 20, 2010, 6:24pm

The only customer of mine who used INSTDRV found it a good way to corrupt
systems. If you are doing a legacy driver, get the OSR Driver Loader

–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

wrote in message news:xxxxx@ntdev…
> Simply by INSTDRV … .
> Is it require to install via SCM ?
>
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 5383 (20100820)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

Information from ESET NOD32 Antivirus, version of virus signature database 5383 (20100820)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

mm1 · August 20, 2010, 6:36pm

http://www.osronline.com/OsrDown.cfm/osrloaderv30.zip?name=osrloaderv30.zip&
id=157

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, August 20, 2010 6:24 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IOCTL problem

The only customer of mine who used INSTDRV found it a good way to corrupt
systems. If you are doing a legacy driver, get the OSR Driver Loader

–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

wrote in message news:xxxxx@ntdev…
> Simply by INSTDRV … .
> Is it require to install via SCM ?
>
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 5383 (20100820)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

Information from ESET NOD32 Antivirus, version of virus signature
database 5383 (20100820)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Tim_Roberts · August 20, 2010, 7:14pm

xxxxx@yahoo.com wrote:

Simply by INSTDRV … .
Is it require to install via SCM ?

Yes, but INSTDRV must be using the SCM. There’s no other practical way
to do a legacy install without requiring a reboot.

It’s just not necessary. You can do the same thing from a command line:
copy mydriver.sys c:\windows\system32\drivers
sc create mydriver type= kernel start= demand binPath=
system32\drivers\mydriver.sys
net start mydriver

Loading a new version in is then just:
net stop mydriver
copy mydriver.sys c:\windows\system32\drivers
net start mydriver

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

OSR_Community_User · August 20, 2010, 7:30pm

As Don pointed out, the correct way is to use the CTL_CODE macro. Also, why
did you choose FILE_DEVICE_UNKNOWN as the device ID (the first 32K device
IDs are reserved for Microsoft, so why did you choose a number in that
range?). Why do you define the symbol in two different files? Why do you
not have a single header file that holds these definitions? (And do not do
as I’ve seen some people do, put them in a .h file with lots of kernel
symbols, the device extension, etc., then lots of complex #ifdefs to make
sure the kernel concepts don’t generate syntax errors; make a separate .h
file, and do the job right)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Friday, August 20, 2010 4:02 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IOCTL problem

Hi, just don’t know why the user-mode could not send the specified command
to kernel-mode component,

here's the source of user mode :  
#define BASE_IOCTL (FILE_DEVICE_UNKNOWN \<\< 16) | (FILE_READ_ACCESS \<\<  
14) | METHOD_BUFFERED  
#define IOCTL_DBG BASE_IOCTL | (1 \<\< 2)  
  
#include <windows.h><br>#include <winioctl.h><br>#include <stdio.h><br><br>int __cdecl main(void)<br>{<br> char szTemp[256] = {0};<br>***************************************************<br>Why is this here when it is not used for anything?<br>Also, why is it initialized if it is a buffer you<br>will read into? And why is it char instead of<br>unsigned char (BYTE)?<br>***************************************************<br>	HANDLE	hFile ;<br>	DWORD	dwReturn ;<br>	hFile =<br>CreateFile("\\\\.\\DeVx",GENERIC_READ|GENERIC_WRITE,0,NULL,OPEN_EXISTING,0,N<br>ULL);<br>	if(hFile)<br>	{<br><br>DeviceIoControl(hFile,IOCTL_DBG,NULL,0,NULL,0,&amp;dwReturn,NULL);<br>	}<br>	CloseHandle(hFile);<br>	return 0;<br>}<br>```<br><br>&amp; here's the kernel-mode :<br><br>```<br>#include <ntddk.h><br><br>typedef char * PCHAR;<br> **********************************************************************<br>Why are you using the char type when it makes more sense to use UCHAR?<br>********************************************************************** <br><br>#define BASE_IOCTL (FILE_DEVICE_UNKNOWN &lt;&lt; 16) | (FILE_READ_ACCESS &lt;&lt; 14) |<br>METHOD_BUFFERED<br>#define IOCTL_DBG BASE_IOCTL | (1 &lt;&lt; 2)<br><br>void ioDbg()<br>{	<br>	DbgPrint("\nioDbg - Successful - Congratulations!");	<br>}<br>NTSTATUS Unsupported_Function(PDEVICE_OBJECT DeviceObject, PIRP Irp)<br>{<br>	NTSTATUS NtStatus = STATUS_NOT_SUPPORTED;<br>	DbgPrint("\nUnsupported Function ...");<br>	return NtStatus ;<br>}<br>NTSTATUS eClose(PDEVICE_OBJECT DeviceObject, PIRP Irp)<br>{<br>	NTSTATUS NtStatus = STATUS_SUCCESS;<br>	DbgPrint("\neCLose()");<br> **********************************<br>And where do you complete the IRP?<br>********************************** <br>	return STATUS_SUCCESS;<br>}<br>NTSTATUS eCreate(PDEVICE_OBJECT DeviceObject, PIRP Irp)<br>{<br>	NTSTATUS NtStatus = STATUS_SUCCESS;<br>	DbgPrint("\neCreate");<br>	return NtStatus ;<br>}<br>NTSTATUS eIoControl(IN PDEVICE_OBJECT pDeviceObject, IN PIRP Irp)<br>{<br>	PIO_STACK_LOCATION	irpStack;<br>	NTSTATUS	NtStatus = STATUS_SUCCESS;<br>	PVOID inputBuffer;<br>	PVOID outputBuffer;<br>	ULONG inputBufferLength;<br>	ULONG outputBufferLength;<br>	ULONG ioctrlCode;<br>	Irp-&gt;IoStatus.Status = STATUS_SUCCESS;<br>	Irp-&gt;IoStatus.Information = 0;<br>	inputBuffer =	Irp-&gt;AssociatedIrp.SystemBuffer;<br>	outputBuffer	=	Irp-&gt;AssociatedIrp.SystemBuffer;<br><br>irpStack =	IoGetCurrentIrpStackLocation(Irp);<br>	inputBufferLength	=<br>irpStack-&gt;Parameters.DeviceIoControl.InputBufferLength;<br>	outputBufferLength	=<br>irpStack-&gt;Parameters.DeviceIoControl.OutputBufferLength;<br>	ioctrlCode =<br>irpStack-&gt;Parameters.DeviceIoControl.IoControlCode;<br>	DbgPrint("\neIoControl");<br>	switch(ioctrlCode)<br>	{<br> case	IOCTL_DBG:<br> ioDbg();<br> break;<br><br>default:<br> DbgPrint("\neIoControl - Error !");<br> break;<br>	}<br>	return STATUS_SUCCESS;<br><br>}<br>VOID	eUnload(PDRIVER_OBJECT DriverObject)<br>{<br>	UNICODE_STRING usDosDeviceName ;<br>	DbgPrint("\neUnload ...");<br>	RtlInitUnicodeString(&amp;usDosDeviceName,L"\\DosDevices\\DeVx");<br>	IoDeleteSymbolicLink(&amp;usDosDeviceName);<br>	IoDeleteDevice(DriverObject-&gt;DeviceObject);<br>}<br><br>NTSTATUS DriverEntry(IN PDRIVER_OBJECT pDriverObject, IN PUNICODE_STRING<br>RegistryPath)<br>{<br>	int i ;<br>	NTSTATUS NtStatus ;<br>	PDEVICE_OBJECT	pDeviceObject = NULL;<br>	UNICODE_STRING	usDriverName, usDosDeviceName ;<br>	DbgPrint("\nDriverEntry");<br>	RtlInitUnicodeString(&amp;usDriverName,L"\\Device\\DeVx") ;<br>	RtlInitUnicodeString(&amp;usDosDeviceName,L"\\DosDevices\\DeVx");<br>	NtStatus = IoCreateDevice(pDriverObject, 0,<br>&amp;usDriverName,FILE_DEVICE_UNKNOWN,FILE_DEVICE_SECURE_OPEN,FALSE,&amp;pDeviceObje<br>ct);<br>	if(NT_SUCCESS(NtStatus))<br>	{<br> for(i=0 ; i<irp_mj_maximum_function i> pDriverObject-&gt;MajorFunction[i] =<br>Unsupported_Function ;<br><br>pDriverObject-&gt;MajorFunction[IRP_MJ_CLOSE]<br>=	eClose;<br> pDriverObject-&gt;MajorFunction[IRP_MJ_CREATE]<br>=	eCreate;<br> pDriverObject-&gt;MajorFunction[IRP_MJ_DEVICE_CONTROL]<br>=	eIoControl;<br><br>pDriverObject-&gt;DriverUnload<br>=	eUnload; <br><br>IoCreateSymbolicLink(&amp;usDosDeviceName,&amp;usDriverName);<br>	}<br><br>return NtStatus ;<br>}<br>```<br><br>Simple IOCTL connection for just send an empty command to kernel-mode with<br>IOCTL_DBG &amp; this simply refer to ioDbg() function which just shows a<br>dbgprint statement to the kernel debugger .<br><br>If anyone could catch this sikt problem it's good to say here .<br>***************************************************************************<br>I fail to see where you did IoCompleteRequest on any of the IRPs, which<br>involves at least three lines of code<br>	Irp-&gt;IoStatus.Status = <some status code here>;<br> Irp-&gt;IoStatus.Information = <some value here>;<br> IoCompleteRequest(Irp);<br><br>As a legacy driver this is OK, but you will lose all power management in any<br>machine you install it on.<br><br>You should be starting with WDF.<br>****************************************************************************<br><br>regards.<br><br>---<br>NTDEV is sponsored by OSR<br><br>For our schedule of WDF, WDM, debugging and other seminars visit: <br>http://www.osr.com/seminars<br><br>To unsubscribe, visit the List Server section of OSR Online at<br>http://www.osronline.com/page.cfm?name=ListServer<br><br>-- <br>This message has been scanned for viruses and<br>dangerous content by MailScanner, and is<br>believed to be clean.</some></some></irp_mj_maximum_function></ntddk.h></stdio.h></winioctl.h></windows.h>