BugCheck in NDIS-WDM miniport driver

Scenario:-

During installation the customized miniport-wdm driver comes up, and
goes through the initilaization process without a hitch.
I am able to allocate memory for certain operations related to the
driver. I am also able to get the lower WDM device object at the end of
initialization . Then i start getting the OIDs to which i respond with
the required info (like OID_GET_LINK_STATUS, OID_GET_HARDWARE_ADDRESS
and so on).

At this point of time suddenly, there is a kernel bugcheck, the details
of which are mentioned below.
(This error was captured through softIce).

Break due to KeBugCheckEx( Unhandled Kernel Mode Excpetion)
Error = 7E (WINDOWS_NT_BANNER)
P1 = C0000047 P2= 8050E2BB …(the rest of the Bug Check parameters)

I tried to trace the stack to no avail. there was not a single function
that was getting executed from my driver.
Can anyone of you please throw some more light on this issue. I
searched through the Web but apart from the fact that it was a double
fault which occured there was nothing more i could find. I must state here
that i am pretty much to new to this kind of error handling.

On Tue, 2003-12-09 at 22:44, Sandeep wrote:

I am able to allocate memory for certain operations related to the
driver. I am also able to get the lower WDM device object at the end of
initialization . Then i start getting the OIDs to which i respond with
the required info (like OID_GET_LINK_STATUS, OID_GET_HARDWARE_ADDRESS
and so on).

At this point of time suddenly, there is a kernel bugcheck, the details
of which are mentioned below.
(This error was captured through softIce).

Break due to KeBugCheckEx( Unhandled Kernel Mode Excpetion)
Error = 7E (WINDOWS_NT_BANNER)
P1 = C0000047 P2= 8050E2BB …(the rest of the Bug Check parameters)

I tried to trace the stack to no avail. there was not a single function
that was getting executed from my driver.

What happens if you return unsupported for those oids?

NTDEV is probably a better list for this question, btw.

-sd