Notes about NMI_HARDWARE_FAILURE

CARE: Crash Analysis Report Environment

DATA (Dump Analysis + Trace Analysis) Facebook group
Please join the community of memory (dump) and trace analysis engineers. This group promotes scientific methods and memory dump-based worldview.

Twitter @ DumpAnalysis
You can now follow portal and blog news at DumpAnalysis on Twitter

LinkedIn Group Dr. Watson Enthusiasts
All about Dr. Watson errors and more. Get news, excerpts and progress reports about the forthcoming book The Science of Dr. Watson: An Illustrated History of Debugging (ISBN 978-1906717070)

2010 (0x7DA) - The Year of Dump Analysis
2011 (0x7DB) - 2020 (0x7E4) The Debugging Decade

WinDbg help states that NMI_HARDWARE_FAILURE (0×80) bugcheck 80 indicates a hardware fault. This description can easily lead to a conclusion that a kernel or complete crash dump you just got from your customer doesn’t worth examining. But hardware malfunction is not always the case especially if your customer mentions that their system was hanging and they forced a manual dump. Here I would advise to check whether they have a special hardware for debugging purposes, for example, a card or an integrated iLO chip (Integrated Lights-Out) for remote server administration. Both can generate NMI (Non Maskable Interrupt) on demand and therefore bugcheck the system. If this is the case then it is worth examining their dump to see why the system was hanging.

- Dmitry Vostokov -

           

Announcements

Coming Soon:

Debugging Notebook: Essential Concepts, WinDbg Commands and Tools

Crash Dump Analysis for System Administrators and Support Engineers

New Magazines:

Debugged! MZ/PE: MagaZine for/from Practicing Engineers


New Books:

Memory Dump Analysis Anthology, Volume 3

First Fault Software Problem Solving: A Guide for Engineers, Managers and Users

x64 Windows Debugging: Practical Foundations

Also available:

Windows Debugging: Practical Foundations

DLL List Landscape: The Art from Computer Memory Space

Dumps, Bugs and Debugging Forensics: The Adventures of Dr. Debugalov

WinDbg: A Reference Poster and Learning Cards

Memory Dump Analysis Anthology, Volume 2

Memory Dump Analysis Anthology, Volume 1

New Children's Book:

Baby Turing

3 Responses to “Notes about NMI_HARDWARE_FAILURE”

  1. !analyze -v : Notes about NMI_HARDWARE_FAILURE Says:

    […] 이 문서는 http://www.dumpanalysis.org/blog blog 의 번역이며 원래의 자료가 통보 없이 변경될 수 있습니다. 이 자료는 법률적 보증이 없으며 의견을 주시기 위해 원래의 blog 를 방문하실 수 있습니다. (http://www.dumpanalysis.org/blog/index.php/2006/12/23/notes-about-nmi_hardware_failure/)" […]

  2. Crash Dump Analysis » Blog Archive » Crash Dump Analysis Patterns (Part 13f) Says:

    […] in running threads, the first one is a normal memory access fault (blue) and the other is forced NMI bugcheck to save a memory dump […]

  3. Crash Dump Analysis » Blog Archive » Reflecting on 2008 (Part 1) Says:

    […] exception information can be accessed via .ecxr. windbg tips 0×80070026 dmitri windbg gdb teb nmi_hardware_failure system_thread_exception_not_handled system_thread_exception_not_handled (7e) windbg command pool allocations have failed receivelotsacalls trap frame vista dr watson bios […]

Leave a Reply