Debugging Stop 0x35 - NO_MORE_IRP_STACK_LOCATIONS

[x BlueRobot]

NO_MORE_IRP_STACK_LOCATIONS (35)
A higher level driver has attempted to call a lower level driver through
the IoCallDriver() interface, but there are no more stack locations in the
packet, hence, the lower level driver would not be able to access its
parameters, as there are no parameters for it.  This is a disasterous
situation, since the higher level driver "thinks" it has filled in the
parameters for the lower level driver (something it MUST do before it calls
it), but since there is no stack location for the latter driver, the former
has written off of the end of the packet.  This means that some other memory
has probably been trashed at this point.
Arguments:
Arg1: ffff90845a109a40, Address of the IRP
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000

Before reading this tutorial, it is highly recommended that you read the article on IRPs and device stacks, which is available here. As the title of the bugcheck suggests, a driver has attempted to push the IRP down the device stack into a non-existent location. By doing so, the driver would have potentially overwritten a part of a pool page which contains critical kernel data, hence why the system throws the bugcheck as a preventive measure to ensure no further damage is done. There is only one parameter of interest here and that is the address of the IRP itself. Let's dump the IRP using the !irp debugger command:

11: kd> !irp ffff90845a109a40
Irp is active with 132 stacks 131 is current (= 0xffff90845a1077e8)
 Mdl=ffff90845dad2410: No System Buffer: Thread 00000000:  Too many Irp stacks to be believed (>50)!!
Use any flag to force.

Interestingly, we can see that the IRP has been allocated 132 stack locations, with the 131st being the current stack location, therefore we should have enough stack locations to correctly process the IRP, right?

If we examine the current I/O stack location, we'll notice that the region of memory has been completely thrashed:

11: kd> ? ffff9084`5a109b10+(48*131)
Evaluate expression: -122576855568168 = ffff9084`5a10f0d8

11: kd> dt _IO_STACK_LOCATION ffff9084`5a10f0d8
win32k!_IO_STACK_LOCATION
   +0x000 MajorFunction    : 0x82 ''
   +0x001 MinorFunction    : 0x30 '0'
   +0x002 Flags            : 0x26 '&'
   +0x003 Control          : 0x5c '\'
   +0x008 Parameters       : _IO_STACK_LOCATION::<unnamed-type-Parameters>
   +0x028 DeviceObject     : (null)
   +0x030 FileObject       : 0xffffde0f`91697ab8 _FILE_OBJECT
   +0x038 CompletionRoutine : 0xffffde0f`91697ae8     long  +ffffde0f91697ae8
   +0x040 Context          : 0xffff9084`5c1ec080 Void

We can find further evidence of this by forcing the debugger to load the IRP stack trace, using the !irp command along with any given flag:

[...]

 [IRP_MJ_CREATE(0), N/A(0)]
            0  0 616c75676e617463 725f646123202c72 202c316e6f696765-696765725f646123  
          616c75676e617463: Could not read device object or _DEVICE_OBJECT not found
  
            Args: 00000000 00000101 6d756964656d5f65 65725f646123202c
 [IRP_MJ_???(6f), N/A(6e)]
           32 2c 736b6e696c5f6465 6123202c7669645f 6574616c65725f64-5f736b6e696c5f64   Cancel
          736b6e696c5f6465: Could not read device object or _DEVICE_OBJECT not found
  
            Args: 336e6f696765725f 65725f646123202c 23202c356e6f6967 74616c65725f6461
 [IRP_MJ_???(64), N/A(69)]
           76 5f 5f7669645f656361 725f646123202c31 656c5f74726f7065-72616f6272656461 Success   pending
          5f7669645f656361: Could not read device object or _DEVICE_OBJECT not found
  
            Args: 646123202c6d6172 6563616c7065725f 202c305f7669645f 6c7065725f646123
 [IRP_MJ_???(64), N/A(2c)]
           20 23 3374686769725f64 69725f646123202c 6265646953746867-4274737269467261   Cancel pending
          3374686769725f64: Could not read device object or _DEVICE_OBJECT not found
  
            Args: 65725f74726f7065 2c656c676e617463 7365725f64612320 6123202c73746c75
 [IRP_MJ_???(61), N/A(6e)]
           6e 65 315f74686769725f 69725f646123202c 2c786f625f746867-6769725f64612320 Success  Cancel pending
          315f74686769725f: Could not read device object or _DEVICE_OBJECT not found
  
            Args: 74686769725f6461 5372616265646953 6e6142646e6f6365 646123202c72656e
 [IRP_MJ_???(68), N/A(74)]
           5f 63 6e6f635f74686769 01580743 00000001-00000000 Success  Cancel pending
          6e6f635f74686769: Could not read device object or _DEVICE_OBJECT not found

[...]

As we can see, the stack trace shown above contains complete nonsense. It would seem that either a driver has either gone completely haywire and thrashed everything, or hardware malfunction such as faulty RAM. Although, if we examine the call stack for the crash, we can see a possible culprit driver.

11: kd> knL
 # Child-SP          RetAddr           Call Site
00 ffffb383`f0aaa878 fffff800`7383ec96 nt!KeBugCheckEx
01 ffffb383`f0aaa880 fffff800`76b26bc8 nt!IofCallDriver+0x1af516
02 ffffb383`f0aaa8c0 fffff800`76b26dc7 envirtahci+0x16bc8
03 ffffb383`f0aaa940 fffff800`76b22ff7 envirtahci+0x16dc7
04 ffffb383`f0aaa9b0 fffff800`76b252ad envirtahci+0x12ff7
05 ffffb383`f0aaaa40 fffff800`76b219f3 envirtahci+0x152ad
06 ffffb383`f0aaaa70 fffff800`76b23853 envirtahci+0x119f3
07 ffffb383`f0aaaaa0 fffff800`73674825 envirtahci+0x13853
08 ffffb383`f0aaab00 fffff800`736b85f5 nt!IopProcessWorkItem+0x135
09 ffffb383`f0aaab70 fffff800`73755935 nt!ExpWorkerThread+0x105
0a ffffb383`f0aaac10 fffff800`737fe728 nt!PspSystemThreadStartup+0x55
0b ffffb383`f0aaac60 00000000`00000000 nt!KiStartSystemThread+0x28

The driver calls IoCallDriver in order to pass the IRP lower down the stack, however, the function notices that the stack location hasn't been allocated properly and throws the Stop 0x35 bugcheck as shown.

11: kd> lmvm envirtahci
Browse full module list
start             end                 module name
fffff800`76b10000 fffff800`76bd6000   envirtahci   (no symbols)       
    Loaded symbol image file: envirtahci.sys
    Image path: \SystemRoot\System32\drivers\envirtahci.sys
    Image name: envirtahci.sys
    Browse all global symbols  functions  data
    Timestamp:        Wed Feb  7 08:51:14 2018 (5A7ABE02)
    CheckSum:         000CA21D
    ImageSize:        000C6000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

The driver in question appears to be related to AMD AHCI Virtual Storage and therefore it is recommended that the driver is either updated or removed.

References:

The Basics:Bugchecks Explained: NO_MORE_IRP_STACK_LOCATIONS
Bug Check 0x35 NO_MORE_IRP_STACK_LOCATIONS - Windows drivers