The following code shows a debugging example: kd>. For more information, see Driver Verifier. The code that verifies drivers adds overhead as it runs, so try to verify the smallest number of drivers as possible. You can configure which drivers to verify. To start Driver Verifier Manager, type verifier at a command prompt. Driver Verifier Manager is built into Windows and is available on all Windows PCs. If it identifies errors in the execution of driver code, it proactively creates an exception to allow that part of the driver code to be further scrutinized. For example, Driver Verifier checks the use of memory resources, such as memory pools. Driver Verifierĭriver Verifier is a tool that runs in real time to examine the behavior of drivers. Look for critical errors in the system log that occurred in the same time frame as the blue screen. Gather informationĮxamine the name of the driver if it was listed on the blue screen.Ĭheck the System Log in Event Viewer for other error messages that might help pinpoint the device or driver that's causing the error. Next, enter one of the k* (display stack backtrace) commands to view the call stack. The !analyze extension can be helpful in determining the root cause. Start by running the !analyze debugger extension to display information about the bug check. If a kernel debugger is available, obtain a stack trace. Investigate the validity of parameter 1 with !pte, !address, and ln (list nearest symbols). It may be a bad pointer caused by use-after-free or bit-flipping. Run at a lower IRQL, or don't mark the code as pageable. If parameter 3 indicates that the bug check was an attempt to execute pageable code, then the IRQL is too high to call this function. Run at a lower IRQL, or allocate the data in the nonpaged pool. If !pool reports that parameter 1 is paged pool (or other types of pageable memory), then the IRQL is too high to access this data. If parameter 1 is less than 0x1000, the issue is likely a NULL pointer dereference. General guidelines that you can use to categorize the type of coding error that caused the bug check are as follows: The cause is either a bad memory pointer or a pageability problem with the device driver code. This bug check indicates that an attempt was made to access an invalid address while at a raised interrupt request level (IRQL). This bug check is caused by kernel-mode device drivers that use improper addresses. Use the ln (List Nearest Symbols) command on this address to see the name of the function. The instruction pointer at the time of the fault. For example, if the code acquires a spinlock, or is called in a deferred procedure call. Marking code as pageable when it must be non-pageable.Calling a function that can't be called at DISPATCH_LEVEL while at DISPATCH_LEVEL.Note that bit 3 is only available on chipsets that support this level of reporting.Ġx0 - Fault trying to READ from the address in parameter 1Ġx1 - Fault trying to WRITE to the address in parameter 1Ġx8 - Fault trying to EXECUTE code from the address in parameter 1 Other commands that might be useful in gathering information about the failure are !pte, !address, and ln (List Nearest Symbols).Ģ - The IRQL was DISPATCH_LEVEL at the time of the fault.īit field that describes the operation that caused the fault. Use !pool on this address to see whether it's a paged pool. The virtual memory address that couldn't be accessed. IRQL_NOT_LESS_OR_EQUAL parameters Parameter If you're a customer who has received a blue screen error code while using your computer, see Troubleshoot blue screen errors.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |