Handling PNP IRP_MN_BOGUS

NTDEV
1

Hi all,

I’m testing a plug and play driver using Driver Verifier on Win2K with
the checked build of HAL and kernel.

On device plug in I am sent a plug and play IRP with the minor code of
0xFF. As we don’t handle this IRP, I do the following:

IoSkipCurrentIrpStackLocation( pIrp );
return IoCallDriver( pDevExt->mGlobalReadOnly.mpLowerDeviceObject , pIrp
);

The following assertion then occurs:

*** BugBug : Driver “mydriver” returned status = 0 and Information = 0
for IRP_MN_BOGUS.
*** Assertion failed: 0
*** Source File: D:\nt\private\ntos\io\pnpenum.c, line 1256

Break, Ignore, Terminate Process or Terminate Thread (bipt)?

Does anybody have any idea what I might be doing wrong?

Thanks in advance,
Matt.

2

“Mathew Perry” <mathew.perry> wrote in message news:xxxxx@ntdev…
>
> On device plug in I am sent a plug and play IRP with the minor code of
> 0xFF. As we don’t handle this IRP, I do the following:
>
> IoSkipCurrentIrpStackLocation( pIrp );
> return IoCallDriver( pDevExt->mGlobalReadOnly.mpLowerDeviceObject , pIrp
> );
>
> The following assertion then occurs:
>
> BugBug : Driver “mydriver” returned status = 0 and Information = 0
> for IRP_MN_BOGUS.
> Assertion failed: 0
> *** Source File: D:\nt\private\ntos\io\pnpenum.c, line 1256
>
> Break, Ignore, Terminate Process or Terminate Thread (bipt)?
>
>
> Does anybody have any idea what I might be doing wrong?
>

First of all, kudos for using the checked versions of the kernel and hal.

Second, you’re doing the right thing in the code above. But I’m puzzled as
to how the status field got to be zero. In my experience, this IRP comes in
with the status set to an error code (STATUS_NOT_SUPPORTED?) just like all
the other PnP IRPs.

You sure you’re not “accidentally” zeroing the status field before
forwarding the IRP? That’d be the error. If you don’t handle it, you don’t
fool with the status…

Peter
OSR</mathew.perry>

3

Somebody should have failed this request, and unless your driver is the bus
driver for the PDOs, it wasn’t you. If you want to fix this up (i.e.
accommodate the bogus bus driver below you,) then you could send the irp
down synchronously and fail it after the bus driver finished with it.

FDOs pass it down, PDOs fail it.

-----Original Message-----
From: Mathew Perry [mailto:mathew.perry@st.com]
Sent: Friday, June 28, 2002 1:10 PM
To: NT Developers Interest List
Subject: [ntdev] Handling PNP IRP_MN_BOGUS

Hi all,

I’m testing a plug and play driver using Driver Verifier on
Win2K with the checked build of HAL and kernel.

On device plug in I am sent a plug and play IRP with the
minor code of 0xFF. As we don’t handle this IRP, I do the following:

IoSkipCurrentIrpStackLocation( pIrp );
return IoCallDriver(
pDevExt->mGlobalReadOnly.mpLowerDeviceObject , pIrp );

The following assertion then occurs:

*** BugBug : Driver “mydriver” returned status = 0 and Information = 0
for IRP_MN_BOGUS.
*** Assertion failed: 0
*** Source File: D:\nt\private\ntos\io\pnpenum.c, line 1256

Break, Ignore, Terminate Process or Terminate Thread (bipt)?

Does anybody have any idea what I might be doing wrong?

Thanks in advance,
Matt.

You are currently subscribed to ntdev as:
xxxxx@stratus.com To unsubscribe send a blank email to
%%email.unsub%%

4

Peter,

Thanks for the reply, I’ve commented below.

xxxxx@osr.com wrote:

“Mathew Perry” <mathew.perry> wrote in message news:xxxxx@ntdev…
> >
> > On device plug in I am sent a plug and play IRP with the minor code of
> > 0xFF. As we don’t handle this IRP, I do the following:
> >
> > IoSkipCurrentIrpStackLocation( pIrp );
> > return IoCallDriver( pDevExt->mGlobalReadOnly.mpLowerDeviceObject , pIrp
> > );
> >
> > The following assertion then occurs:
> >
> > BugBug : Driver “mydriver” returned status = 0 and Information = 0
> > for IRP_MN_BOGUS.
> > Assertion failed: 0
> > *** Source File: D:\nt\private\ntos\io\pnpenum.c, line 1256
> >
> > Break, Ignore, Terminate Process or Terminate Thread (bipt)?
> >
> >
> > Does anybody have any idea what I might be doing wrong?
> >
>
> First of all, kudos for using the checked versions of the kernel and hal.
>
> Second, you’re doing the right thing in the code above. But I’m puzzled as
> to how the status field got to be zero. In my experience, this IRP comes in
> with the status set to an error code (STATUS_NOT_SUPPORTED?) just like all
> the other PnP IRPs.

You’re right here. Curiously enough the status field is set to
STATUS_NOT_SUPPORTED (0xC00000BB) when I get the IRP and remains at this
value after the call to IoCallDriver(). The same value is returned by
IoCallDriver() and so becomes the return of my PNP Handler. The
information field of the IRP is zero but I guess that should be OK. I’m
not sure why this assertion is occuring in this circumstance. There are
a number of other PNP IRPs which I am handling in exactly the same way
and the assertion doesn’t occur!

>
> You sure you’re not “accidentally” zeroing the status field before
> forwarding the IRP? That’d be the error. If you don’t handle it, you don’t
> fool with the status…
>
> Peter
> OSR
>
> —
> You are currently subscribed to ntdev as: mathew.perry@st.com
> To unsubscribe send a blank email to %%email.unsub%%</mathew.perry>