Done Some Harm

Hi again,

It appears that my serial filter driver has broken Walt Oney’s “do no harm”
rule. When the driver is in place on the modem port, using Windows “Dial Up
Networking” to connect to the Internet results in a failure. But, when I
test the driver by typing characters through it using HyperTerminal I can’t
see a problem. Of course, when establishing a dial-up connection *without*
the driver in place all is OK.

So it apears as though I am corrupting something to do with the read and/or
write data passing through the driver but I can’t see what could be wrong. I
just pass the IRP_MJ_WRITE stuff straight down like this:

NTSTATUS DispatchWrite(PDEVICE_OBJECT fdo, PIRP Irp)
{
NTSTATUS status;

PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fdo->DeviceExtension;

PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);
// Do write data storage here…

status = IoAcquireRemoveLock(&pdx->RemoveLock,Irp);
if (!NT_SUCCESS(status))
return CompleteRequest(Irp, status, 0);

IoSkipCurrentIrpStackLocation(Irp);
status = IoCallDriver(pdx->LowerDeviceObject,Irp);
IoReleaseRemoveLock(&pdx->RemoveLock,Irp);
return status;
}

And IRP_MJ_READ is like this:

NTSTATUS DispatchRead(PDEVICE_OBJECT fdo, PIRP Irp)
{
NTSTATUS status;

PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fdo->DeviceExtension;

PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);

status = IoAcquireRemoveLock(&pdx->RemoveLock,Irp);
if (!NT_SUCCESS(status))
return CompleteRequest(Irp, status, 0);

IoCopyCurrentIrpStackLocationToNext(Irp);
IoSetCompletionRoutine(Irp,
(PIO_COMPLETION_ROUTINE) CompletionRoutine,
pdx,
TRUE, // InvokeOnSuccess.
FALSE, // InvokeOnError.
FALSE); // InvokeOnCancel.

status = IoCallDriver(pdx->LowerDeviceObject,Irp);
return status;
}

And my completion routine looks like this:

NTSTATUS CompletionRoutine(PDEVICE_OBJECT fdo,PIRP Irp,PDEVICE_EXTENSION
pdx)
{
if (Irp->PendingReturned)
IoMarkIrpPending(Irp);

PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);
// Do read data storage here…

IoReleaseRemoveLock(&pdx->RemoveLock, Irp);

return STATUS_SUCCESS;
}

In addition to this the data length that I see in the completion routine is
not correct, it appears from visual inspection that the start of the
SystemBuffer contains valid data but the length is much higher than the
actual data content. The length I see in the completion routine appears to
be the same as the length passed down in the read request rather than the
actual length of the data received.

Once again thanks for all the help you have given me so far, I would not
have got to this stage without you.

Alasdair

NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.

In the completion routine, are you looking at IoStatus.Information for the number of bytes returned ? or are you looking the current stack location Parameters.Read.Length ? you need to look at the information field. The parameters field is an indication of how large the buffer is, not how many bytes were copied into it.

d


From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alasdair Tompson (external)
Sent: Friday, October 08, 2004 4:11 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Done Some Harm

Hi again,
It appears that my serial filter driver has broken Walt Oney’s “do no harm” rule. When the driver is in place on the modem port, using Windows “Dial Up Networking” to connect to the Internet results in a failure. But, when I test the driver by typing characters through it using HyperTerminal I can’t see a problem. Of course, when establishing a dial-up connection *without* the driver in place all is OK.
So it apears as though I am corrupting something to do with the read and/or write data passing through the driver but I can’t see what could be wrong. I just pass the IRP_MJ_WRITE stuff straight down like this:

NTSTATUS DispatchWrite(PDEVICE_OBJECT fdo, PIRP Irp)
{
??? NTSTATUS status;
??? PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fdo->DeviceExtension;
??? PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);
??? // Do write data storage here…
??? status = IoAcquireRemoveLock(&pdx->RemoveLock,Irp);
??? if (!NT_SUCCESS(status))
??? ??? return CompleteRequest(Irp, status, 0);
??? IoSkipCurrentIrpStackLocation(Irp);
??? status = IoCallDriver(pdx->LowerDeviceObject,Irp);
??? IoReleaseRemoveLock(&pdx->RemoveLock,Irp);
??? return status;
}

And IRP_MJ_READ is like this:

NTSTATUS DispatchRead(PDEVICE_OBJECT fdo, PIRP Irp)
{
??? NTSTATUS status;
??? PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fdo->DeviceExtension;
??? PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);
??? status = IoAcquireRemoveLock(&pdx->RemoveLock,Irp);
??? if (!NT_SUCCESS(status))
??? ??? return CompleteRequest(Irp, status, 0);
??? IoCopyCurrentIrpStackLocationToNext(Irp);
??? IoSetCompletionRoutine(Irp,
??? ??? (PIO_COMPLETION_ROUTINE) CompletionRoutine,
??? ??? pdx,
??? ??? TRUE,?? ??? // InvokeOnSuccess.
??? ??? FALSE,? // InvokeOnError.
??? ??? FALSE); // InvokeOnCancel.
??? status = IoCallDriver(pdx->LowerDeviceObject,Irp);
??? return status;
}

And my completion routine looks like this:

NTSTATUS CompletionRoutine(PDEVICE_OBJECT fdo,PIRP Irp,PDEVICE_EXTENSION pdx)
{
??? if (Irp->PendingReturned)
??? ??? IoMarkIrpPending(Irp);
??? PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);
??? // Do read data storage here…
??? IoReleaseRemoveLock(&pdx->RemoveLock, Irp);
??? return STATUS_SUCCESS;
}

In addition to this the data length that I see in the completion routine is not correct, it appears from visual inspection that the start of the SystemBuffer contains valid data but the length is much higher than the actual data content. The length I see in the completion routine appears to be the same as the length passed down in the read request rather than the actual length of the data received.
Once again thanks for all the help you have given me so far, I would not have got to this stage without you.
Alasdair

NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.? If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents.? We cannot accept liability for any breaches of confidence arising through use of email.? Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions.? We will not accept responsibility for any commitments made by our employees outside the scope of our business.? We do not warrant the accuracy or completeness of such information.

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Hi Doron,

Thanks - You are right. I can see now that in the completion routine the
count is in the “Information” field, in the DispatchWrite routine it is in
the current stack location. I still have a bug somewhere though as the count
here now appears to be too small and with my filter installed the dial up
connection fails. I seem to be “losing” some data somewere.

Regards

Alasdair

-----Original Message-----
From: Doron Holan [mailto:xxxxx@windows.microsoft.com]
Sent: 08 October 2004 17:17
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Done Some Harm

In the completion routine, are you looking at
IoStatus.Information for the number of bytes returned ? or
are you looking the current stack location
Parameters.Read.Length ? you need to look at the information
field. The parameters field is an indication of how large
the buffer is, not how many bytes were copied into it.

d


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
Alasdair Tompson (external)
Sent: Friday, October 08, 2004 4:11 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Done Some Harm

Hi again,
It appears that my serial filter driver has broken Walt
Oney’s “do no harm” rule. When the driver is in place on the
modem port, using Windows “Dial Up Networking” to connect to
the Internet results in a failure. But, when I test the
driver by typing characters through it using HyperTerminal I
can’t see a problem. Of course, when establishing a dial-up
connection *without* the driver in place all is OK. So it
apears as though I am corrupting something to do with the
read and/or write data passing through the driver but I can’t
see what could be wrong. I just pass the IRP_MJ_WRITE stuff
straight down like this:

NTSTATUS DispatchWrite(PDEVICE_OBJECT fdo, PIRP Irp)
{
??? NTSTATUS status;
??? PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION)
fdo->DeviceExtension;
??? PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);
??? // Do write data storage here…
??? status = IoAcquireRemoveLock(&pdx->RemoveLock,Irp);
??? if (!NT_SUCCESS(status))
??? ??? return CompleteRequest(Irp, status, 0);
??? IoSkipCurrentIrpStackLocation(Irp);
??? status = IoCallDriver(pdx->LowerDeviceObject,Irp);
??? IoReleaseRemoveLock(&pdx->RemoveLock,Irp);
??? return status;
}

And IRP_MJ_READ is like this:

NTSTATUS DispatchRead(PDEVICE_OBJECT fdo, PIRP Irp)
{
??? NTSTATUS status;
??? PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION)
fdo->DeviceExtension;
??? PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);
??? status = IoAcquireRemoveLock(&pdx->RemoveLock,Irp);
??? if (!NT_SUCCESS(status))
??? ??? return CompleteRequest(Irp, status, 0);
??? IoCopyCurrentIrpStackLocationToNext(Irp);
??? IoSetCompletionRoutine(Irp,
??? ??? (PIO_COMPLETION_ROUTINE) CompletionRoutine,
??? ??? pdx,
??? ??? TRUE,?? ??? // InvokeOnSuccess.
??? ??? FALSE,? // InvokeOnError.
??? ??? FALSE); // InvokeOnCancel.
??? status = IoCallDriver(pdx->LowerDeviceObject,Irp);
??? return status;
}

And my completion routine looks like this:

NTSTATUS CompletionRoutine(PDEVICE_OBJECT fdo,PIRP
Irp,PDEVICE_EXTENSION pdx)
{
??? if (Irp->PendingReturned)
??? ??? IoMarkIrpPending(Irp);
??? PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);
??? // Do read data storage here…
??? IoReleaseRemoveLock(&pdx->RemoveLock, Irp);
??? return STATUS_SUCCESS;
}

In addition to this the data length that I see in the
completion routine is not correct, it appears from visual
inspection that the start of the SystemBuffer contains valid
data but the length is much higher than the actual data
content. The length I see in the completion routine appears
to be the same as the length passed down in the read request
rather than the actual length of the data received. Once
again thanks for all the help you have given me so far, I
would not have got to this stage without you.
Alasdair

NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.? If you
have received this email in error please notify the sender
immediately and delete this email from your system without
copying or disseminating it or placing any reliance upon its
contents.? We cannot accept liability for any breaches of
confidence arising through use of email.? Any opinions
expressed in this email (including attachments) are those of
the author and do not necessarily reflect our opinions.? We
will not accept responsibility for any commitments made by
our employees outside the scope of our business.? We do not
warrant the accuracy or completeness of such information.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’ To unsubscribe send a blank email to
xxxxx@lists.osr.com

NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.