bicy
New member
- Joined
- Dec 15, 2023
- Messages
- 12
- Reaction score
- 14
I am sure you have seen these files in any of your minidump files. Without going into an explanation about them, I'll examine a file and briefly explain what they are.
> It says that a bsod is generated as a result of a drive accessing an incorrect address or an invalid address reference. The main thing is to have a high IRQL while doing so.
> As you can see, the IRQL level in the .dmp file is 2, IRQL 2 is used for deferred procedure calls (DPC) and thread scheduling. IRQL 2 is known as the DISPATCH_LEVEL. When a processor is running at a given IRQL, interrupts at that IRQL and lower are blocked by the processor. Therefore, a processor currently at DISPATCH_LEVEL can only be interrupted by a request from an IRQL greater than 2. A system will schedule all threads to run at IRQL's below DISPATCH_LEVEL - this level is also where the thread scheduler itself will run. So if there is a thread that has an IRQL greater than 2, that thread will have exclusive use of the processor. Since the scheduler runs at DISPATCH_LEVEL, and that interrupt level is now blocked off by the thread at a higher IRQL, the thread scheduler cannot run and schedule any other thread. For more detailed information you can refer to chapter 5 of the windows internals book. Windows Internals Book - Sysinternals
>Anyway, we need to go back to our file and look at the stack.
> If you look at the call I have marked in purple, you will see that these(Storport/Stornvme) are disk and storage related drives. The storport.sys driver is the Windows high-level storage driver and stornvme.sys is the Windows NVMe SSD driver. Neither of these drivers are at fault because they are Microsoft drivers.
> When the system is idle, you can see the KiRetireDpcList call, this shows that the IRQL level is at DISPATCH. System crash starts with pci!PciPowerUpDeviceTimerCallback+0x4d0 call. This call detects a power input on the pci port and then calls back the timer with timercallback. DPC. Then these timer processes are successfully completed. Then we see the call storport!RaidAdapterPowerUpDeviceCompletion+0x140dd, which clearly shows that the raid adapter is receiving power from a device. From this we can see that this file was created when a disk was inserted into the system. In the next 2 calls ( storport!RaidAdapterSendPowerToMiniport+0x6b & storport!RaCallMiniportAdapterControl+0x24) The raid adapter sends the power it receives to the port it is connected to. This port is then checked on the port that is connected.Then comes the call stornvme!NVMeHwAdapterControl+0x134 which is related to the nvme driver. Here the nvme driver checks for a hardware-sized adapter. Note the 2 calls immediately following. stornvme!NVMeControllerPowerUp+0x54 The Nvme drive is trying to power up the controller on the disk, it tries it for the 2nd time in the next call stornvme!NVMeControllerInitPart2+0x226. Then storport makes a notification with the call storport!StorPortNotification+0x91c and finally we see that the disk failed with the call storport!StorpMarkDeviceFailed+0x57a. So why?
>We need to look at the trap frame.
>fffff807`6703ccb2 shows that the corresponding device has failed. What about the address that this address refers to? Not valid. Bum. The sentence "An attempt was made to access a pageable (or completely invalid) address at an" in the description of the file applied to exactly this. Our SSD failed because it was trying to access an invalid address, which caused the system to stop and protect itself with a BSoD.
>If we look at the device objects in the file, we will see the nvme drive and pci drives that we are already familiar with, because the system crashed exactly when trying to run the nvme drive disk controller.
This file ends here, I hope I've been able to help
Rich (BB code):
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: 0000000000000018, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff8076703ccb2, address which referenced memory> It says that a bsod is generated as a result of a drive accessing an incorrect address or an invalid address reference. The main thing is to have a high IRQL while doing so.
> As you can see, the IRQL level in the .dmp file is 2, IRQL 2 is used for deferred procedure calls (DPC) and thread scheduling. IRQL 2 is known as the DISPATCH_LEVEL. When a processor is running at a given IRQL, interrupts at that IRQL and lower are blocked by the processor. Therefore, a processor currently at DISPATCH_LEVEL can only be interrupted by a request from an IRQL greater than 2. A system will schedule all threads to run at IRQL's below DISPATCH_LEVEL - this level is also where the thread scheduler itself will run. So if there is a thread that has an IRQL greater than 2, that thread will have exclusive use of the processor. Since the scheduler runs at DISPATCH_LEVEL, and that interrupt level is now blocked off by the thread at a higher IRQL, the thread scheduler cannot run and schedule any other thread. For more detailed information you can refer to chapter 5 of the windows internals book. Windows Internals Book - Sysinternals
Code:
8: kd> !irql
Debugger saved IRQL for processor 0x8 -- 2 (DISPATCH_LEVEL)>Anyway, we need to go back to our file and look at the stack.
Rich (BB code):
8: kd> k
# Child-SP RetAddr Call Site
00 fffff308`2469ed78 fffff807`64a119a9 nt!KeBugCheckEx
01 fffff308`2469ed80 fffff807`64a0d463 nt!KiBugCheckDispatch+0x69
02 fffff308`2469eec0 fffff807`6703ccb2 nt!KiPageFault+0x463 << Crash here
02 fffff308`2469e6a8 fffff807`96dd3d00 Ndu!NduHandleNblContextRemoved+0x650
03 fffff308`2469e028 fffff807`964f2264 dump_diskdump!DiskDumpWrite+0x1d4
03 fffff308`2469f050 fffff807`6700f0ec storport!StorpMarkDeviceFailed+0x57a
04 fffff308`2469f2e0 fffff807`7431dff6 storport!StorPortNotification+0x91c
""Allocate IO queues failed""
05 fffff308`2469f3b0 fffff807`7431e3ec stornvme!NVMeControllerInitPart2+0x226
06 fffff308`2469f430 fffff807`743161b4 stornvme!NVMeControllerPowerUp+0x54
07 fffff308`2469f460 fffff807`67013dc8 stornvme!NVMeHwAdapterControl+0x134
08 fffff308`2469f4f0 fffff807`6703ec37 storport!RaCallMiniportAdapterControl+0x24
09 fffff308`2469f520 fffff807`67028b7d storport!RaidAdapterSendPowerToMiniport+0x6b
0a fffff308`2469f570 fffff807`6485d2a5 storport!RaidAdapterPowerUpDeviceCompletion+0x140dd
0b fffff308`2469f5b0 fffff807`6485d0e7 nt!IopfCompleteRequest+0x1a5
0c fffff308`2469f690 fffff807`66bb22e0 nt!IofCompleteRequest+0x17
0d fffff308`2469f6c0 fffff807`648af389 pci!PciPowerUpDeviceTimerCallback+0x4d0
0e fffff308`2469f7c0 fffff807`648c3a15 nt!KiExpireTimer2+0x429
0f fffff308`2469f8d0 fffff807`648c0fd4 nt!KiTimer2Expiration+0x165
10 fffff308`2469f990 fffff807`64a01fae nt!KiRetireDpcList+0x874
11 fffff308`2469fc20 00000000`00000000 nt!KiIdleLoop+0x9e> If you look at the call I have marked in purple, you will see that these(Storport/Stornvme) are disk and storage related drives. The storport.sys driver is the Windows high-level storage driver and stornvme.sys is the Windows NVMe SSD driver. Neither of these drivers are at fault because they are Microsoft drivers.
> When the system is idle, you can see the KiRetireDpcList call, this shows that the IRQL level is at DISPATCH. System crash starts with pci!PciPowerUpDeviceTimerCallback+0x4d0 call. This call detects a power input on the pci port and then calls back the timer with timercallback. DPC. Then these timer processes are successfully completed. Then we see the call storport!RaidAdapterPowerUpDeviceCompletion+0x140dd, which clearly shows that the raid adapter is receiving power from a device. From this we can see that this file was created when a disk was inserted into the system. In the next 2 calls ( storport!RaidAdapterSendPowerToMiniport+0x6b & storport!RaCallMiniportAdapterControl+0x24) The raid adapter sends the power it receives to the port it is connected to. This port is then checked on the port that is connected.Then comes the call stornvme!NVMeHwAdapterControl+0x134 which is related to the nvme driver. Here the nvme driver checks for a hardware-sized adapter. Note the 2 calls immediately following. stornvme!NVMeControllerPowerUp+0x54 The Nvme drive is trying to power up the controller on the disk, it tries it for the 2nd time in the next call stornvme!NVMeControllerInitPart2+0x226. Then storport makes a notification with the call storport!StorPortNotification+0x91c and finally we see that the disk failed with the call storport!StorpMarkDeviceFailed+0x57a. So why?
>We need to look at the trap frame.
Rich (BB code):
TRAP_FRAME: fffff3082469eec0 -- (.trap 0xfffff3082469eec0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000ffffff rbx=0000000000000000 rcx=ffffc58f2b967e00
rdx=00000000000000c6 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8076703ccb2 rsp=fffff3082469f050 rbp=fffff3082469f180
r8=ffffc58f2b9641a0 r9=0000000000000000 r10=ffffc58f2b9641a0
r11=000000000000002c r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
storport!StorpMarkDeviceFailed+0x57a:
fffff807`6703ccb2 488b4718 mov rax,qword ptr [rdi+18h] ds:00000000`00000018=????????????????
Resetting default scope>fffff807`6703ccb2 shows that the corresponding device has failed. What about the address that this address refers to? Not valid. Bum. The sentence "An attempt was made to access a pageable (or completely invalid) address at an" in the description of the file applied to exactly this. Our SSD failed because it was trying to access an invalid address, which caused the system to stop and protect itself with a BSoD.
Rich (BB code):
8: kd> !pte 00000000`00000018
VA ffffe287d77ca120
PXE at FFFFBDDEEF77BE28 PPE at FFFFBDDEEF7C50F8 PDE at FFFFBDDEF8A1F5D8 PTE at FFFFBDF143EBBE50
contains 0A000000002D5863 contains 0000000000000000
pfn 2d5 ---DA--KWEV contains 0000000000000000
not valid>If we look at the device objects in the file, we will see the nvme drive and pci drives that we are already familiar with, because the system crashed exactly when trying to run the nvme drive disk controller.
Rich (BB code):
fffff80765225188: Unable to get value of ObpRootDirectoryObject
Device object is for:
InfoMask field not found for OBJECT_HEADER at ffffc58f26ad2360
\Driver\pci
Current Irp 00000000 RefCount 0 Type 00000004 Flags 00001040
SecurityDescriptor ffffae80b7a47860 DevExt ffffc58f26ad24e0 DevObjExt ffffc58f26ad2c28 DevNode ffffc58f26b027e0
ExtensionFlags (0000000000)
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) \Driver\stornvme <<< crash
Device queue is not busy.
--------------------------------------------------------------------------
fffff80765225188: Unable to get value of ObpRootDirectoryObject
Device object (ffffc58f2b964050) is for:
Cannot read info offset from nt!ObpInfoMaskToOffset
\Driver\stornvme <<< crash
Current Irp 00000000 RefCount 0 Type 00000004 Flags 00000050
SecurityDescriptor ffffae80b7a47860 DevExt ffffc58f2b9641a0 DevObjExt ffffc58f2b9688e0
ExtensionFlags (0000000000)
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedTo (Lower) \Driver\pci>storport!StorPortNotification+0x91c ""Allocate IO queues failed"" in the file just before the call indicates that an allocation of IO queues failed. This happens right after the NVME driver crash. This stop code is caused by problems with the NVME driver.
This file ends here, I hope I've been able to help
