none
DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) RRS feed

  • Question

  • Hello Guys,

    I am really required some help on this topic.

    I get this bugcheck of my driver.

    DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
    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.
    If kernel debugger is available get stack backtrace.
    Arguments:
    Arg1: 0048b650, memory referenced
    Arg2: 0000000b, IRQL
    Arg3: 00000011, value 0 = read operation, 1 = write operation
    Arg4: 0048b650, address which referenced memory

    it looks like this memory is paged out, but analyzing it I cannot find any prooves about it.

    3: kd> !address -v 48b650
    ===================================================================================================
    PDE:    c0600010 [contains 56f93867]
    
            Page Frame Number:  56f93, at address: 88383414
            Page Location:      6 (Active)
            Virtual address:    c0002000
            PTE Address:        c0600010
            Containing frame:   00058cc0
            Attributes:         M:Modified,Cached
            Usage:              PTEs; Process bb5d00c0 [CNCInterpreter], Entries:0
    
    ===================================================================================================
    PTE:    c0002458 [contains 40243125]
    
            Page Frame Number:  40243, at address: 88103f54
            Page Location:      6 (Active)
            PTE Address:        bd674458
            Containing frame:   00050c65
            Attributes:         P:Prototype,Cached
            Usage:              MappedFile; CA:9668fca8 []
    
    Type:   Valid
    Attrs:  Global,NormalPage,NotDirty,NotDirty1,Accessed,User,NotWritable,NotWriteThrough,Cached
    PFN:    40243

    Could you please help me how to proove that memory is invalid ?

    Thanks.

    With respects, Eugene.

    Wednesday, December 4, 2019 12:35 PM

Answers

  • The address 48b650 is user space so is almost guaranteed to be pageable.  You are accessing it at an IRQL that cannot page, so you are getting the crash.   In fact since this is a user space address if you are in something like the Interrupt Service Routine for your driver, it may not even be the same process running in user space.   Your driver needs to map to kernel space the address locking down the memory using MmProbeAndLock pages, then storing the kernel address for use at the point where the bug check occurred.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Wednesday, December 4, 2019 3:04 PM
  • Hello Guys,

    Thanks for everybody, who helped me by any information.

    I have solved my problem.

    Thanks.

    With respects, Eugene.

    • Marked as answer by EugeneApp Thursday, January 9, 2020 10:06 AM
    Wednesday, January 8, 2020 1:49 PM

All replies

  • The address 48b650 is user space so is almost guaranteed to be pageable.  You are accessing it at an IRQL that cannot page, so you are getting the crash.   In fact since this is a user space address if you are in something like the Interrupt Service Routine for your driver, it may not even be the same process running in user space.   Your driver needs to map to kernel space the address locking down the memory using MmProbeAndLock pages, then storing the kernel address for use at the point where the bug check occurred.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Wednesday, December 4, 2019 3:04 PM
  • Thank you, Don. I have some additional question. How coult memory be paged If I turned off paging file in my Windows 10 ?

    With respects, Eugene.

    Thursday, December 5, 2019 10:00 AM
  • Paging involves more than just the paging file.  For example, the read only parts of an executable are brought in from the executables file directly.  Memory mapping a file is paging, except that it uses the file as its backing store.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Thursday, December 5, 2019 12:19 PM
  • Don, Am I right if I understood it as

    Any executable, which mapped to memory, sometimes backs store to original file on disk? In case, for example, process doesn't execute any active code ? And it is impossible to disable this behavour.

    Thanks.

    With respects, Eugen.

    Thursday, December 5, 2019 12:50 PM
  • There is no way to complete disable paging, for instance how is an executable loaded in the first place.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Thursday, December 5, 2019 1:24 PM
  • Even I call for virtual memory VirtualLock function it happens. Also it was no any bugcheck on windows 7.

    With respects, Eugene.

    Thursday, December 5, 2019 2:43 PM
  • No you cannot stop paging, forget this it will not work.  Even the diskless embedded versions of Windows used a virtual disk for some paging.  Turn on Driver Verifier with Forced IRQL Checking and I suspect that your driver will fail on any system.  Just because it works on a version of Windows does not mean it is correctly coded, it just means you got lucky.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Thursday, December 5, 2019 2:50 PM
  • You mean that IRQL has a meaning ? I am free to set any IRQL for my driver. DISPATCH_LEVEL also provide d1 bugcheck.

    With respects, Eugene.

    Thursday, December 5, 2019 2:52 PM
  • IRQL has a lot of meaning, and no you are not able to control IRQL in many situations in your driver.   You need to seriously consider reading a good book on Windows Driver Development or consider taking a class.   IRQL is one of the base concepts every developer must know.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Thursday, December 5, 2019 3:04 PM
  • Don, thank you. I know what is it IRQL. And I am sure I can set almost any IRQL level for my driver code ). I wanted to ask, if I call my driver code on APC_LEVEL would it be helpfull to kill d1 bugcheck ?

    With respects, Eugene.

    Thursday, December 5, 2019 3:19 PM
  • Are you the one setting your IRQL to 11 or is the code running off something like an interrupt service routine.  If you are setting the IRQL high, redesign all your code to stop doing this.   If the IRQL is because of the interrupt service routine, you cannot mess with this, lowering the IRQL on you own in this case will cause a crash for sure.

    Basically, for year I've had the rule when I review someones code if I see a KeLowerIrql() call it is probably a bug.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Thursday, December 5, 2019 3:28 PM
  • Thank you Don for avdices and help. IRQL 0xB is the default value for my ISR, but it is clear I have possibility to set it to any other value. I will check is it the problem in IRQL.

    What book could you advise for Windows Internal understanding? I do not need "smart" book. I need book with clear explanation.

    With respects, Eugene.

    Friday, December 6, 2019 5:52 AM
  • Sorry for a lot of questions.

    I see in my windbg this kind of traces:

    *** Fatal System Error: 0x0000007f
                           (0x00000008,0x84D98400,0x00000000,0x00000000)
    
    Break instruction exception - code 80000003 (first chance)
    
    A fatal system error has occurred.
    Debugger entered on first try; Bugcheck callbacks have not been invoked.
    
    A fatal system error has occurred.
    
    WARNING: Process directory table base DD21CBC0 doesn't match CR3 001A8000
    WARNING: Process directory table base DD21CBC0 doesn't match CR3 001A8000

    And looking into warnings. Does it mean incorrect CR3 register value? It means wrong context was set ? 

    Thanks.

    With respects, Eugene.

    Friday, December 6, 2019 7:21 AM
  • Open the windbg help file (you have windbg, right?) and find in the contents "Bug checks (blue screens)".

    Then look for "Bug Check 0x7F, 

    This with 1st parameter 8 means double fault. Usually caused by kernel stack overflow or... young "security researchers" doing something creative ;)

    -- pa

    Saturday, December 7, 2019 4:15 AM
  • Nice answer)) Thank you for smile. I was interested in WARNING explanations, but this kind of influence on my life also welcome)

    With respects, Eugene.

    Saturday, December 7, 2019 6:33 AM
  • Hello Experts,

    My summarize question. It is about VirtualLock function from memoryapi.h .

    Does anybody know did behavour of this function change with Windows 10 comparing with Windows 7 ?

    In 2014 year the behavour was not the same as before - https://devblogs.microsoft.com/oldnewthing/?p=1833

    Thanks in advance.

    With respects, Eugene.

    Wednesday, December 11, 2019 6:48 AM
  • Hello Guys,

    Thanks for everybody, who helped me by any information.

    I have solved my problem.

    Thanks.

    With respects, Eugene.

    • Marked as answer by EugeneApp Thursday, January 9, 2020 10:06 AM
    Wednesday, January 8, 2020 1:49 PM