Sadly I can't read the whole doc now since I'm heading home from work in a min, but I've run into a description of the IRQL thing before
sorry, I'll read the rest later!
anyway, short version, aiui this is an unhandled/unhandleable memory access violation in elevated code and almost certainly the fault of a driver doing something wrong or the hardware it's running doing something fucked up that causes an edge case nobody anticipated
so yeah IRQL here is different from old timey IRQ conflicts, I only have a general vague feeling for it because I don't do much windows troubleshooting or dev etc etc but basically some part of windows tried to access invalid memory while in an elevated interrupt request level (as in, software scheduling, not hardware interrupts, thanks for the super ambiguous naming convention though)
since it expects all code at an elevated IRQL to run to completion without interruption (except maybe by a higher IRQL? I think?), doing things like accessing invalid or nonpaged memory can't be handled in the normal method of generating a page fault and then Doing The Right Thing, because that would be a lower IRQL interrupting an higher one (I THIIIINK??)
I'd probably this probably means "some driver running some code at an elevated IRQL fucked up" like 99% of the time
so IRQL_NOT_LESS_OR_EQUAL literally means that the unhandleable memory thing happened while the running IRQL was higher than whatever threshold page faults and access violations (etc) can be handled at
also it's a fucking terrible name for what it means
