Problem with synchronous ReadFile() calls inside the NDIS miniport driver & some strange behaviour...please help URGENT

Hello all,

I am developing a NDIS miniport driver which also exposes a file interface
(for CreateFile(), ReadFile(), WriteFile() etc).I created this file
interface inside the MiniportInitialize() function using
NdisMRegisterDevice() API. There are few problems which I am getting as
follows:

1. If I try to assign different dispatch entry point functions then my
driver is breaking the system (I am getting blue screen). The only way to
avoid this I found is to use the same function for all the IRP dispatche
entry points like below:

DispatchTable[IRP_MJ_CREATE] = MyDeviceHook;

DispatchTable[IRP_MJ_CLOSE] = MyDeviceHook;

DispatchTable[IRP_MJ_READ] = MyDeviceHook;

DispatchTable[IRP_MJ_WRITE] = MyDeviceHook;

DispatchTable[IRP_MJ_DEVICE_CONTROL] = MyDeviceHook;

DispatchTable[IRP_MJ_CLEANUP] = MyDeviceHook;

NdisInitUnicodeString(&DeviceName, NT_DEVICE_NAME);

NdisInitUnicodeString(&DosDeviceName, DOS_DEVICE_NAME);

Status = NdisMRegisterDevice(g_NdisWrapperHandle,
&DeviceName,&DosDeviceName,&DispatchTable[0],&tapDevice->devObj,&tapDevice->handle);

and then use switch cases inside the MyDeviceHook() function for
pIrpSp->MajorFunction to direct to particular function for handling read,
write, close etc.

My question is why I am unable to specify different dispatch entry point
functions here? Is it something wrong with NDisMRegisterDevice() API. DDK
documentation says that I should use as many different dispatch entry point
functions for my different IRP_MJ_XXX codes handle by the driver.

2. Secondly I am using Cancel-Safe Irp (not Ex version) mechanism to pend
read Irps until data is available from the other end of my Ndis miniport (i
am transferring TCP/IP packets to my the user application via ReadFile()).
However, when a read Irp is pending and I call CloseHandle() from my user
application to close the handle, I expect that Close Irp will be called but
it never get called and my application hangs. Please tell me why is it
happening like that?

I am using WinDDK (2600~1.110) on my Windows XP machine. Please reply soon
as I am meeting deadlines.

Thanks,

Arsalan

anton
Mon Nov 13 16:10:02 CST 2006

Hi mate

> 1. If I try to assign different dispatch entry point functions then my
> driver is breaking the system (I am getting blue screen).

The very first thing that gets into my head is that, unlike
MyDeviceHook(), one of the above mentioned routines may be just buggy.
It never occured to you to think this way????

> However, when a read Irp is pending and I call CloseHandle() from my user
> application to close the handle, I expect that Close Irp will be called but
> it never get called and my application hangs.

What is "Close Irp"????? When the last open handle to the file object
gets closed, your driver receives either IRP_MJ_CLOSE (if there are no
outstanding IO requests on the file), or in IRP_MJ_CLEANUP( if there
are still some outstanding IO requests on the file) request.
In latter case, your driver must cancel and complete all currently
queued IRPs that are associated with the file object. Which of the
above mentioned requests "CloseIrp" handles????



Anton Bassov


Arsalan Ahmad wrote:
> Hello all,
>
> I am developing a NDIS miniport driver which also exposes a file interface
> (for CreateFile(), ReadFile(), WriteFile() etc).I created this file
> interface inside the MiniportInitialize() function using
> NdisMRegisterDevice() API. There are few problems which I am getting as
> follows:
>
> 1. If I try to assign different dispatch entry point functions then my
> driver is breaking the system (I am getting blue screen). The only way to
> avoid this I found is to use the same function for all the IRP dispatche
> entry points like below:
>
> DispatchTable[IRP_MJ_CREATE] = MyDeviceHook;
>
> DispatchTable[IRP_MJ_CLOSE] = MyDeviceHook;
>
> DispatchTable[IRP_MJ_READ] = MyDeviceHook;
>
> DispatchTable[IRP_MJ_WRITE] = MyDeviceHook;
>
> DispatchTable[IRP_MJ_DEVICE_CONTROL] = MyDeviceHook;
>
> DispatchTable[IRP_MJ_CLEANUP] = MyDeviceHook;
>
> NdisInitUnicodeString(&DeviceName, NT_DEVICE_NAME);
>
> NdisInitUnicodeString(&DosDeviceName, DOS_DEVICE_NAME);
>
> Status = NdisMRegisterDevice(g_NdisWrapperHandle,
> &DeviceName,&DosDeviceName,&DispatchTable[0],&tapDevice->devObj,&tapDevice->handle);
>
> and then use switch cases inside the MyDeviceHook() function for
> pIrpSp->MajorFunction to direct to particular function for handling read,
> write, close etc.
>
> My question is why I am unable to specify different dispatch entry point
> functions here? Is it something wrong with NDisMRegisterDevice() API. DDK
> documentation says that I should use as many different dispatch entry point
> functions for my different IRP_MJ_XXX codes handle by the driver.
>
> 2. Secondly I am using Cancel-Safe Irp (not Ex version) mechanism to pend
> read Irps until data is available from the other end of my Ndis miniport (i
> am transferring TCP/IP packets to my the user application via ReadFile()).
> However, when a read Irp is pending and I call CloseHandle() from my user
> application to close the handle, I expect that Close Irp will be called but
> it never get called and my application hangs. Please tell me why is it
> happening like that?
>
> I am using WinDDK (2600~1.110) on my Windows XP machine. Please reply soon
> as I am meeting deadlines.
>
> Thanks,
>
> Arsalan

Arsalan
Tue Nov 14 03:33:12 CST 2006

The problem is that I have a pending IO request (for IRP_MJ_READ) queued in
the driver and once I have queued this request then if I try to call
WriteFile() or CloseHandle() to the file handle then I do not recieve
equivalent IRP_MJ_WRITE or IRP_MJ_CLOSE request in the driver. Neither does
I get IRP_MJ_CLEANUP. May be something wrong in my code in IRP_MJ_READ
handler in which I queue the Irp. The code for IRP_MJ_READ handler is below:

NTSTATUS NtStatus = STATUS_SUCCESS;

pIrpSp = IoGetCurrentIrpStackLocation(pIrp);

pIrp->IoStatus.Information = 0;

UCHAR *pBuffer = NULL;

NdisAcquireSpinLock(&g_pAdapter->ReadLock);

if(QueueCount(g_pAdapter->ReadQueue) > 0)

{

pBuffer = Pop(g_pAdapter->ReadQueue, &len);

}

NdisReleaseSpinLock(&g_pAdapter->ReadLock);

if(pBuffer)

{

pIrp->IoStatus.Information = pIrpSp->Parameters.Read.Length;

NtStatus = CompleteIRP(g_pAdapter, pIrp, pBuffer, len, IO_NO_INCREMENT);

}

else

{

IoCsqInsertIrp(&g_pAdapter->CancelSafeQueue, pIrp, NULL);

NtStatus = STATUS_PENDING;

}

return NtStatus;

So any idea what is wrong why other IRP_MJ_XXX handlers are not being called
while I have a pending IRP_MJ_READ Irp?

Thanks,

Arsalan

>
> What is "Close Irp"????? When the last open handle to the file object
> gets closed, your driver receives either IRP_MJ_CLOSE (if there are no
> outstanding IO requests on the file), or in IRP_MJ_CLEANUP( if there
> are still some outstanding IO requests on the file) request.
> In latter case, your driver must cancel and complete all currently
> queued IRPs that are associated with the file object. Which of the
> above mentioned requests "CloseIrp" handles????
>

Arsalan
Tue Nov 14 04:43:25 CST 2006

One thing I like to mention is that I am using Direct I/O mechanism i.e. I
have set my device->Flags to DO_DIRECT_IO.


"Arsalan Ahmad" <arsal__@hotmail.com> wrote in message
news:%230vUk$8BHHA.4472@TK2MSFTNGP03.phx.gbl...
> The problem is that I have a pending IO request (for IRP_MJ_READ) queued
> in the driver and once I have queued this request then if I try to call
> WriteFile() or CloseHandle() to the file handle then I do not recieve
> equivalent IRP_MJ_WRITE or IRP_MJ_CLOSE request in the driver. Neither
> does I get IRP_MJ_CLEANUP. May be something wrong in my code in
> IRP_MJ_READ handler in which I queue the Irp. The code for IRP_MJ_READ
> handler is below:
>
> NTSTATUS NtStatus = STATUS_SUCCESS;
>
> pIrpSp = IoGetCurrentIrpStackLocation(pIrp);
>
> pIrp->IoStatus.Information = 0;
>
> UCHAR *pBuffer = NULL;
>
> NdisAcquireSpinLock(&g_pAdapter->ReadLock);
>
> if(QueueCount(g_pAdapter->ReadQueue) > 0)
>
> {
>
> pBuffer = Pop(g_pAdapter->ReadQueue, &len);
>
> }
>
> NdisReleaseSpinLock(&g_pAdapter->ReadLock);
>
> if(pBuffer)
>
> {
>
> pIrp->IoStatus.Information = pIrpSp->Parameters.Read.Length;
>
> NtStatus = CompleteIRP(g_pAdapter, pIrp, pBuffer, len,
> IO_NO_INCREMENT);
>
> }
>
> else
>
> {
>
> IoCsqInsertIrp(&g_pAdapter->CancelSafeQueue, pIrp, NULL);
>
> NtStatus = STATUS_PENDING;
>
> }
>
> return NtStatus;
>
> So any idea what is wrong why other IRP_MJ_XXX handlers are not being
> called while I have a pending IRP_MJ_READ Irp?
>
> Thanks,
>
> Arsalan
>
>>
>> What is "Close Irp"????? When the last open handle to the file object
>> gets closed, your driver receives either IRP_MJ_CLOSE (if there are no
>> outstanding IO requests on the file), or in IRP_MJ_CLEANUP( if there
>> are still some outstanding IO requests on the file) request.
>> In latter case, your driver must cancel and complete all currently
>> queued IRPs that are associated with the file object. Which of the
>> above mentioned requests "CloseIrp" handles????
>>
>
>

Arsalan
Tue Nov 14 06:34:39 CST 2006

One thing more I am opening the file handle to my driver without using
overlapped IO so is this something that is causing this problem?


"Arsalan Ahmad" <arsal__@hotmail.com> wrote in message
news:%23GySxm9BHHA.2128@TK2MSFTNGP04.phx.gbl...
> One thing I like to mention is that I am using Direct I/O mechanism i.e. I
> have set my device->Flags to DO_DIRECT_IO.
>
>
> "Arsalan Ahmad" <arsal__@hotmail.com> wrote in message
> news:%230vUk$8BHHA.4472@TK2MSFTNGP03.phx.gbl...
>> The problem is that I have a pending IO request (for IRP_MJ_READ) queued
>> in the driver and once I have queued this request then if I try to call
>> WriteFile() or CloseHandle() to the file handle then I do not recieve
>> equivalent IRP_MJ_WRITE or IRP_MJ_CLOSE request in the driver. Neither
>> does I get IRP_MJ_CLEANUP. May be something wrong in my code in
>> IRP_MJ_READ handler in which I queue the Irp. The code for IRP_MJ_READ
>> handler is below:
>>
>> NTSTATUS NtStatus = STATUS_SUCCESS;
>>
>> pIrpSp = IoGetCurrentIrpStackLocation(pIrp);
>>
>> pIrp->IoStatus.Information = 0;
>>
>> UCHAR *pBuffer = NULL;
>>
>> NdisAcquireSpinLock(&g_pAdapter->ReadLock);
>>
>> if(QueueCount(g_pAdapter->ReadQueue) > 0)
>>
>> {
>>
>> pBuffer = Pop(g_pAdapter->ReadQueue, &len);
>>
>> }
>>
>> NdisReleaseSpinLock(&g_pAdapter->ReadLock);
>>
>> if(pBuffer)
>>
>> {
>>
>> pIrp->IoStatus.Information = pIrpSp->Parameters.Read.Length;
>>
>> NtStatus = CompleteIRP(g_pAdapter, pIrp, pBuffer, len,
>> IO_NO_INCREMENT);
>>
>> }
>>
>> else
>>
>> {
>>
>> IoCsqInsertIrp(&g_pAdapter->CancelSafeQueue, pIrp, NULL);
>>
>> NtStatus = STATUS_PENDING;
>>
>> }
>>
>> return NtStatus;
>>
>> So any idea what is wrong why other IRP_MJ_XXX handlers are not being
>> called while I have a pending IRP_MJ_READ Irp?
>>
>> Thanks,
>>
>> Arsalan
>>
>>>
>>> What is "Close Irp"????? When the last open handle to the file object
>>> gets closed, your driver receives either IRP_MJ_CLOSE (if there are no
>>> outstanding IO requests on the file), or in IRP_MJ_CLEANUP( if there
>>> are still some outstanding IO requests on the file) request.
>>> In latter case, your driver must cancel and complete all currently
>>> queued IRPs that are associated with the file object. Which of the
>>> above mentioned requests "CloseIrp" handles????
>>>
>>
>>
>
>

soviet_bloke
Tue Nov 14 09:53:15 CST 2006

> One thing more I am opening the file handle to my driver without using
> overlapped IO so is this something that is causing this problem?

This is what you should have started with.......


If you want to do asynchronous IO, you have to do it as
ReadFileEx()/WriteFileEx(), rather than simply ReadFile()/WriteFile(),
and, in order to do it, file handle has to be opened with
FILE_FLAG_OVERLAPPED flag

Anton Bassov

Arsalan Ahmad wrote:
> One thing more I am opening the file handle to my driver without using
> overlapped IO so is this something that is causing this problem?
>
>
> "Arsalan Ahmad" <arsal__@hotmail.com> wrote in message
> news:%23GySxm9BHHA.2128@TK2MSFTNGP04.phx.gbl...
> > One thing I like to mention is that I am using Direct I/O mechanism i.e. I
> > have set my device->Flags to DO_DIRECT_IO.
> >
> >
> > "Arsalan Ahmad" <arsal__@hotmail.com> wrote in message
> > news:%230vUk$8BHHA.4472@TK2MSFTNGP03.phx.gbl...
> >> The problem is that I have a pending IO request (for IRP_MJ_READ) queued
> >> in the driver and once I have queued this request then if I try to call
> >> WriteFile() or CloseHandle() to the file handle then I do not recieve
> >> equivalent IRP_MJ_WRITE or IRP_MJ_CLOSE request in the driver. Neither
> >> does I get IRP_MJ_CLEANUP. May be something wrong in my code in
> >> IRP_MJ_READ handler in which I queue the Irp. The code for IRP_MJ_READ
> >> handler is below:
> >>
> >> NTSTATUS NtStatus = STATUS_SUCCESS;
> >>
> >> pIrpSp = IoGetCurrentIrpStackLocation(pIrp);
> >>
> >> pIrp->IoStatus.Information = 0;
> >>
> >> UCHAR *pBuffer = NULL;
> >>
> >> NdisAcquireSpinLock(&g_pAdapter->ReadLock);
> >>
> >> if(QueueCount(g_pAdapter->ReadQueue) > 0)
> >>
> >> {
> >>
> >> pBuffer = Pop(g_pAdapter->ReadQueue, &len);
> >>
> >> }
> >>
> >> NdisReleaseSpinLock(&g_pAdapter->ReadLock);
> >>
> >> if(pBuffer)
> >>
> >> {
> >>
> >> pIrp->IoStatus.Information = pIrpSp->Parameters.Read.Length;
> >>
> >> NtStatus = CompleteIRP(g_pAdapter, pIrp, pBuffer, len,
> >> IO_NO_INCREMENT);
> >>
> >> }
> >>
> >> else
> >>
> >> {
> >>
> >> IoCsqInsertIrp(&g_pAdapter->CancelSafeQueue, pIrp, NULL);
> >>
> >> NtStatus = STATUS_PENDING;
> >>
> >> }
> >>
> >> return NtStatus;
> >>
> >> So any idea what is wrong why other IRP_MJ_XXX handlers are not being
> >> called while I have a pending IRP_MJ_READ Irp?
> >>
> >> Thanks,
> >>
> >> Arsalan
> >>
> >>>
> >>> What is "Close Irp"????? When the last open handle to the file object
> >>> gets closed, your driver receives either IRP_MJ_CLOSE (if there are no
> >>> outstanding IO requests on the file), or in IRP_MJ_CLEANUP( if there
> >>> are still some outstanding IO requests on the file) request.
> >>> In latter case, your driver must cancel and complete all currently
> >>> queued IRPs that are associated with the file object. Which of the
> >>> above mentioned requests "CloseIrp" handles????
> >>>
> >>
> >>
> >
> >

Don
Tue Nov 14 09:59:28 CST 2006


<soviet_bloke@hotmail.com> wrote in message
> If you want to do asynchronous IO, you have to do it as
> ReadFileEx()/WriteFileEx(), rather than simply ReadFile()/WriteFile(),
> and, in order to do it, file handle has to be opened with
> FILE_FLAG_OVERLAPPED flag

Sorry, Anton this is incorrect. You can do this fine with
ReadFile/WriteFile with an overlapped structure and support code to check
the event. The Ex version's of the calls are newer and nicer, but
asynchronous I/O has been around for a lot longer than those calls.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

soviet_bloke
Tue Nov 14 15:04:37 CST 2006

Don,

> Sorry, Anton this is incorrect. You can do this fine with
> ReadFile/WriteFile with an overlapped structure and support code to check
> the event.

Actually, this is true. Thank you for correction. To be honest, in my
mind asynchronous IO is always associated with a completion routine,
which is just one possible form of overlapped IO, so that, whenever I
hear "asynchronous IO", the immediate association is
callback and ReadFileEx/WriteFileEx (which is wrong)


However, no matter how you do overlapped IO, you still need
FILE_FLAG_OVERLAPPED flag. I believe this is the main reason for the
OP's problem.....

Anton Bassov


Don Burn wrote:
> <soviet_bloke@hotmail.com> wrote in message
> > If you want to do asynchronous IO, you have to do it as
> > ReadFileEx()/WriteFileEx(), rather than simply ReadFile()/WriteFile(),
> > and, in order to do it, file handle has to be opened with
> > FILE_FLAG_OVERLAPPED flag
>
> Sorry, Anton this is incorrect. You can do this fine with
> ReadFile/WriteFile with an overlapped structure and support code to check
> the event. The Ex version's of the calls are newer and nicer, but
> asynchronous I/O has been around for a lot longer than those calls.
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply

Arsalan
Wed Nov 15 03:43:44 CST 2006

Hello all,

Thanks for all the replies. The problem is now solved. Actually I was
opening the file handle without using overlapped flag and then was creating
two threads one for reading and one for writing. If overlapped flag not used
then my read call was blocking and even though I call WriteFile() from the
other thread it was blocked as well. So stupid of me not to realize this
before. Well anyway thanks for all the help.

Best Regards,

Arsalan


<soviet_bloke@hotmail.com> wrote in message
news:1163538277.382421.38350@b28g2000cwb.googlegroups.com...
> Don,
>
>> Sorry, Anton this is incorrect. You can do this fine with
>> ReadFile/WriteFile with an overlapped structure and support code to check
>> the event.
>
> Actually, this is true. Thank you for correction. To be honest, in my
> mind asynchronous IO is always associated with a completion routine,
> which is just one possible form of overlapped IO, so that, whenever I
> hear "asynchronous IO", the immediate association is
> callback and ReadFileEx/WriteFileEx (which is wrong)
>
>
> However, no matter how you do overlapped IO, you still need
> FILE_FLAG_OVERLAPPED flag. I believe this is the main reason for the
> OP's problem.....
>
> Anton Bassov
>
>
> Don Burn wrote:
>> <soviet_bloke@hotmail.com> wrote in message
>> > If you want to do asynchronous IO, you have to do it as
>> > ReadFileEx()/WriteFileEx(), rather than simply ReadFile()/WriteFile(),
>> > and, in order to do it, file handle has to be opened with
>> > FILE_FLAG_OVERLAPPED flag
>>
>> Sorry, Anton this is incorrect. You can do this fine with
>> ReadFile/WriteFile with an overlapped structure and support code to check
>> the event. The Ex version's of the calls are newer and nicer, but
>> asynchronous I/O has been around for a lot longer than those calls.
>>
>>
>> --
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> http://www.windrvr.com
>> Remove StopSpam from the email to reply
>