Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Handle NMI interrupt in Device driver

OSR_Community_UserOSR_Community_User Member Posts: 110,217
Hello,

My SBC's vendor (Adlink) suggested to create an "NMI" interrupt upon '1' in the chipset's GPIO.

Can you please explain what should I write in inf+sys in order to catch this interrupt ?

O.S: Windows 7 (64)

Can you please tell if this is wise step to use NMI ? Is this interrupt used for other criticial purposes like application debug ?

Thank you,
Zvika

Comments

  • anton_bassovanton_bassov Member Posts: 4,928
    > Can you please tell if this is wise step to use NMI ?

    Well, apparently, not.....


    NMI in itself is meant to be used either for indicating critical hardware failures that require immediate attention from the system (like, for example, parity error detected by the memory controller), or for breaking into the system by means of kernel debugger (i.e. signaling it via NMI pin) when no other option is available because of some irrecoverable system software bug. For example, if CPU executes HLT instruction (or just goes into an infinite loop) while interrupts are disabled, NMI is the only way one may get the system back.


    Although Linux uses NMI for watchdog timers and performance counters, in the Windows world NMI is, IIRC, firmly associated with irrecoverable system failures and always results in bugchecking. You can check the following article for more details


    https://support.microsoft.com/en-us/help/2750146/nmi-hardware-failure-error-when-an-nmi-is-triggered-on-windows-8-and-w


    Therefore, using NMI option is obviously unwise in the Windows world unless bugchcking is your intended behavior (i.e. you want to use it for diagnostic purposes)



    Anton Bassov
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,305
    PVOID KeRegisterNmiCallback(
    _In_ PNMI_CALLBACK CallbackRoutine,
    _In_opt_ PVOID Context
    );


    Read the docs on how to use it.

    Mark Roddy

    On Sun, Nov 26, 2017 at 3:52 PM, xxxxx@hotmail.com <
    xxxxx@lists.osr.com> wrote:

    > > Can you please tell if this is wise step to use NMI ?
    >
    > Well, apparently, not.....
    >
    >
    > NMI in itself is meant to be used either for indicating critical hardware
    > failures that require immediate attention from the system (like, for
    > example, parity error detected by the memory controller), or for breaking
    > into the system by means of kernel debugger (i.e. signaling it via NMI
    > pin) when no other option is available because of some irrecoverable system
    > software bug. For example, if CPU executes HLT instruction (or just goes
    > into an infinite loop) while interrupts are disabled, NMI is the only way
    > one may get the system back.
    >
    >
    > Although Linux uses NMI for watchdog timers and performance counters, in
    > the Windows world NMI is, IIRC, firmly associated with irrecoverable
    > system failures and always results in bugchecking. You can check the
    > following article for more details
    >
    >
    > https://support.microsoft.com/en-us/help/2750146/nmi-
    > hardware-failure-error-when-an-nmi-is-triggered-on-windows-8-and-w
    >
    >
    > Therefore, using NMI option is obviously unwise in the Windows world
    > unless bugchcking is your intended behavior (i.e. you want to use it for
    > diagnostic purposes)
    >
    >
    >
    > Anton Bassov
    >
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Ken_JohnsonKen_Johnson Member - All Emails Posts: 1,559
    The documentation is perhaps not as cautionary as it should be on this topic. Essentially no system APIs can be safely called from an NMI callback (including but not limited to: acquiring locks, queueing a DPC, etc.), because an NMI can interrupt any code, even code that holds an interrupts-disabled or HIGH_LEVEL lock.

    Since an NMI can interrupt anything (and there is almost no code that can safely be called from an NMI callback), synchronizing with any code that is called to handle an NMI without risk of deadlock etc. is difficult and cumbersome, not to mention that NMI code typically cannot be debugged in typical fashion, as the debugger itself relies on NMIs to function (at least on AMD64).

    Unless something very special-purpose such as a debugging watchdog to catch, say, a hung system is being implemented, NMIs are best avoided.

    - S (Msft)

    ________________________________
    From: xxxxx@lists.osr.com on behalf of xxxxx@gmail.com
    Sent: Monday, November 27, 2017 3:41:26 AM
    To: Windows System Software Devs Interest List
    Subject: Re: [ntdev] Handle NMI interrupt in Device driver


    PVOID KeRegisterNmiCallback(
    _In_ PNMI_CALLBACK CallbackRoutine,
    _In_opt_ PVOID Context
    );


    Read the docs on how to use it.

    Mark Roddy

    On Sun, Nov 26, 2017 at 3:52 PM, xxxxx@hotmail.com > wrote:
    > Can you please tell if this is wise step to use NMI ?

    Well, apparently, not.....


    NMI in itself is meant to be used either for indicating critical hardware failures that require immediate attention from the system (like, for example, parity error detected by the memory controller), or for breaking into the system by means of kernel debugger (i.e. signaling it via NMI pin) when no other option is available because of some irrecoverable system software bug. For example, if CPU executes HLT instruction (or just goes into an infinite loop) while interrupts are disabled, NMI is the only way one may get the system back.


    Although Linux uses NMI for watchdog timers and performance counters, in the Windows world NMI is, IIRC, firmly associated with irrecoverable system failures and always results in bugchecking. You can check the following article for more details


    https://support.microsoft.com/en-us/help/2750146/nmi-hardware-failure-error-when-an-nmi-is-triggered-on-windows-8-and-w


    Therefore, using NMI option is obviously unwise in the Windows world unless bugchcking is your intended behavior (i.e. you want to use it for diagnostic purposes)



    Anton Bassov



    ---
    NTDEV is sponsored by OSR

    Visit the list online at: >

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at >

    To unsubscribe, visit the List Server section of OSR Online at >

    --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,305
    Well presumably he just is going to read/write a register on his device and
    dismiss the interrupt. Indeed if he is doing anything else it will be a
    disaster.

    Mark Roddy

    On Mon, Nov 27, 2017 at 5:02 PM, xxxxx@valhallalegends.com <
    xxxxx@lists.osr.com> wrote:

    > The documentation is perhaps not as cautionary as it should be on this
    > topic. Essentially no system APIs can be safely called from an NMI
    > callback (including but not limited to: acquiring locks, queueing a DPC,
    > etc.), because an NMI can interrupt any code, even code that holds an
    > interrupts-disabled or HIGH_LEVEL lock.
    >
    >
    >
    > Since an NMI can interrupt anything (and there is almost no code that can
    > safely be called from an NMI callback), synchronizing with any code that is
    > called to handle an NMI without risk of deadlock etc. is difficult and
    > cumbersome, not to mention that NMI code typically cannot be debugged in
    > typical fashion, as the debugger itself relies on NMIs to function (at
    > least on AMD64).
    >
    >
    >
    > Unless something very special-purpose such as a debugging watchdog to
    > catch, say, a hung system is being implemented, NMIs are best avoided.
    >
    >
    > - S (Msft)
    >
    >
    > ------------------------------
    > *From:* xxxxx@lists.osr.com osr.com> on behalf of xxxxx@gmail.com
    > *Sent:* Monday, November 27, 2017 3:41:26 AM
    > *To:* Windows System Software Devs Interest List
    > *Subject:* Re: [ntdev] Handle NMI interrupt in Device driver
    >
    >
    > PVOID KeRegisterNmiCallback(
    > _In_ PNMI_CALLBACK CallbackRoutine,
    > _In_opt_ PVOID Context
    > );
    >
    >
    > Read the docs on how to use it.
    >
    > Mark Roddy
    >
    > On Sun, Nov 26, 2017 at 3:52 PM, xxxxx@hotmail.com <
    > xxxxx@lists.osr.com> wrote:
    >
    >> > Can you please tell if this is wise step to use NMI ?
    >>
    >> Well, apparently, not.....
    >>
    >>
    >> NMI in itself is meant to be used either for indicating critical hardware
    >> failures that require immediate attention from the system (like, for
    >> example, parity error detected by the memory controller), or for breaking
    >> into the system by means of kernel debugger (i.e. signaling it via NMI
    >> pin) when no other option is available because of some irrecoverable system
    >> software bug. For example, if CPU executes HLT instruction (or just goes
    >> into an infinite loop) while interrupts are disabled, NMI is the only way
    >> one may get the system back.
    >>
    >>
    >> Although Linux uses NMI for watchdog timers and performance counters, in
    >> the Windows world NMI is, IIRC, firmly associated with irrecoverable
    >> system failures and always results in bugchecking. You can check the
    >> following article for more details
    >>
    >>
    >> https://support.microsoft.com/en-us/help/2750146/nmi-hardwar
    >> e-failure-error-when-an-nmi-is-triggered-on-windows-8-and-w
    >>
    >>
    >>
    >> Therefore, using NMI option is obviously unwise in the Windows world
    >> unless bugchcking is your intended behavior (i.e. you want to use it for
    >> diagnostic purposes)
    >>
    >>
    >>
    >> Anton Bassov
    >>
    >>
    >>
    >> ---
    >> NTDEV is sponsored by OSR
    >>
    >> Visit the list online at: > lists.cfm?list=ntdev
    >>
    >> >
    >>
    >> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    >> software drivers!
    >> Details at >
    >> >
    >>
    >> To unsubscribe, visit the List Server section of OSR Online at <
    >> http://www.osronline.com/page.cfm?name=ListServer
    >>
    >> >
    >>
    >
    > --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
    > on crash dump analysis, WDF, Windows internals and software drivers!
    > Details at To unsubscribe, visit the List Server section of OSR Online at
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • anton_bassovanton_bassov Member Posts: 4,928
    > Well presumably he just is going to read/write a register on his device and dismiss the interrupt.

    In such case, what is the point of relying upon NMI, rather than a "regular" IOAPIC/MSI interrupt
    that gets signaled by the device, in the first place??? As I said in my previous post, normally you would want to use it for working around the chipset bugs or debugging the kernel



    Anton Bassov
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,914
    xxxxx@hotmail.com wrote:
    >
    >> Well presumably he just is going to read/write a register on his device and dismiss the interrupt.
    > In such case, what is the point of relying upon NMI, rather than a "regular" IOAPIC/MSI interrupt
    > that gets signaled by the device, in the first place??? As I said in my previous post, normally you would want to use it for working around the chipset bugs or debugging the kernel

    Looping back around to the original request, he is working with an
    embedded system, and the vendor has a GPIO pin that can trigger an NMI. 
    It's an easy path to get external input for debugging.  The embedded
    world is just not a "pure" as the desktop world.

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

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Hi Anton, Tim, Mark, Ken,

    In my system, upon getting NMI from GPIO I should signal it to the application.
    Application will send IOCTL and wait NMI handler to answer it.
    According to your answers, I will ask SBC's vendor for an alternative.

    Thank you very much for the detailed information.

    Best regards,
    Zvika
  • Ken_JohnsonKen_Johnson Member - All Emails Posts: 1,559
    Yes - once you need to involve any sort of acknowledgement or processing of your interrupt that is more than just twiddling bits in hardware registers, you really will want something other than an NMI.

    There aren't any good mechanisms available to communicate things from an NMI handler to the "outside world" (e.g. user mode application with a pending IOCTL) on account of the relatively hostile environment that NMIs run in - and without the ability to signal synchronization objects, or to queue a DPC, or to complete an I/O request, etc. directly from an NMI handler, any component that wants to consume data from an NMI is going to be forced to rely on suboptimal and awkward mechanisms like polling (and even then, it would need to be very careful to handle a second NMI coming in simultaneously and adjusting data structures being examined by the polling logic).

    And if polling is sufficient, you might as well just dispense with the interrupt entirely. Otherwise, you would likely be much better off with a conventional hardware interrupt that can be masked, so that your ISR can queue a DPC to perform whatever software processing is needed to, say, inform your application that an interrupt has been handled.

    - S (Msft)

    -----Original Message-----
    From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
    Sent: Tuesday, November 28, 2017 8:46 PM
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    Subject: RE:[ntdev] Handle NMI interrupt in Device driver

    Hi Anton, Tim, Mark, Ken,

    In my system, upon getting NMI from GPIO I should signal it to the application.
    Application will send IOCTL and wait NMI handler to answer it.
    According to your answers, I will ask SBC's vendor for an alternative.

    Thank you very much for the detailed information.

    Best regards,
    Zvika


    ---
    NTDEV is sponsored by OSR

    Visit the list online at: <https://na01.safelinks.protection.outlook.com/?url=http://www.osronline.com/showlists.cfm?list=ntdev&amp;data=01|01||c2e20894d7be4a19e66208d536e435db|f62b632944a24271bcc1ea45807ab854|1&amp;sdata=AWcydLDo4i3o7XCD+35/ycSpR0BkGPixDajL+8ecNso=&amp;reserved=0&gt;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at <https://na01.safelinks.protection.outlook.com/?url=http://www.osr.com/seminars&amp;data=01|01||c2e20894d7be4a19e66208d536e435db|f62b632944a24271bcc1ea45807ab854|1&amp;sdata=mPwJtd4jKW/JG6598OvASzws667XQ3agavZhPzMZo18=&amp;reserved=0&gt;

    To unsubscribe, visit the List Server section of OSR Online at <https://na01.safelinks.protection.outlook.com/?url=http://www.osronline.com/page.cfm?name=ListServer&amp;data=01|01||c2e20894d7be4a19e66208d536e435db|f62b632944a24271bcc1ea45807ab854|1&amp;sdata=jfIa0Jfd/knWumUty8lZGL+zOjhtlF12UzrHfAdrsuo=&amp;reserved=0&gt;
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space