about READ_PORT_ULONG

hi

I find it in many driver sample especially pci driver sample that
READ_PORT_ULONG is mainly on the OnInterrupt routine?

what if my device has no support for interrupt, say its a custom
hardware.
Where should such READ_PORT be?

ps.
How a StartDevice() routine is called?

krby_xtrm

Doron
Wed Dec 28 10:57:12 CST 2005

you can read the port from any routine as long as the device is powered on.
you can read the port in start device or a DPC or whatever context you
choose.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"krby_xtrm" <kerby.martino@gmail.com> wrote in message
news:1135778137.201931.148370@f14g2000cwb.googlegroups.com...
> hi
>
> I find it in many driver sample especially pci driver sample that
> READ_PORT_ULONG is mainly on the OnInterrupt routine?
>
> what if my device has no support for interrupt, say its a custom
> hardware.
> Where should such READ_PORT be?
>
> ps.
> How a StartDevice() routine is called?
>
> krby_xtrm
>

krby_xtrm
Wed Dec 28 11:31:06 CST 2005

i see.
but how does a StartDevice() is called?coz i cant find in many driver
samples that the routine is assigned or called?

-krby_xtrm-

Ali
Wed Dec 28 11:48:39 CST 2005

StartDevice is a helper routine you write to handle the details of
extracting and dealing with configuration information. In sample
drivers of Walter O. book "Windows Driver Model" , you can check the
source module named READWRITE.CPP for StartDevice understanding.

/ali

Eric
Wed Dec 28 11:59:14 CST 2005

It just helper function. don't mind driver model. but, check carefully
power of device.
If you know wdm or NT driver model, just use it.

Don
Wed Dec 28 12:11:40 CST 2005

StartDevice is just a common name for the code to handle IRP_MN_START_DEVICE
which is a sub-code of IRP_MJ_PNP. It can have anyname you want or be part
of a more general routine handling IRP_MJ_PNP. Look for IRP_MN_START_DEVICE
in samples and you will get the gist of it.


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



"krby_xtrm" <kerby.martino@gmail.com> wrote in message
news:1135791066.365035.193170@g47g2000cwa.googlegroups.com...
>i see.
> but how does a StartDevice() is called?coz i cant find in many driver
> samples that the routine is assigned or called?
>
> -krby_xtrm-
>

Ali
Wed Dec 28 12:32:51 CST 2005

Isn't StartDevice wdm version of CreateDispatch or DisatchIO? in good
nt days without IRP_MJ_PNP.

Don
Wed Dec 28 12:36:41 CST 2005

You are thinking of StartIo something totally different, and only used by
slow devices.


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



"Ali" <abdulrazaq@gmail.com> wrote in message
news:1135794771.114669.113930@g43g2000cwa.googlegroups.com...
> Isn't StartDevice wdm version of CreateDispatch or DisatchIO? in good
> nt days without IRP_MJ_PNP.
>

krby_xtrm
Wed Dec 28 23:42:33 CST 2005

Yes. I think I know that, I have minor function IRP_MN_START_DEVICE in
my Pnp Dispatch routine.

NTSTATUS PciWDMPnp (IN PDEVICE_OBJECT fdo, IN PIRP Irp)
{
...
ULONG MinorFunction = IrpStack->MinorFunction;
...
switch(MinorFunction)
{
case IRP_MN_START_DEVICE:
// we should check the allocated resource...
KdPrint((DRIVERNAME " - IRP_MN_START_DEVICE"));
//
break;
case IRP_MN_REMOVE_DEVICE:
KdPrint((DRIVERNAME " - IRP_MN_REMOVE_DEVICE"));
if(pdx->LowerDeviceObject)
IoDetachDevice(pdx->LowerDeviceObject);
IoDeleteDevice(fdo); // delete fdo
break;
}
...
}

and my start device:

NTSTATUS StartDevice(PDEVICE_OBJECT fdo, PCM_PARTIAL_RESOURCE_LIST raw,
PCM_PARTIAL_RESOURCE_LIST translated)
{
...
PHYSICAL_ADDRESS portbase;// base address of range
BOOLEAN gotport = FALSE;

PCM_PARTIAL_RESOURCE_DESCRIPTOR resource =
translated->PartialDescriptors;
ULONG nres = translated->Count;

for (ULONG i = 0; i < nres; ++i, ++resource)
{ // for each resource
switch (resource->Type)
{ // switch on resource type
case CmResourceTypePort:
portbase = resource->u.Port.Start;
pdx->nports = resource->u.Port.Length;
pdx->mappedport = (resource->Flags & CM_RESOURCE_PORT_IO) == 0;
gotport = TRUE;
break;
default:
KdPrint((DRIVERNAME " - Unexpected I/O resource type %d\n",
resource->Type));
break;
}
}
....
}

pavel_a
Thu Dec 29 08:46:04 CST 2005

Well it's your driver, you decide how to call your internal function from
PciWDMPnp.
Or just copy what the DDK samples do. To look up function
names in the sources - From Visual Studio:
Edit -> Find and replace -> Find in files

--PA

"krby_xtrm" wrote:
> Yes. I think I know that, I have minor function IRP_MN_START_DEVICE in
> my Pnp Dispatch routine.
>
> NTSTATUS PciWDMPnp (IN PDEVICE_OBJECT fdo, IN PIRP Irp)
> {
> ....
> ULONG MinorFunction = IrpStack->MinorFunction;
> ....
> switch(MinorFunction)
> {
> case IRP_MN_START_DEVICE:
> // we should check the allocated resource...
> KdPrint((DRIVERNAME " - IRP_MN_START_DEVICE"));
> //
> break;
> case IRP_MN_REMOVE_DEVICE:
> KdPrint((DRIVERNAME " - IRP_MN_REMOVE_DEVICE"));
> if(pdx->LowerDeviceObject)
> IoDetachDevice(pdx->LowerDeviceObject);
> IoDeleteDevice(fdo); // delete fdo
> break;
> }
> ....
> }
>
> and my start device:
>
> NTSTATUS StartDevice(PDEVICE_OBJECT fdo, PCM_PARTIAL_RESOURCE_LIST raw,
> PCM_PARTIAL_RESOURCE_LIST translated)
> {
> ....
> PHYSICAL_ADDRESS portbase;// base address of range
> BOOLEAN gotport = FALSE;
>
> PCM_PARTIAL_RESOURCE_DESCRIPTOR resource =
> translated->PartialDescriptors;
> ULONG nres = translated->Count;
>
> for (ULONG i = 0; i < nres; ++i, ++resource)
> { // for each resource
> switch (resource->Type)
> { // switch on resource type
> case CmResourceTypePort:
> portbase = resource->u.Port.Start;
> pdx->nports = resource->u.Port.Length;
> pdx->mappedport = (resource->Flags & CM_RESOURCE_PORT_IO) == 0;
> gotport = TRUE;
> break;
> default:
> KdPrint((DRIVERNAME " - Unexpected I/O resource type %d\n",
> resource->Type));
> break;
> }
> }
> .....
> }
>
>

krby_xtrm
Thu Dec 29 10:27:04 CST 2005

Yes, but based on the code i presented. Should I call StartDevice upon
recieving IRP_MN_START_DEVICE in PciWDMPnp?

There in my StartDevice, i think after the iteration, 'portbase' should
have already the start address for I/O mapped resource of my device, is
that correct?

Is the driver ready to perform I/O operation then?
like READ_PORT_xxx(pdx->portbase + offset) ???

krby_xtrm

Don
Thu Dec 29 10:31:45 CST 2005

Yes it looks like you should have called StartDevice upon recieving
IRP_MN_START_DEVICE. Your device is then ready to perform I/O until a stop
device or related occurs.


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



"krby_xtrm" <kerby.martino@gmail.com> wrote in message
news:1135873624.157616.249550@g14g2000cwa.googlegroups.com...
> Yes, but based on the code i presented. Should I call StartDevice upon
> recieving IRP_MN_START_DEVICE in PciWDMPnp?
>
> There in my StartDevice, i think after the iteration, 'portbase' should
> have already the start address for I/O mapped resource of my device, is
> that correct?
>
> Is the driver ready to perform I/O operation then?
> like READ_PORT_xxx(pdx->portbase + offset) ???
>
> krby_xtrm
>

pavel_a
Thu Dec 29 11:58:03 CST 2005

"krby_xtrm" wrote:
> Yes, but based on the code i presented. Should I call StartDevice upon
> recieving IRP_MN_START_DEVICE in PciWDMPnp?

This depends on your situation. For example, the pcidrv sample from
the DDK 3790.1830 delays the StartDevice processing in the driver
using a worker item. Study this sample, read the comments Eliyas put there...

--PA

> There in my StartDevice, i think after the iteration, 'portbase' should
> have already the start address for I/O mapped resource of my device, is
> that correct?
>
> Is the driver ready to perform I/O operation then?
> like READ_PORT_xxx(pdx->portbase + offset) ???
>
> krby_xtrm
>
>

krby_xtrm
Thu Dec 29 20:05:59 CST 2005

i found this thread:
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/214d3c196479ce01/c687b1aa693e043d?q=pci+startdevice&rnum=6#c687b1aa693e043d

my question is, is that the right way to call StartDevice routine?

-krby-

krby_xtrm
Thu Dec 29 20:26:38 CST 2005

// This is my complete Pnp Dispatch routine:
NTSTATUS PciWDMPnp (IN PDEVICE_OBJECT fdo, IN PIRP Irp)
{
DbgPrint(DRIVERNAME " - Begin WDM Pnp");

PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION)fdo->DeviceExtension;
PIO_STACK_LOCATION IrpStack = IoGetCurrentIrpStackLocation(Irp); //
obtain current IRP

ULONG MinorFunction = IrpStack->MinorFunction;

// sends an IRP to the driver associated with a specified device
object.
// pdx->LowerDeviceObject, representing the target device for the
requested I/O operation.
NTSTATUS status = IoCallDriver(pdx->LowerDeviceObject, Irp);

// then pass down this Minor Function for the next driver stack:
IoSkipCurrentIrpStackLocation(Irp);

// added 12-30-05
PCM_PARTIAL_RESOURCE_LIST raw;
PCM_PARTIAL_RESOURCE_LIST translated;

switch(MinorFunction)
{
case IRP_MN_START_DEVICE:
// we should check the allocated resource...
KdPrint((DRIVERNAME " - IRP_MN_START_DEVICE"));
if (NULL == IrpStack->Parameters.StartDevice.AllocatedResources) ||
(NULL ==
IrpStack->Parameters.StartDevice.AllocatedResources.Translated)){
status = STATUS_INSUFFICIENT_RESOURCES;
break;
}
raw =
&IrpStack->Parameters.StartDevice.AllocatedResources->List[0].PartialResourceList;
translated =
&IrpStack->Parameters.StartDevice.AllocatedResourcesTranslated->List[0].PartialResourceList;
StartDevice(fdo, raw, translated);
// ~added 12-30-05
case IRP_MN_REMOVE_DEVICE:
KdPrint((DRIVERNAME " - IRP_MN_REMOVE_DEVICE"));
if(pdx->LowerDeviceObject)
IoDetachDevice(pdx->LowerDeviceObject);
IoDeleteDevice(fdo); // delete fdo
break;
}
// call the device below us
IoSkipCurrentIrpStackLocation(Irp);
return IoCallDriver(pdx->LowerDeviceObject, Irp);
}

Doron
Thu Dec 29 23:15:47 CST 2005

you need to synchronously send the start irp down the stack, you have

> NTSTATUS status = IoCallDriver(pdx->LowerDeviceObject, Irp);
>
> // then pass down this Minor Function for the next driver stack:
> IoSkipCurrentIrpStackLocation(Irp);

you are touching an irp after it left your driver in the call to
IoSkipCurrentStackLocation after calling IoCallDriver. instead, send the
irp and synchronously wait for it to come back. there are many examples in
the DDK which show this.

d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"krby_xtrm" <kerby.martino@gmail.com> wrote in message
news:1135909598.720708.189900@g49g2000cwa.googlegroups.com...
> // This is my complete Pnp Dispatch routine:
> NTSTATUS PciWDMPnp (IN PDEVICE_OBJECT fdo, IN PIRP Irp)
> {
> DbgPrint(DRIVERNAME " - Begin WDM Pnp");
>
> PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION)fdo->DeviceExtension;
> PIO_STACK_LOCATION IrpStack = IoGetCurrentIrpStackLocation(Irp); //
> obtain current IRP
>
> ULONG MinorFunction = IrpStack->MinorFunction;
>
> // sends an IRP to the driver associated with a specified device
> object.
> // pdx->LowerDeviceObject, representing the target device for the
> requested I/O operation.
> NTSTATUS status = IoCallDriver(pdx->LowerDeviceObject, Irp);
>
> // then pass down this Minor Function for the next driver stack:
> IoSkipCurrentIrpStackLocation(Irp);
>
> // added 12-30-05
> PCM_PARTIAL_RESOURCE_LIST raw;
> PCM_PARTIAL_RESOURCE_LIST translated;
>
> switch(MinorFunction)
> {
> case IRP_MN_START_DEVICE:
> // we should check the allocated resource...
> KdPrint((DRIVERNAME " - IRP_MN_START_DEVICE"));
> if (NULL == IrpStack->Parameters.StartDevice.AllocatedResources) ||
> (NULL ==
> IrpStack->Parameters.StartDevice.AllocatedResources.Translated)){
> status = STATUS_INSUFFICIENT_RESOURCES;
> break;
> }
> raw =
> &IrpStack->Parameters.StartDevice.AllocatedResources->List[0].PartialResourceList;
> translated =
> &IrpStack->Parameters.StartDevice.AllocatedResourcesTranslated->List[0].PartialResourceList;
> StartDevice(fdo, raw, translated);
> // ~added 12-30-05
> case IRP_MN_REMOVE_DEVICE:
> KdPrint((DRIVERNAME " - IRP_MN_REMOVE_DEVICE"));
> if(pdx->LowerDeviceObject)
> IoDetachDevice(pdx->LowerDeviceObject);
> IoDeleteDevice(fdo); // delete fdo
> break;
> }
> // call the device below us
> IoSkipCurrentIrpStackLocation(Irp);
> return IoCallDriver(pdx->LowerDeviceObject, Irp);
> }
>

kerby
Fri Dec 30 07:01:36 CST 2005

Doron Holan [MS] wrote:
> you need to synchronously send the start irp down the stack, you have
>
>
>>NTSTATUS status = IoCallDriver(pdx->LowerDeviceObject, Irp);
>>
>>// then pass down this Minor Function for the next driver stack:
>>IoSkipCurrentIrpStackLocation(Irp);
>
>
> you are touching an irp after it left your driver in the call to
> IoSkipCurrentStackLocation after calling IoCallDriver. instead, send the
> irp and synchronously wait for it to come back. there are many examples in
> the DDK which show this.
>
> d

one question, is there somehing in my code before that should be removed?

anyway, is what you're saying
something like this:
NTSTATUS PassDownPnP( IN PDEVICE_OBJECT pDO,
IN PIRP pIrp ) {
IoSkipCurrentIrpStackLocation( pIrp );
PDEVICE_EXTENSION pDevExt = (PDEVICE_EXTENSION)
pDO->DeviceExtension;
return IoCallDriver(pDevExt->pLowerDevice, pIrp);
}

?
-krby_xtrm-

Doron
Fri Dec 30 10:14:30 CST 2005

i suggest you do alot more reading of the samples, documenation, and
hopefully a book or two. you are missing some fundamental concepts here.

KEVENT startDeviceEvent;
NTSTATUS ntStatus;

//
// We cannot touch the device (send it any non pnp irps) until a
// start device has been passed down to the lower drivers.
// first pass the Irp down
//
KeInitializeEvent(&startDeviceEvent, NotificationEvent, FALSE);
IoCopyCurrentIrpStackLocationToNext(Irp);
IoSetCompletionRoutine(Irp,
(PIO_COMPLETION_ROUTINE)IrpCompletionRoutine,
(PVOID)&startDeviceEvent,
TRUE,
TRUE,
TRUE);

ntStatus = IoCallDriver(deviceExtension->TopOfStackDeviceObject, Irp);

if(ntStatus == STATUS_PENDING) {

KeWaitForSingleObject(&startDeviceEvent,
Executive,
KernelMode,
FALSE,
NULL);

ntStatus = Irp->IoStatus.Status;
}

NTSTATUS
IrpCompletionRoutine(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp,
IN PVOID Context
)
{
PKEVENT event = Context;

KeSetEvent(event, 0, FALSE);

return STATUS_MORE_PROCESSING_REQUIRED;
}


--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"kerby" <kerby@driftmark.com> wrote in message
news:uHKbtEUDGHA.3984@TK2MSFTNGP14.phx.gbl...
> Doron Holan [MS] wrote:
>> you need to synchronously send the start irp down the stack, you have
>>
>>
>>>NTSTATUS status = IoCallDriver(pdx->LowerDeviceObject, Irp);
>>>
>>>// then pass down this Minor Function for the next driver stack:
>>>IoSkipCurrentIrpStackLocation(Irp);
>>
>>
>> you are touching an irp after it left your driver in the call to
>> IoSkipCurrentStackLocation after calling IoCallDriver. instead, send the
>> irp and synchronously wait for it to come back. there are many examples
>> in the DDK which show this.
>>
>> d
>
> one question, is there somehing in my code before that should be removed?
>
> anyway, is what you're saying
> something like this:
> NTSTATUS PassDownPnP( IN PDEVICE_OBJECT pDO,
> IN PIRP pIrp ) {
> IoSkipCurrentIrpStackLocation( pIrp );
> PDEVICE_EXTENSION pDevExt = (PDEVICE_EXTENSION)
> pDO->DeviceExtension;
> return IoCallDriver(pDevExt->pLowerDevice, pIrp);
> }
>
> ?
> -krby_xtrm-

Calvin
Mon Jan 02 17:11:13 CST 2006

"synchronously wait for it to come back" means:

1) setup a completion routine for the IRP (which will consume one stack
location, so you can't use IoSkipCurrentIrpStackLocation, use IoCopyXxx
instead), then you forward the request down by IoCallDriver.

2) Your main PNP path will wait on an event allocated from the kernel stack
if the lower driver has not done with the IRP, for instance, it returned
STATUS_PENDING.

3) The lower drivers has done with the IRP eventually, such as the bus
driver has brought the device into a proper state for your device to start.
The lower driver then completes the IRP and the I/O stack unwinding starts.

4) The I/O manage walks the i/o stack all the way back and calls completion
routine installed at each stack location. Your completion routine gets call
then. It will set the event which the main PNP path is waiting on, and
return STATUS_MORE_PROCESSING_REQUIRED so that the stack unwinding (part of
IRP completion process) will stop immediately. This prevents IRP and its
associated resources from being deallocated because the rest of the PNP code
path needs it.

5)Your main PNP path (IRP_MN_START_DEVICE) regains control and go ahead with
whatever needs to be done to init your device.

6) After you are done with the START_DEVICE Irp, do NOT forget to complete
it by calling IoCompleteRequest since the completion process has been paused
by returning SMPR from your completion routine.



If you want to learn how a PNP driver works by writing code from scratch,
you should go over the DDK doc and/or get a good windows driver book such as
Oney's at www.oneysoft.com

If you just want to get your driver going quickly without messing with the
nasty PNP/Po code, you can take the toaster sample from DDK.

HTH, Calvin

--
Calvin Guan (Windows DDK MVP)
NetXtreme Longhorn Miniport Prime
Broadcom Corp. www.broadcom.com

"kerby" <kerby@driftmark.com> wrote in message
news:uHKbtEUDGHA.3984@TK2MSFTNGP14.phx.gbl...
> Doron Holan [MS] wrote:
>> you need to synchronously send the start irp down the stack, you have
>>
>>
>>>NTSTATUS status = IoCallDriver(pdx->LowerDeviceObject, Irp);
>>>
>>>// then pass down this Minor Function for the next driver stack:
>>>IoSkipCurrentIrpStackLocation(Irp);
>>
>>
>> you are touching an irp after it left your driver in the call to
>> IoSkipCurrentStackLocation after calling IoCallDriver. instead, send the
>> irp and synchronously wait for it to come back. there are many examples
>> in the DDK which show this.
>>
>> d
>
> one question, is there somehing in my code before that should be removed?
>
> anyway, is what you're saying
> something like this:
> NTSTATUS PassDownPnP( IN PDEVICE_OBJECT pDO,
> IN PIRP pIrp ) {
> IoSkipCurrentIrpStackLocation( pIrp );
> PDEVICE_EXTENSION pDevExt = (PDEVICE_EXTENSION)
> pDO->DeviceExtension;
> return IoCallDriver(pDevExt->pLowerDevice, pIrp);
> }
>
> ?
> -krby_xtrm-

Calvin
Mon Jan 02 17:14:34 CST 2006

> NTSTATUS
> IrpCompletionRoutine(
> IN PDEVICE_OBJECT DeviceObject,
> IN PIRP Irp,
> IN PVOID Context
> )
> {
> PKEVENT event = Context;
>
> KeSetEvent(event, 0, FALSE);
>
> return STATUS_MORE_PROCESSING_REQUIRED;
> }

Personally, I prefer

if (Irp->PendingReturned) {
KeSetEvent();
}

Not a big deal though.

--
Calvin Guan (Windows DDK MVP)
NetXtreme Longhorn Miniport Prime
Broadcom Corp. www.broadcom.com

Gary
Tue Jan 03 09:13:18 CST 2006

If you REALLY want PNP and Po easy, and need not worry about W2K, or can
delay support for W2K for a while, use KMDF10.

The personal opinion of
Gary G. Little

"Calvin Guan" <hguan@nospam.broadcom.com> wrote in message
news:%23MO0NK$DGHA.2320@TK2MSFTNGP11.phx.gbl...
> "synchronously wait for it to come back" means:
>
> 1) setup a completion routine for the IRP (which will consume one stack
> location, so you can't use IoSkipCurrentIrpStackLocation, use IoCopyXxx
> instead), then you forward the request down by IoCallDriver.
>
> 2) Your main PNP path will wait on an event allocated from the kernel
> stack if the lower driver has not done with the IRP, for instance, it
> returned STATUS_PENDING.
>
> 3) The lower drivers has done with the IRP eventually, such as the bus
> driver has brought the device into a proper state for your device to
> start. The lower driver then completes the IRP and the I/O stack unwinding
> starts.
>
> 4) The I/O manage walks the i/o stack all the way back and calls
> completion routine installed at each stack location. Your completion
> routine gets call then. It will set the event which the main PNP path is
> waiting on, and return STATUS_MORE_PROCESSING_REQUIRED so that the stack
> unwinding (part of IRP completion process) will stop immediately. This
> prevents IRP and its associated resources from being deallocated because
> the rest of the PNP code path needs it.
>
> 5)Your main PNP path (IRP_MN_START_DEVICE) regains control and go ahead
> with whatever needs to be done to init your device.
>
> 6) After you are done with the START_DEVICE Irp, do NOT forget to complete
> it by calling IoCompleteRequest since the completion process has been
> paused by returning SMPR from your completion routine.
>
>
>
> If you want to learn how a PNP driver works by writing code from scratch,
> you should go over the DDK doc and/or get a good windows driver book such
> as Oney's at www.oneysoft.com
>
> If you just want to get your driver going quickly without messing with the
> nasty PNP/Po code, you can take the toaster sample from DDK.
>
> HTH, Calvin
>
> --
> Calvin Guan (Windows DDK MVP)
> NetXtreme Longhorn Miniport Prime
> Broadcom Corp. www.broadcom.com
>
> "kerby" <kerby@driftmark.com> wrote in message
> news:uHKbtEUDGHA.3984@TK2MSFTNGP14.phx.gbl...
>> Doron Holan [MS] wrote:
>>> you need to synchronously send the start irp down the stack, you have
>>>
>>>
>>>>NTSTATUS status = IoCallDriver(pdx->LowerDeviceObject, Irp);
>>>>
>>>>// then pass down this Minor Function for the next driver stack:
>>>>IoSkipCurrentIrpStackLocation(Irp);
>>>
>>>
>>> you are touching an irp after it left your driver in the call to
>>> IoSkipCurrentStackLocation after calling IoCallDriver. instead, send
>>> the irp and synchronously wait for it to come back. there are many
>>> examples in the DDK which show this.
>>>
>>> d
>>
>> one question, is there somehing in my code before that should be removed?
>>
>> anyway, is what you're saying
>> something like this:
>> NTSTATUS PassDownPnP( IN PDEVICE_OBJECT pDO,
>> IN PIRP pIrp ) {
>> IoSkipCurrentIrpStackLocation( pIrp );
>> PDEVICE_EXTENSION pDevExt = (PDEVICE_EXTENSION)
>> pDO->DeviceExtension;
>> return IoCallDriver(pDevExt->pLowerDevice, pIrp);
>> }
>>
>> ?
>> -krby_xtrm-
>
>