Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

How to solve Windows 10 crashes in less than a minute

Dirk A.D. Smith | Aug. 2, 2016
This article deals with system crashes, not application crashes or system hangs.

!analyze -v The output from selecting !analyze -v provides more detail about the system crash event. In this case, the analysis accurately describes the actions of the test driver (myfault.sys) which was instructed by the test program to access an address at an interrupt level that was too high.

Output from !Analyze -v DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

only select debugging tools for windows

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.

The BUCKET_ID_FUNC_OFFSET is the distance from the base address of the suspect module where the problematic code resides

 

The important points are that the suspect module named by WinDbg is myfault and that, since we know that this is a third-party driver, he is very likely guilty.

To get a better picture of what was happening when the OS fell over, look at the stack.

Walking the stack It is always important to look at the stack output displayed by the debugger because it shows who was active and what he was doing leading up to the crash. When looking at the stack, always look at the far right end of the stack for any third-party drivers and always remember that the stack is displayed in reverse chronological order. Therefore, the 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, pushing the previous actions down. In this stack you can see that NotMyFault/myfault was active. Following the last activity by the driver, Windows 10 declared a PageFault then a BugCheck which stopped the system (Blue Screened).

The metaphor that I have often used in technical sessions is to relate stack walking with stepping into the room where a murder just took place and finding a body on the floor and someone standing over it with a smoking gun in his hand; it does not mean that he is guilty but it surely makes him suspect No.1.

not my fault was active

NotMyFault/ myfault was active

 

Assuming that we need more information about the suspect module, run lmvm.

lmvm

lmvm [module name] Now that we have a suspect module to consider, it is important to learn more about it. The two key reasons for this are simply to ensure that it is indeed a third-party module and to determine if it is an out of date module. lmvm tells both and more as shown in the exhibit. For instance, we can see that the maker of the module is SysInternals and that it has a timestamp of April 2012.

 

Previous Page  1  2  3  4  5  6  7  8  9  10  Next Page 

Sign up for Computerworld eNewsletters.