An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses.
Under Debugging Details the report suggests that the problem was a "WIN_8_DRIVER_FAULT" and that it NotMyFault.exe was active.
An important feature of the debugger's output using !analyze -v is the stack text. Whenever looking at a dump file always look at the far right end of the stack for any third-party drivers. In this case we see myfault. Note that the chronologic sequence of events goes from the bottom to the top; as each new task is performed by the system it shows up at the top. In this rather short stack you can see that myfault was active, then a page fault occurred, and the system declared a BugCheck, which is when the system stopped (Blue Screened).
One way to look at this is that when you see a third-party driver active on the stack when the system crashed, it is like walking into a room and finding a body on the floor and someone standing over it with a smoking gun in his hand; it doesn't mean that he is guilty but makes him suspect No.1.
Output from lmvm (or by selecting myfault)
Knowing the name of a suspect is not enough; you need to know where he lives and what he does. That's where lmvm comes in. It provides a range of data from this image path (not all drivers live in %systemroot%\system32\drivers.), time stamp, image size and file type (in this case a driver) to the company that made it, the product it belongs to, version number and description. Some companies even include contact information for technical support. What the debugger reports, though, is solely dependent upon what the developer included, which, in some cases, is very little.
After you find the vendor's name, go to its Web site and check for updates, knowledge base articles, and other supporting information. If such items do not exist or do not resolve the problem, contact them. They may ask you to send along the debugging information (it is easy to copy the output from the debugger into an e-mail or Word document) or they may ask you to send them the memory dump (zip it up first, both to compress it and protect data integrity).
If you have any questions regarding the use of WinDbg, check out the WinDbg help file. It is excellent. And, when reading about a command be sure to look at the information provided about the many parameters such as "-v" which returns more (verbose) information.
Sign up for CIO Asia eNewsletters.