Re: Vista 5840 and Int 2C by soviet_bloke
soviet_bloke
Wed Nov 15 09:11:35 CST 2006
> 2. An interrupt handler is what is called through the NDIS miniport's
So now it turns out that we are speaking about NDIS miniport......
This is what you should have started with. Anyway, it sounds already
encouraging.
Have you got any idea at which exact point an assertion fails? Once it
is not your code who fails an assertion, it must be happening
throughout a call to some NDIS function. Have you got any idea which
particular function does it?
Anton Bassov
John Q. Public wrote:
> 1. An ISR is what is called at KIRQL.
> 2. An interrupt handler is what is called through the NDIS miniport's
> MiniportInterruptDPC (for NDIS 6.0) or MiniportHandleInterrupt function at
> DIRQL. See how interrupt handler == MiniportHandleInterrupt?
>
> What I have been describing is an assert (triggered by the OS) which happens
> within the driver's MiniportInterruptDPC.
>
> <soviet_bloke@hotmail.com> wrote in message
> news:1163578515.431545.38930@b28g2000cwb.googlegroups.com...
> >> 1. This is not happening in the ISR, but in the interrupt handler which
> >> runs
> >> at IRQL == DISPATCH.
> >
> > What is "interrupt handler", in your understanding?????????
> >
> > In a true meaning of this term, interrupt handler is system-provided
> > routine with the address stored in IDT. Its task is to save registers,
> > raise IRQL to DIRQL , corresponding to your device (it runs at
> > DISPATCH_LEVEL before doing so), and transfer control to ISR. As a
> > driver writer, you are not supposed to even know about it, let alone
> > to get involved in the process. Therefore, I don't think that
> > "interrupt handler" in this context refers to the above the mentioned
> > routine, does it????
> >
> > In most cases, when you hear "interrupt handler" from driver writer,
> > you can be pretty sure he means ISR, but you made it clear that your
> > "interrupt handler" runs at DISPATCH_LEVEL, so it is not ISR.
> >
> > The only thing left is DPC routine - it is scheduled by ISR, and,
> > indeed, runs at DISPATCH_LEVEL, and this is what you, apparently meant
> > by "interrupt handler"
> >
> > In other words, you should learn how to formulate your questions
> > properly.
> >
> >> 3. Why am I wasting my time on this news group?
> >
> > To be honest, for the time being it looks like "this news group" is
> > wasting its time on you, and not the other way round.......
> >
> > Anton Bassov
> >
> >
> > John Q. Public wrote:
> >> 1. This is not happening in the ISR, but in the interrupt handler which
> >> runs
> >> at IRQL == DISPATCH.
> >> 2. The WDK supports DbgRaiseAssertionFailure() which uses INT 2c, which
> >> can
> >> be used by KM drivers.
> >> 3. Why am I wasting my time on this news group?
> >>
> >> <soviet_bloke@hotmail.com> wrote in message
> >> news:1163565253.054096.316480@b28g2000cwb.googlegroups.com...
> >> >> The OS is triggering this assert while my driver is executing its
> >> >> interrupt
> >> >> handler.
> >> >
> >> > How is your driver's interrupt handler related to Int 0x2C??? Int 0x2C
> >> > is a software interrupt
> >> > (as its very value of 0x2c suggests - it is too low for hardware
> >> > interrupt), so that it has nothing to do with your ISR. In actuality,
> >> > it is one of few software interrupts that user-mode code is allowed to
> >> > raise.....
> >> >
> >> > Anton Bassov
> >> >
> >> > John Q. Public wrote:
> >> >> Hi!
> >> >>
> >> >> The OS is triggering this assert while my driver is executing its
> >> >> interrupt
> >> >> handler. I suspect that the OS is hitting the assert because we may be
> >> >> within DPC for too long. However, how can I find out the root cause
> >> >> for
> >> >> this
> >> >> assert?
> >> >>
> >> >> Thanks!
> >> >
> >