Jan
Thu May 08 10:12:02 CDT 2008
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@discussions.microsoft.com> wrote in message
> > news:D1672622-E99B-4AD9-AEB7-BE8CED5DA29A@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
> >
> >
> >