The ntkrnlmp.exe file is the Windows multiprocessor kernel (ntoskrnl.exe is the core kernel, that's often seen in BSOD dumps too). The reason is that most BSODs are caused by old/bad/flaky/wrong third-party drivers, the rest are caused by hardware failures. When a driver fouls up a memory pointer or a memory allocation, or otherwise screws-up, the error isn't usually detected until the driver returns control to the Windows kernel. It's the kernel that does the real hardware accesses and that's the point at which the failure becomes apparent, but because the kernel has no way of knowing how serious the third-party driver foul-up was, or whether user data may be corrupted if execution continues, the kernel writes a memory dump, displays a blue screen with the bugcheck name displayed (eg IRQL_NOT_LESS_OR_EQUAL), and then halts the system. We call that a Blue Screen Of Death (BSOD). Windows, if so configured, may then auto restart.
The dump that was produced contains the status at the time the error was detected, since that's very often in the Windows kernel (ntkrnlmp.exe or ntoskrnl.exe) that's the failing module name that gets displayed.
This is why tools like WhoCrashed and BlueScreenView are largely useless, because they only display the bugcheck code, the failing module name, and the four bugcheck arguments. If the failing module name is ntoskrnl.exe or ntkrnlmp.exe - as it so often is, and which we know is not at fault - then you know nothing useful. Debugging the resulting dump and unwinding the process of function calls that led up to the bugcheck is the only way to discover the thrid-party driver (or hardware failure) that was the root cause. That requires considerabale experience and skills to do sucessfully. If you think you have the background and apptitude to learn to diagnose BSOD dumps then I can strongly recommend the
Sysnative BSOD Academy.
