Verifier Causes Breakpoint in WDFInterruptEnable

NTDEV
21

OK, this is one of those quirks about the KMDF log that I wish the dev team would fix (Doron?) – The name of the function – WdfDmaEnablerCreate – isn’t correct, but the MESSAGE is. The relevant function name can typically be determined from the previous log entry.

See this article:

http://www.osronline.com/article.cfm?article=496

In any case, this is the error I suspected. You’re calling WdfInterruptEnable at IRQL DISPATCH_LEVEL and it can only be called at IRQL PASSIVE_LEVEL. See previous discussion.

Peter
OSR

22

imp_WdfDmaEnablerCreate is actually the name of the function that implements the API. It can’t be WdfDmaEnablerCreate because WdfDmaEnablerCreate is defined in the header as a call through a pointer and it would be a redefinition. All kmdf APIs implementatios are named imp_Xxxx. The reason you see this is because we app to automatically get the name into the log and we can’t munge it back

d

From: xxxxx@osr.commailto:xxxxx
Sent: ?1/?30/?2013 6:15 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Verifier Causes Breakpoint in WDFInterruptEnable



OK, this is one of those quirks about the KMDF log that I wish the dev team would fix (Doron?) – The name of the function – WdfDmaEnablerCreate – isn’t correct, but the MESSAGE is. The relevant function name can typically be determined from the previous log entry.

See this article:

http://www.osronline.com/article.cfm?article=496

In any case, this is the error I suspected. You’re calling WdfInterruptEnable at IRQL DISPATCH_LEVEL and it can only be called at IRQL PASSIVE_LEVEL. See previous discussion.

Peter
OSR

—
NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

23

I think you miss my point.

He’s getting this message as a result of calling WdfInterruptEnable… nothing whatsoever to do with DMA Enablers. He probably doesn’t have a DMA Enable in his driver.

The message has the wrong function name in the text. It’s always been this way, because of how the messages are generated. I’m simply saying “please remove the name of the function from the message” as it’s not needed… preceding KMDF Verifier messages make the context sufficiently clear.

Peter
OSR

24

xxxxx@osr.com wrote:

He’s getting this message as a result of calling WdfInterruptEnable… nothing whatsoever to do with DMA Enablers. He probably doesn’t have a DMA Enable in his driver.

The message has the wrong function name in the text. It’s always been this way, because of how the messages are generated. I’m simply saying “please remove the name of the function from the message” as it’s not needed… preceding KMDF Verifier messages make the context sufficiently clear.

If I had to guess (which I don’t, but I will anyway), I’d guess this was
probably being caused by aggressive code shuffling and code combining by
the linker and the loader. By the time those two are done, none of the
code is really sure who its daddy is.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

25

xxxxx@verizon.net wrote:

If interrupts occurred before the user request, there would be nothing intelligent do with them.

Then why would there be any? If you get an interrupt when you aren’t
expecting one, that’s an error condition, and you probably need to do
something about it, don’t you. Otherwise, you’re going to have an
unhandled interrupt pending at the time you enable your interrupts.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

26

Ah, the irql check function is shared across all api implementations which have irql restrictions. We might be able to control the name in the actual message, but if you setup the log dump format string to show function name, it will still show up with the wrong name in the log

d

From: xxxxx@osr.commailto:xxxxx
Sent: ?1/?30/?2013 9:55 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Verifier Causes Breakpoint in WDFInterruptEnable



I think you miss my point.

He’s getting this message as a result of calling WdfInterruptEnable… nothing whatsoever to do with DMA Enablers. He probably doesn’t have a DMA Enable in his driver.

The message has the wrong function name in the text. It’s always been this way, because of how the messages are generated. I’m simply saying “please remove the name of the function from the message” as it’s not needed… preceding KMDF Verifier messages make the context sufficiently clear.

Peter
OSR

—
NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

27

There may be nothing intelligent to do with it, but you must avoid doing
something stupid with it, such as trying to write the data to a
non-existent buffer or use the non-existent IRP. A huge number of drivers
fail in the field because their ISR tries to access an invalid address.
And for some devices, this is legitimate behavior, and you should either
ignore it or implement internal buffering so the data is not lost. In one
case, my copy routine was called at ISR level to copy one byte of data.
If (and this was in another OS, decades ago) there was no pending IRP, I
recorded the status register and the data byte in an internal buffer, and
when the IRP (or its equivalent) arrived, I passed the data byte and
status code to the copy routine, so that if there had been a data overrun
the app would see this. For that particular device, this was necessary.
So your choices are (a) ignore the interrupt, and silently lose data (b)
use internal buffering (c) include the status register in the internal
buffering (d) crash on an access fault. And these are just the
superficial choices; your device may require you handle far more subtle
cases. What you have to do is make sure (d) is never possible. Oh, yes,
and you must avoid (e) do nothing and the device hangs, failing to send
interrupts until it is in a “clean” state.
joe

xxxxx@verizon.net wrote:
> If interrupts occurred before the user request, there would be nothing
> intelligent do with them.

Then why would there be any? If you get an interrupt when you aren’t
expecting one, that’s an error condition, and you probably need to do
something about it, don’t you. Otherwise, you’re going to have an
unhandled interrupt pending at the time you enable your interrupts.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer