Prev: Poblem to install x64 driver from 32-bit code
Next: Filter driver installation
From: Jan on 7 May 2008 17:58
Hi,

What sort of things would cause a miniport's Halt function ( MiniportHalt()
) to NOT get caused? I have a deserialized miniport leveraged from the DDK
example netvmini. I have even gutted OUT MPHalt() just to set a breakpoint
to verify the function is getting called (along with debug statements), and
it is not happening. The uninstall/disable window in the Device Manager
(which I am using to issue the MPHalt) hangs indefinitely. I can move the
window around, but it stays in a "not responding" state.

Any ideas? Should I be looking for a spin lock (doubtful due to responsive
behavior of window), or is there an acknowledge which must be passed up first
to NDIS, etc? I'm sort of fishing for ideas to look into.

Thanks,

Jan
From: Pavel A. on 7 May 2008 21:10
"Jan" <Jan(a)discussions.microsoft.com> wrote in message
news:D1672622-E99B-4AD9-AEB7-BE8CED5DA29A(a)microsoft.com...
> Hi,
>
> What sort of things would cause a miniport's Halt function (
> MiniportHalt()
> ) to NOT get caused? I have a deserialized miniport leveraged from the
> DDK
> example netvmini. I have even gutted OUT MPHalt() just to set a
> breakpoint
> to verify the function is getting called (along with debug statements),
> and
> it is not happening. The uninstall/disable window in the Device Manager
> (which I am using to issue the MPHalt) hangs indefinitely. I can move the
> window around, but it stays in a "not responding" state.
>
> Any ideas? Should I be looking for a spin lock (doubtful due to
> responsive
> behavior of window), or is there an acknowledge which must be passed up
> first
> to NDIS, etc? I'm sort of fishing for ideas to look into.
>

This has been discussed here many times.
You may have uncompleted sends or OID requests,
or packets indicated up and not returned to their source pool.
People that answered this question before gave some useful windbg
commands (!ndiskd.findpacket, !ndiskd.miniport, !stacks 1 ndis ...)

Regards,
--PA


From: Jan on 8 May 2008 09:29
thank you, I will search on some of the key words you mentioned. I guess I
didn't use the right ones in my previous search.

Cheers,

Jan

"Pavel A." wrote:

> "Jan" <Jan(a)discussions.microsoft.com> wrote in message
> news:D1672622-E99B-4AD9-AEB7-BE8CED5DA29A(a)microsoft.com...
> > Hi,
> >
> > What sort of things would cause a miniport's Halt function (
> > MiniportHalt()
> > ) to NOT get caused? I have a deserialized miniport leveraged from the
> > DDK
> > example netvmini. I have even gutted OUT MPHalt() just to set a
> > breakpoint
> > to verify the function is getting called (along with debug statements),
> > and
> > it is not happening. The uninstall/disable window in the Device Manager
> > (which I am using to issue the MPHalt) hangs indefinitely. I can move the
> > window around, but it stays in a "not responding" state.
> >
> > Any ideas? Should I be looking for a spin lock (doubtful due to
> > responsive
> > behavior of window), or is there an acknowledge which must be passed up
> > first
> > to NDIS, etc? I'm sort of fishing for ideas to look into.
> >
>
> This has been discussed here many times.
> You may have uncompleted sends or OID requests,
> or packets indicated up and not returned to their source pool.
> People that answered this question before gave some useful windbg
> commands (!ndiskd.findpacket, !ndiskd.miniport, !stacks 1 ndis ...)
>
> Regards,
> --PA
>
>
>
From: Jan on 8 May 2008 11:12
Just as a follow up, here is a link to a document that seconds what Pavel
indicates, and has some helpful hints:

http://download.microsoft.com/download/5/7/7/577a5684-8a83-43ae-9272-ff260a9c20e2/ndisWinHec2003.doc#_Toc37747321

Cheers,

Jan

"Jan" wrote:

> thank you, I will search on some of the key words you mentioned. I guess I
> didn't use the right ones in my previous search.
>
> Cheers,
>
> Jan
>
> "Pavel A." wrote:
>
> > "Jan" <Jan(a)discussions.microsoft.com> wrote in message
> > news:D1672622-E99B-4AD9-AEB7-BE8CED5DA29A(a)microsoft.com...
> > > Hi,
> > >
> > > What sort of things would cause a miniport's Halt function (
> > > MiniportHalt()
> > > ) to NOT get caused? I have a deserialized miniport leveraged from the
> > > DDK
> > > example netvmini. I have even gutted OUT MPHalt() just to set a
> > > breakpoint
> > > to verify the function is getting called (along with debug statements),
> > > and
> > > it is not happening. The uninstall/disable window in the Device Manager
> > > (which I am using to issue the MPHalt) hangs indefinitely. I can move the
> > > window around, but it stays in a "not responding" state.
> > >
> > > Any ideas? Should I be looking for a spin lock (doubtful due to
> > > responsive
> > > behavior of window), or is there an acknowledge which must be passed up
> > > first
> > > to NDIS, etc? I'm sort of fishing for ideas to look into.
> > >
> >
> > This has been discussed here many times.
> > You may have uncompleted sends or OID requests,
> > or packets indicated up and not returned to their source pool.
> > People that answered this question before gave some useful windbg
> > commands (!ndiskd.findpacket, !ndiskd.miniport, !stacks 1 ndis ...)
> >
> > Regards,
> > --PA
> >
> >
> >
 | 
Pages: 1
Prev: Poblem to install x64 driver from 32-bit code
Next: Filter driver installation