Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- # Analysis of a system crash related to Intel iaStorAC.sys on wakeup from hibernation
- Crashdump analysis: serbian.intel.hibernate.wakeup.3rd_party.debugprivilege.dmp.
- Kernel dump file provided by DebugPrivilege: https://mega.nz/file/oo8kXSpA#U7LNLJSdXtAq4Vfq6TFv1KcJ9WzQm_NBDwbQHQrKbQo
- Analysis by sixtyvividtails.
- Here I'll just provide windbg output with my comments.
- You can spot windbg commands and important stuff in the wall of text by scanning for chars in the higher Unicode planes;
- if you have human eyes you should see colored emojis.
- Edit 2025-10-08:
- * slightly rephrased the first encounter with iaStorAC to indicate there's more evidence towards the analysis end
- * added link to the 3rd analysis
- ## Analysis Links
- There are now three analysis takes for the very same dump :)
- 1. First analysis by DebugPrivilege. Has some daring takes, but further reviews show the root cause lies elsewhere.
- https://medium.com/@Debugger/hibernation-crash-traced-to-intel-gpu-driver-igdkmdn64-during-power-transition-5b05b30c94ce
- thread: https://twitter.com/DebugPrivilege/status/1970720013125361763
- 2. Analysis by sixtyvividtails. In response to the first analysis. Identifies iaStorAC.sys as the root cause.
- π [You are here]: https://pastebin.com/psVhq6Pe
- π thread: https://x.com/sixtyvividtails/status/1975606844363075714
- 3. Second analysis by DebugPrivilege. Contains additional pointers and evidence, marking iaStorAC.sys as the culprit.
- https://medium.com/@Debugger/unexpected-store-exception-0x154-root-cause-storage-i-o-failure-in-iastorac-sys-2745d9de6202
- thread: https://x.com/DebugPrivilege/status/1975733380395495671
- π€¨ Wait, which analysis to read then?
- Since you're already here at (2), you should save traffic and read this one πΈ. Or you can read the (3), your decision.
- Or, if you like, you can look at both (2) and (3) - while the conclusion is basically the same,
- the flow in (2) and (3) is quite different, and analysis steps don't even intersect much!
- ## Additional Links
- script to enum ntfs volumes: https://twitter.com/sixtyvividtails/status/1960578133616152712
- Whitepaper referenced: 2019.Extracting Compressed Pages from the Windows 10 Virtual Store.Sardar.[MemCompression].pdf
- ## Analysis
- π½ [opens crashdump file in the newest Windbg]
- Microsoft (R) Windows Debugger Version 10.0.27920.1001 AMD64
- Copyright (c) Microsoft Corporation. All rights reserved.
- Loading Dump File [C:\stuff\dumps\serbian.intel.hibernate.wakeup.3rd_party.debugprivilege.dmp]
- Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available.
- Windows 10 Kernel Version 19041 MP (8 procs) Free x64
- Product: WinNt, suite: TerminalServer SingleUserTS Personal
- Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
- Kernel base = 0xfffff801`14200000 PsLoadedModuleList = 0xfffff801`14e2a230
- Debug session time: Thu Jun 24 04:42:52.788 2021 (UTC + 0:00) π½ time of crash (analyst local time)
- System Uptime: 6 days 17:51:30.552 π½ uptime at the moment of crash
- Loading Kernel Symbols...
- Loading User Symbols...
- PEB address is NULL ! π½ no usermode dll symbols: no PEB[.Ldr]; that's ok
- π½ ^^ Note "Debug session time" displays time of crash as local time of the analyst box (machine with Windbg running),
- it is NOT the local time on the target box (the crashed machine).
- The value in parens is simply analyst timezone. Since I live in Utc, my timezone is set to 0 (convenient).
- π½ Since we've started talking about timezones, let's check target box timezone too.
- β¨β¨β¨β¨β¨β¨β¨β¨
- 2: kd> !kuser
- _KUSER_SHARED_DATA at fffff78000000000 π°οΈ I've copypasted this address for command right below
- TickCount: fa00000 * 00000000023908a3 (6:17:51:30.546)
- TimeZone Id: 2 π½ 2: TIME_ZONE_ID_DAYLIGHT (daylight saving)
- ImageNumber Range: [8664 .. 8664]
- Crypto Exponent: 0
- SystemRoot: 'C:\WINDOWS'
- BootId: 10 π½ system has booted only 0n10 times since install
- β¨β¨β¨
- 2: kd> ?? *(int64*)(0xfffff78000000000 + #FIELD_OFFSET(KUSER_SHARED_DATA, TimeZoneBias))/(10*1000*1000*60)
- int64 0n-120 π½ target timezone is -120 minutes, i.e. UTC-2:00 (includes daylight bias)
- π½ ^^ If you're unsure what just happened:
- I've used C++ expression evaluation "??" (similar to masm evaluation "?"), to do a very simple thing:
- read KUSER_SHARED_DATA.TimeZoneBias, cast it to int64, and convert value from centums (100 ns units) into minutes.
- π½ Let's continue with time.
- β¨β¨β¨
- 2: kd> !time
- CURRENT TIME:
- System: 01d768b3`64a7f260 (2021 Jun 24 04:42:52.788) π½ target box time, *always* UTC here
- Interrupt: 0000054c`aea24ca6 (6 days, 17:51:30.552) π½ target "uptime"
- Unbiased Interrupt: 000001ba`87a64e35 (2 days, 04:47:45.136) π½ target uptime without sleeping
- π½ ^^ We are already starting to get some insights. We can see that system "uptime" is more than 6 days.
- However, that "uptime" is biased. That is, it includes sleep/hibernate time! (Also some of DRIPS time).
- For the real uptime, see Unbiased Interrupt Time.
- π So the system has booted 6ΒΎ days ago [before the crash], but actual total work time is about 53 hours (2 days+).
- I guess such use pattern is fairly normal for a laptop.
- π½ Okay, enough messing around. Let's run the magic command which shall solve everything.
- β¨β¨β¨β¨β¨β¨β¨β¨
- 2: kd> !analyze -v
- π½ [outputs nothing]
- π½ [nothing happens]
- Okay. I've actually just updated DbgX (aka Windbg Preview). That's version from 2025-08-27. Today is 2025-09-28.
- I was pretty sure Microsoft ought to unfuckup any serious Windbg fuckups in a month time? Lol, wtf.
- π Yep, the basic command "!analyze" doesn't work in this Windbg for kernel dumps. Looks like Microsoft code became
- so good, they just don't need to analyse kernel crashdumps anymore! πΈ. Fine. Let's just switch to Windbg Classic.
- β¨β¨β¨β¨β¨β¨β¨β¨
- π½ [reopens crashdump file in the Windbg classic]
- Microsoft (R) Windows Debugger Version 10.0.26100.1 AMD64
- Copyright (c) Microsoft Corporation. All rights reserved.
- Loading Dump File [C:\stuff\dumps\serbian.intel.hibernate.wakeup.3rd_party.debugprivilege.dmp]
- Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available.
- Windows 10 Kernel Version 19041 MP (8 procs) Free x64
- Product: WinNt, suite: TerminalServer SingleUserTS Personal
- Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
- Kernel base = 0xfffff801`14200000 PsLoadedModuleList = 0xfffff801`14e2a230
- Debug session time: Thu Jun 24 04:42:52.788 2021 (UTC + 0:00) π½ time of crash (analyst local time)
- System Uptime: 6 days 17:51:30.552 π½ uptime at the moment of crash
- Loading Kernel Symbols...
- Loading User Symbols...
- PEB address is NULL ! π½ no usermode dll symbols: no PEB[.Ldr]; that's ok
- π½ We got same output as before so far. Let's run the magic command [round 2].
- β¨β¨β¨β¨β¨β¨β¨β¨
- 2: kd> !analyze -v
- *******************************************************************************
- * *
- * Bugcheck Analysis *
- * *
- *******************************************************************************
- UNEXPECTED_STORE_EXCEPTION (154) π½π¦ note the bugcheck code and parameters
- The store component caught an unexpected exception.
- Arguments:
- Arg1: ffffb005e91ba000, Pointer to the store context or data manager π½π½πͺ address of SMKM_STORE (found out below)
- Arg2: ffffe509f8198620, Exception information π½π§¨π° address of EXCEPTION_POINTERS
- Arg3: 0000000000000002, Reserved π½π½β windbg doesn't know (found out below)
- Arg4: 0000000000000000, Reserved
- Debugging Details:
- ------------------
- KEY_VALUES_STRING: 1
- π½ this badly presented block is for the analyst box; i.e. it's extension internal debug info, ignore it
- Key : Analysis.CPU.mSec
- Value: 5561
- Key : Analysis.DebugAnalysisManager
- Value: Create
- Key : Analysis.Elapsed.mSec
- Value: 5478
- Key : Analysis.Init.CPU.mSec
- Value: 2467
- Key : Analysis.Init.Elapsed.mSec
- Value: 8304
- Key : Analysis.Memory.CommitPeak.Mb
- Value: 94
- π½ this block is for the target box (but we've already seen that info right after loading the dump file)
- Key : WER.OS.Branch
- Value: vb_release
- Key : WER.OS.Timestamp
- Value: 2019-12-06T14:06:00Z
- Key : WER.OS.Version
- Value: 10.0.19041.1
- FILE_IN_CAB: serbian.intel.hibernate.wakeup.3rd_party.debugprivilege.dmp
- BUGCHECK_CODE: 154
- BUGCHECK_P1: ffffb005e91ba000
- BUGCHECK_P2: ffffe509f8198620
- BUGCHECK_P3: 2
- BUGCHECK_P4: 0
- EXCEPTION_RECORD: ffffe509f81995a8 -- (.exr 0xffffe509f81995a8) π½π§¨ note the .exr XXX command
- ExceptionAddress: fffff801144d10d0 (nt!RtlDecompressBufferXpressLz+0x0000000000000050)
- ExceptionCode: c0000006 (In-page I/O error)
- ExceptionFlags: 00000000
- NumberParameters: 3
- Parameter[0]: 0000000000000000
- Parameter[1]: 0000027e296ab9f0
- Parameter[2]: 00000000c000000e
- Inpage operation failed at 0000027e296ab9f0, due to I/O error 00000000c000000e π½π± almost everything we need
- EXCEPTION_PARAMETER1: 0000000000000000
- EXCEPTION_PARAMETER2: 0000027e296ab9f0
- CONTEXT: ffffe509f8198de0 -- (.cxr 0xffffe509f8198de0) π½π° note the .cxr XXX command
- rax=fffff801144d1080 rbx=ffffd3011992f000 rcx=ffffd3011992f000
- rdx=ffffd3011992f000 rsi=0000000000000002 rdi=0000027e296ab9f0
- rip=fffff801144d10d0 rsp=ffffe509f81997e8 rbp=0000027e296ab9af
- r8=0000027e296ab9f0 r9=0000000000000015 r10=ffffd3011992fea0
- r11=0000027e296aba05 r12=ffffe509f8199a58 r13=ffffb005ee4ef000
- r14=ffffd30119930000 r15=0000000000000000
- iopl=0 nv up ei pl zr na po nc
- cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00050246
- nt!RtlDecompressBufferXpressLz+0x50:
- fffff801`144d10d0 418b08 mov ecx,dword ptr [r8] ds:002b:0000027e`296ab9f0=????????
- Resetting default scope
- BLACKBOXBSD: 1 (!blackboxbsd)
- BLACKBOXNTFS: 1 (!blackboxntfs)
- BLACKBOXPNP: 1 (!blackboxpnp)
- BLACKBOXWINLOGON: 1
- PROCESS_NAME: MemCompression π½βοΈ note the process name
- ERROR_CODE: (NTSTATUS) 0xc0000006 - The instruction at 0x%p referenced memory at 0x%p. The required data was not placed into memory because of an I/O error status of 0x%x.
- EXCEPTION_CODE_STR: c0000006
- EXCEPTION_PARAMETER3: 00000000c000000e
- EXCEPTION_STR: 0xc0000006
- STACK_TEXT: π½π₯ note the callstack
- ffffe509`f81997e8 fffff801`144a6bf0 : ffffd301`1992f000 ffffd301`1992f000 00000000`00000002 0000027e`296ab9f0 : nt!RtlDecompressBufferXpressLz+0x50
- ffffe509`f8199800 fffff801`144a6938 : 00000000`00000001 00000000`00000000 00000000`00000000 00000000`00000002 : nt!RtlDecompressBufferEx+0x60
- ffffe509`f8199850 fffff801`144a67c5 : 00000000`00000004 fffff801`144a632e 00000000`00000000 00000000`00000001 : nt!ST_STORE<SM_TRAITS>::StDmSinglePageCopy+0x150
- ffffe509`f8199910 fffff801`144a5ffc : 00000000`00000001 00000000`0000b9f0 ffffb005`e91ba000 ffffb005`00001000 : nt!ST_STORE<SM_TRAITS>::StDmSinglePageTransfer+0xa5
- ffffe509`f8199960 fffff801`144a5e2c : 00000000`ffffffff ffffb005`ee4ef000 ffffe509`f8199a40 ffffb005`f7e24710 : nt!ST_STORE<SM_TRAITS>::StDmpSinglePageRetrieve+0x180
- ffffe509`f8199a00 fffff801`144a5c79 : ffffd301`19bda730 00000000`00000001 00000000`00000000 00000000`00000000 : nt!ST_STORE<SM_TRAITS>::StDmPageRetrieve+0xc8
- ffffe509`f8199ab0 fffff801`144a5b31 : ffffb005`e91ba000 ffffb005`f7e24710 ffffb005`ee4ef000 ffffb005`e91bb9c0 : nt!SMKM_STORE<SM_TRAITS>::SmStDirectReadIssue+0x85
- ffffe509`f8199b30 fffff801`14498bc8 : ffffb005`df2c8480 ffffb005`e91ba000 00000000`00000000 ffffb005`ff1175f0 : nt!SMKM_STORE<SM_TRAITS>::SmStDirectReadCallout+0x21
- ffffe509`f8199b60 fffff801`144a368f : fffff801`144a5b10 ffffe509`f8199c00 00000000`00000003 00000000`00000000 : nt!KeExpandKernelStackAndCalloutInternal+0x78
- ffffe509`f8199bd0 fffff801`14559934 : ffffe509`f8199cd0 00000000`31526d73 00000000`000003ff fffff801`14f239c0 : nt!SMKM_STORE<SM_TRAITS>::SmStDirectRead+0xc7
- ffffe509`f8199ca0 fffff801`14559368 : 00000000`0000000c 00000000`000003ff ffffe509`f8199d50 fffff801`14f239c0 : nt!SMKM_STORE<SM_TRAITS>::SmStWorkItemQueue+0x1ac
- ffffe509`f8199cf0 fffff801`144a4117 : 00000000`0000000c 00000000`00000001 ffffb005`f7e24710 ffffb005`ff1175f0 : nt!SMKM_STORE_MGR<SM_TRAITS>::SmIoCtxQueueWork+0xc0
- ffffe509`f8199d80 fffff801`144fa96b : ffffb005`00000001 ffffb005`ff1176b0 00000000`00000000 ffffb005`e91ba000 : nt!SMKM_STORE_MGR<SM_TRAITS>::SmPageRead+0x167
- ffffe509`f8199df0 fffff801`1445e0a0 : ffffe509`00000100 00000000`00000000 ffffe509`f819a048 fffff801`1445bff0 : nt!SmPageRead+0x33
- ffffe509`f8199e40 fffff801`1445bb4d : 00000000`00000002 ffffe509`f8199ed0 ffffe509`f819a048 ffffb005`ff1175a0 : nt!MiIssueHardFaultIo+0x10c
- ffffe509`f8199e90 fffff801`14528278 : 00000000`c0033333 00000000`00000000 ffff9c89`4f503000 00000000`00000000 : nt!MiIssueHardFault+0x29d
- ffffe509`f8199f50 fffff801`1442a4d2 : ffff9c89`46e00100 00000000`00000000 ffff9c89`46e00340 0078d807`00002084 : nt!MmAccessFault+0x468
- ffffe509`f819a0f0 fffff801`14460836 : ffffb005`f0086090 ffffe509`f819a218 ffffb005`fd4b7111 ffffb005`fdb2fc50 : nt!MiDeleteSubsectionPages+0x172
- ffffe509`f819a1b0 fffff801`14808d56 : 00000000`000800a1 00000000`00000000 fffff801`14e50b00 00000000`000800a1 : nt!MiDeleteSegmentPages+0x56
- ffffe509`f819a210 fffff801`14584a89 : 00000000`00000001 00000000`00000000 ffffe509`f819a2e0 ffffb005`f0086018 : nt!MiSegmentDelete+0x92
- ffffe509`f819a260 fffff801`145ba179 : 00000000`00000000 fffff801`00000001 00000000`00000000 00000000`00000000 : nt!MiProcessDereferenceList+0xc1
- ffffe509`f819a320 fffff801`144f53b5 : ffffb005`df2c8480 ffffb005`df2c8480 00000000`00000080 fffff801`145ba050 : nt!MiDereferenceSegmentThread+0x129
- ffffe509`f819a550 fffff801`145fe278 : ffffd301`19bd2180 ffffb005`df2c8480 fffff801`144f5360 00000000`00000000 : nt!PspSystemThreadStartup+0x55
- ffffe509`f819a5a0 00000000`00000000 : ffffe509`f819b000 ffffe509`f8194000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x28
- SYMBOL_NAME: nt!RtlDecompressBufferXpressLz+50
- MODULE_NAME: nt
- IMAGE_NAME: ntkrnlmp.exe
- STACK_COMMAND: .cxr 0xffffe509f8198de0 ; kb
- BUCKET_ID_FUNC_OFFSET: 50
- FAILURE_BUCKET_ID: 0x154_c0000006_c000000e_nt!RtlDecompressBufferXpressLz
- OS_VERSION: 10.0.19041.1
- BUILDLAB_STR: vb_release
- OSPLATFORM_TYPE: x64
- OSNAME: Windows 10
- FAILURE_ID_HASH: {04bbc5ba-a28a-9efe-b2fd-8956bfd9dd67}
- Followup: MachineOwner
- ---------
- β¨β¨β¨β¨β¨β¨β¨β¨
- π½ What do we have here? Command "!analyze -v" has extracted significant information from the dump for us.
- π½π¦ Bugcheck code: 0x154, UNEXPECTED_STORE_EXCEPTION. Let's duplicate that piece of output for quick reference:
- """
- UNEXPECTED_STORE_EXCEPTION (154) π½π¦
- The store component caught an unexpected exception.
- Arguments:
- Arg1: ffffb005e91ba000, Pointer to the store context or data manager π½π½πͺ address of SMKM_STORE (found out below)
- Arg2: ffffe509f8198620, Exception information π½π§¨π° address of EXCEPTION_POINTERS
- Arg3: 0000000000000002, Reserved π½π½β windbg doesn't know (found out below)
- Arg4: 0000000000000000, Reserved
- """
- π½ The bugcheck code itself doesn't immediatelly tell us much.
- We can lookup more info in Windbg HELP.CHM: press F1 and search, or simply type windbg command `.hh bug check 0x154`.
- However, that won't give us much either, as the help file doesn't have any extra info compared to the already displayed.
- Function KeBugCheckEx has 4 [arbitrary] arguments beside the bugcheck code, and some Args have non-zero values here.
- Arg1. Pointer to SMKM_STORE object (we actually don't know it, but willl find out soon; well, doesn't matter anyway).
- Arg2. That's an address of EXCEPTION_POINTERS: simply a container for 𧨠EXCEPTION_RECORD and π° CONTEXT pointers.
- Note "!analyze -v" has already extracted these pointers (you can run "dps ffffe509f8198620 L2" and they'll match).
- Arg3. We don't know what "2" means. We can disasm ntoskrnl and find out (look for KeBugCheckEx with code 0x154),
- but right now there's no point doing that, as we have much better options to explore.
- The main takeaway right now is the description string "The store component caught an unexpected exception".
- Looking at the π₯callstack, it makes sense - there is indeed "ST_STORE" and "SMKM_STORE" πͺ object methods there,
- so let's move to explore the exception which the store component couldn't handle.
- β¨β¨β¨β¨β¨β¨β¨β¨
- π½ Let's rerun 𧨠".exr XXX" to avoid scrolling up to "!analyze -v" output.
- π½π§¨
- 2: kd> .exr 0xffffe509f81995a8 π½π§¨
- ExceptionAddress: fffff801144d10d0 (nt!RtlDecompressBufferXpressLz+0x0000000000000050)
- ExceptionCode: c0000006 (In-page I/O error) π₯π΄π nobody expects the STATUS_IN_PAGE_ERROR
- ExceptionFlags: 00000000
- NumberParameters: 3 π½ rdx: KiExceptionDispatch extra args count (in r9, r10, r11)
- Parameter[0]: 0000000000000000 π½ r9, xarg1: mem op, from CPU-pushed #PF code (mask 1: W; 8: X)
- Parameter[1]: 0000027e296ab9f0 π½ r10, xarg2: address referenced which caused fault
- Parameter[2]: 00000000c000000e π½π r11, xarg3: error code returned from MmAccessFault
- Inpage operation failed at 0000027e296ab9f0, due to I/O error 00000000c000000e π½π± almost everything we needed
- π½ ^^ So something needed a page-in operation (previously paged out data needed to be read), but for some reason that
- operation failed. STATUS_IN_PAGE_ERROR (C0000006) is a rare exception. π₯π΄π In fact, its chief weapon is surprise!
- Some situations when you can see it:
- * Executable image was mapped over the network; app tried to access currently missing page, but network got unplugged.
- * The app run from a removable media; user removed the media, then app accessed some absent page. [Note both network
- and removable media failures can be mitigated by special PE header flags, forcing full load and pagefile use later].
- * App used Jonas Lyk rad :bbq self-deletion method; then OS dropped some image pages (to read 'em from the image later);
- app accesses absent page with no file to read it from. [You've used the method and didn't know that could happen? Ha!]
- * Disk read failed for some reason.
- Now, what is the low-level sequence for in-page error? Let's see abridged flow for x64 (for ARM64 it's similar anyway).
- 1. CPU executes code which causes it to access a memory page with bit PTE.Valid == 0.
- 2. Page fault happens (#PF). Windows pagefault handler is nt!KiPageFault. That's very low-level function, written
- in assembly. It's also quite small, and delegates real fault resolution work to high-level func nt!MmAccessFault.
- 3. MmAccessFault attempts to resolves the fault. In most cases it's a soft pagefault (so its job is "PTE.Valid := 1"),
- but sometimes it's a hard pagefault, requiring data reading from disk/network. In any case, MmAccessFault returns
- NTSTATUS to KiPageFault. Succeeded? All good, continue execution. Failed? KiPageFault invokes KiExceptionDispatch.
- 4. KiExceptionDispatch is a low-level function, invoked from multiple fault handlers; arguments:
- ecx: exception code (for KiPageFault its derived from the code MmAccessFault returned); edx: number of extra args;
- r8: exception address (rip of the faulting instruction); r9, r10, r11: extra args.
- Of course, all that info is not that important, but it helps to know the details when looking at π§¨".exr XXX" output.
- If you check KiPageFault disasm, you'll see it discerns only like 5 error codes from MmAccessFault. For codes it doesn't
- know/care about, it simply sets KiExceptionDispatch ecx arg (the error code) to C0000006 (STATUS_IN_PAGE_ERROR). The
- orig error code from MmAccessFault is still retained as the third extra argument for KiExceptionDispatch (in r11).
- π What it means: the status we really need to examine is in the extra xarg3: π C000000E, STATUS_NO_SUCH_DEVICE.
- β¨β¨β¨β¨β¨β¨β¨β¨
- π½ Let's check π° context/disasm around the faulting instruction, along with the π₯ callstack.
- 2: kd> .cxr 0xffffe509f8198de0 π½π°
- rax=fffff801144d1080 rbx=ffffd3011992f000 rcx=ffffd3011992f000
- rdx=ffffd3011992f000 rsi=0000000000000002 rdi=0000027e296ab9f0
- rip=fffff801144d10d0 rsp=ffffe509f81997e8 rbp=0000027e296ab9af
- r8=0000027e296ab9f0 r9=0000000000000015 r10=ffffd3011992fea0
- r11=0000027e296aba05 r12=ffffe509f8199a58 r13=ffffb005ee4ef000
- r14=ffffd30119930000 r15=0000000000000000
- iopl=0 nv up ei pl zr na po nc
- cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00050246
- nt!RtlDecompressBufferXpressLz+0x50:
- fffff801`144d10d0 418b08 mov ecx,dword ptr [r8] ds:002b:0000027e`296ab9f0=????????
- π½ ^^ That's the CONTEXT record OS helpfully saved at the time of exception.
- Note ".cxr XXX" command doesn't just display the context, it actually sets ("activates") it for the debugger. Thus
- subsequent commands (like "k" would use this context, and not the real CPU context).
- β¨β¨β¨
- π½ Continue by quickly checking the disasm around the faulted "mov ecx, [r8]" instruction.
- Huge 0x0E-byte nop right before: faulted instruction is at the start of a cycle. Nothing stands out so far.
- 2: kd> ub . L7 π½ Unassemble Backward from current point ("."), Length: 7 instructions
- nt!RtlDecompressBufferXpressLz+0x2b:
- fffff801`144d10ae 458bd9 mov r11d,r9d
- fffff801`144d10b1 4d03d8 add r11,r8
- fffff801`144d10b4 4533ff xor r15d,r15d
- fffff801`144d10b7 4d8d96a0feffff lea r10,[r14-160h]
- fffff801`144d10be 498d6baa lea rbp,[r11-56h]
- fffff801`144d10c2 0f1f4000 nop dword ptr [rax]
- fffff801`144d10c6 66660f1f840000000000 nop word ptr [rax+rax]
- 2: kd> u . L3
- nt!RtlDecompressBufferXpressLz+0x50:
- fffff801`144d10d0 418b08 mov ecx,dword ptr [r8]
- fffff801`144d10d3 4983c004 add r8,4
- fffff801`144d10d7 493bd2 cmp rdx,r10
- β¨β¨β¨
- π½ Overview the π₯ callstack at the time of fault.
- 2: kd> k π½π₯
- *** Stack trace for last set context - .thread/.cxr resets it
- # Child-SP RetAddr Call Site
- 00 ffffe509`f81997e8 fffff801`144a6bf0 nt!RtlDecompressBufferXpressLz+0x50
- 01 ffffe509`f8199800 fffff801`144a6938 nt!RtlDecompressBufferEx+0x60
- 02 ffffe509`f8199850 fffff801`144a67c5 nt!ST_STORE<SM_TRAITS>::StDmSinglePageCopy+0x150
- 03 ffffe509`f8199910 fffff801`144a5ffc nt!ST_STORE<SM_TRAITS>::StDmSinglePageTransfer+0xa5
- 04 ffffe509`f8199960 fffff801`144a5e2c nt!ST_STORE<SM_TRAITS>::StDmpSinglePageRetrieve+0x180
- 05 ffffe509`f8199a00 fffff801`144a5c79 nt!ST_STORE<SM_TRAITS>::StDmPageRetrieve+0xc8
- 06 ffffe509`f8199ab0 fffff801`144a5b31 nt!SMKM_STORE<SM_TRAITS>::SmStDirectReadIssue+0x85
- 07 ffffe509`f8199b30 fffff801`14498bc8 nt!SMKM_STORE<SM_TRAITS>::SmStDirectReadCallout+0x21
- 08 ffffe509`f8199b60 fffff801`144a368f nt!KeExpandKernelStackAndCalloutInternal+0x78
- 09 ffffe509`f8199bd0 fffff801`14559934 nt!SMKM_STORE<SM_TRAITS>::SmStDirectRead+0xc7
- 0a ffffe509`f8199ca0 fffff801`14559368 nt!SMKM_STORE<SM_TRAITS>::SmStWorkItemQueue+0x1ac
- 0b ffffe509`f8199cf0 fffff801`144a4117 nt!SMKM_STORE_MGR<SM_TRAITS>::SmIoCtxQueueWork+0xc0
- 0c ffffe509`f8199d80 fffff801`144fa96b nt!SMKM_STORE_MGR<SM_TRAITS>::SmPageRead+0x167
- 0d ffffe509`f8199df0 fffff801`1445e0a0 nt!SmPageRead+0x33
- 0e ffffe509`f8199e40 fffff801`1445bb4d nt!MiIssueHardFaultIo+0x10c
- 0f ffffe509`f8199e90 fffff801`14528278 nt!MiIssueHardFault+0x29d
- 10 ffffe509`f8199f50 fffff801`1442a4d2 nt!MmAccessFault+0x468 π½π¦ "fake" fault (described below)
- 11 ffffe509`f819a0f0 fffff801`14460836 nt!MiDeleteSubsectionPages+0x172
- 12 ffffe509`f819a1b0 fffff801`14808d56 nt!MiDeleteSegmentPages+0x56
- 13 ffffe509`f819a210 fffff801`14584a89 nt!MiSegmentDelete+0x92
- 14 ffffe509`f819a260 fffff801`145ba179 nt!MiProcessDereferenceList+0xc1
- 15 ffffe509`f819a320 fffff801`144f53b5 nt!MiDereferenceSegmentThread+0x129
- 16 ffffe509`f819a550 fffff801`145fe278 nt!PspSystemThreadStartup+0x55
- 17 ffffe509`f819a5a0 00000000`00000000 nt!KiStartSystemThread+0x28
- β¨β¨β¨
- π½ But let's reset the debugger context using argless ".cxr" and overview the π₯ callstack again.
- All frame numbers we reference below would be for *this* callstack rather than the partial one above.
- 2: kd> .cxr π½ reset the debugger context
- 2: kd> k π½π₯
- # Child-SP RetAddr Call Site
- 00 ffffe509`f8198568 fffff801`14794dee nt!KeBugCheckEx π½π¦
- 01 ffffe509`f8198570 fffff801`14610023 nt!SMKM_STORE<SM_TRAITS>::SmStUnhandledExceptionFilter+0x7e
- 02 ffffe509`f81985c0 fffff801`145cca4f nt!`SMKM_STORE<SM_TRAITS>::SmStDirectReadIssue'::`1'::filt$0+0x22 π½π’
- 03 ffffe509`f81985f0 fffff801`145ffadf nt!_C_specific_handler+0x9f
- 04 ffffe509`f8198660 fffff801`14487547 nt!RtlpExecuteHandlerForException+0xf
- 05 ffffe509`f8198690 fffff801`14486136 nt!RtlDispatchException+0x297
- 06 ffffe509`f8198db0 fffff801`14608cac nt!KiDispatchException+0x186
- 07 ffffe509`f8199470 fffff801`14604e43 nt!KiExceptionDispatch+0x12c
- 08 ffffe509`f8199650 fffff801`144d10d0 nt!KiPageFault+0x443 π½π called "real" MmAccessFault (it has returned)
- 09 ffffe509`f81997e8 fffff801`144a6bf0 nt!RtlDecompressBufferXpressLz+0x50 π½π₯
- 0a ffffe509`f8199800 fffff801`144a6938 nt!RtlDecompressBufferEx+0x60
- 0b ffffe509`f8199850 fffff801`144a67c5 nt!ST_STORE<SM_TRAITS>::StDmSinglePageCopy+0x150
- 0c ffffe509`f8199910 fffff801`144a5ffc nt!ST_STORE<SM_TRAITS>::StDmSinglePageTransfer+0xa5
- 0d ffffe509`f8199960 fffff801`144a5e2c nt!ST_STORE<SM_TRAITS>::StDmpSinglePageRetrieve+0x180
- 0e ffffe509`f8199a00 fffff801`144a5c79 nt!ST_STORE<SM_TRAITS>::StDmPageRetrieve+0xc8
- 0f ffffe509`f8199ab0 fffff801`144a5b31 nt!SMKM_STORE<SM_TRAITS>::SmStDirectReadIssue+0x85 π½π’
- 10 ffffe509`f8199b30 fffff801`14498bc8 nt!SMKM_STORE<SM_TRAITS>::SmStDirectReadCallout+0x21
- 11 ffffe509`f8199b60 fffff801`144a368f nt!KeExpandKernelStackAndCalloutInternal+0x78
- 12 ffffe509`f8199bd0 fffff801`14559934 nt!SMKM_STORE<SM_TRAITS>::SmStDirectRead+0xc7
- 13 ffffe509`f8199ca0 fffff801`14559368 nt!SMKM_STORE<SM_TRAITS>::SmStWorkItemQueue+0x1ac
- 14 ffffe509`f8199cf0 fffff801`144a4117 nt!SMKM_STORE_MGR<SM_TRAITS>::SmIoCtxQueueWork+0xc0
- 15 ffffe509`f8199d80 fffff801`144fa96b nt!SMKM_STORE_MGR<SM_TRAITS>::SmPageRead+0x167
- 16 ffffe509`f8199df0 fffff801`1445e0a0 nt!SmPageRead+0x33
- 17 ffffe509`f8199e40 fffff801`1445bb4d nt!MiIssueHardFaultIo+0x10c
- 18 ffffe509`f8199e90 fffff801`14528278 nt!MiIssueHardFault+0x29d
- 19 ffffe509`f8199f50 fffff801`1442a4d2 nt!MmAccessFault+0x468 π½π¦ "fake" fault (described below)
- 1a ffffe509`f819a0f0 fffff801`14460836 nt!MiDeleteSubsectionPages+0x172
- 1b ffffe509`f819a1b0 fffff801`14808d56 nt!MiDeleteSegmentPages+0x56
- 1c ffffe509`f819a210 fffff801`14584a89 nt!MiSegmentDelete+0x92
- 1d ffffe509`f819a260 fffff801`145ba179 nt!MiProcessDereferenceList+0xc1 π½ποΈ
- 1e ffffe509`f819a320 fffff801`144f53b5 nt!MiDereferenceSegmentThread+0x129
- 1f ffffe509`f819a550 fffff801`145fe278 nt!PspSystemThreadStartup+0x55
- 20 ffffe509`f819a5a0 00000000`00000000 nt!KiStartSystemThread+0x28
- π½ ^^ So far so good. We see RtlDecompressBufferXpressLz at frame 9 tried to access page with PTE.Valid == 0, which
- caused #PF; CPU consulted its Interrupt Descriptor Table to find the #PF handler, which is KiPageFault. As previously
- noted, KiPageFault invoked MmAccessFault to handle the fault, but that failed with STATUS_NO_SUCH_DEVICE (C000000E).
- [Ofc MmAccessFault has already returned and thus absent in the callstack; the one you see at frame 0x19 is different].
- So KiPageFault invoked KiExceptionDispatch, which tried to dispatch the exception using SEH frames. It so happened
- π’ SmStDirectReadIssue at frame 0x0F had SEH frame (try-except) block, with quite simple exception filter (frame 2).
- I wouldn't normally decompile bugchecked func in such simple cases, but let's do it for a better overview.
- I've used ntoskrnl.exe of similar build, but you can use the exact version - windbg should have already downloaded the
- exact bin from the MS symbol server and saved it to your symstore (defined by _NT_SYMBOL_PATH envar). Example location:
- C:\stuff\symbols\ms\ntkrnlmp.exe\05C0E3E01046000\ntkrnlmp.exe; `05C0E3E0` is PE.timestamp, [0]1046000 is PE.SizeOfImage.
- If for some reason binary wasn't downloaded yet, you can force download using `!chkimg` command, e.g. `!chkimg nt`.
- ```
- // function with SEH, frame 0x0F π½π’
- NTSTATUS SMKM_STORE<SM_TRAITS>::SmStDirectReadIssue(...)
- {
- ...
- __try
- {
- ...
- // in this case π₯ RtlDecompressBufferXpressLz (frame 9) gets invoked eventually, and Page Fault happens
- ...
- }
- __except(this->SmStUnhandledExceptionFilter(GetExceptionPointers(), FaultingFunc=2`SmStDirectReadIssue))
- {
- NOTHING;
- }
- ...
- }
- // entire func which invoked KeBugCheckEx, frame 0x02 π½π’; used as filter from 4 different "FaultingFunc" methods
- int SMKM_STORE<SM_TRAITS>::SmStUnhandledExceptionFilter(this, EXCEPTION_POINTERS* ExceptionPointers, int FaultingFunc)
- {
- if (FaultingFunc == 1`SmStWorkerThread) // only process it if faulting func is SmStWorkerThread (not our case)
- {
- int exceptionCode = ExceptionPointers->ExceptionRecord->ExceptionCode;
- if (exceptionCode == 0xC0000005`STATUS_ACCESS_VIOLATION || exceptionCode == 0xC0000420`STATUS_ASSERTION_FAILURE)
- {
- __try
- {
- SmHpChunkHeapProtect(this + 0x110, 2);
- }
- __except(EXCEPTION_EXECUTE_HANDLER)
- {
- NOTHING;
- }
- }
- }
- if (ExceptionPointers) // that's always true
- KeBugCheckEx(0x154, this, ExceptionPointers, FaultingFunc, 0); π½π¦ bugcheck Arg3 π½β mystery revealed
- return EXCEPTION_CONTINUE_SEARCH; // that's never executed
- }
- ```
- π½ ^^ That's actually really weird exception filter. Normally neither user nor kernel code should be written like that.
- IDA shows the filter is used in 4 different places, and in all cases it tries to catch/eat all exceptions, w/o giving
- higher-level components chance to handle them. Well, that's probably okay (it enriches the bugcheck with 'this' pointer,
- i.e. address of the SMKM_STORE object); but filter tries to process certain fails using SmHpChunkHeapProtect, yet it
- still invokes KeBugCheckEx basically unconditionally! And returns EXCEPTION_CONTINUE_SEARCH as if it handled nothing.
- π The exception filter seems like a wreckorama, but it's not the BSOD root cause. Continue investigation.
- β¨β¨β¨β¨β¨β¨β¨β¨
- π½ We need the faulting βοΈ process name for a better reflection.
- 2: kd> !process -1 0 π½βοΈ using "-1" to display current process
- PROCESS ffffb005e91bc040
- SessionId: none Cid: 0c0c Peb: 00000000 ParentCid: 0004
- DirBase: 1a7f49000 ObjectTable: ffff9c894d4f4500 HandleCount: 0.
- Image: MemCompression βοΈβοΈβοΈ
- 2: kd> ?? @$proc->Minimal π½ current EPROCESS.Minimal == 1
- unsigned long 1
- β¨β¨β¨β¨β¨β¨β¨β¨
- π½ Okay, CPU was running kernelmode code in the context of the MemCompression process. What is that process?
- You guessed it: the MemCompression process is a process which compresses memory! π€―
- It is a *Minimal* process: a real process with its own address space. Its usermode virtual address space part is
- separate from the System process (different KPROCESS.DirectoryTableBase, aka DirBase, aka CR3 register).
- Since it's a Minimal process, it doesn't have the usual usermode stuff, like mapped ntdll, KUSER_SHARED_DATA, or PEB.
- The MS assumption is that it's faster to decompress a page than to read it from disk. However, it's not that simple and
- is not always an easy win. In case of disk read the CPU is free to do something else while disk device reads data, while
- decompression is intense on CPU usage/power/cache. There are also no transition pages parallel to compressed ones (as
- that'll just increase the RAM usage), so no fast/soft pagefaults for compressed pages, sometimes making them... slower?
- But it does save memory, and still is a win in many scenarios (just not in all of them). Also note the beauty:
- compressed data itself can be paged out to disk.
- You can read a bit more about memory compression in Windows Internals, "Memory compression" section. But there's
- more: see "2019.Extracting Compressed Pages from the Windows 10 Virtual Store.Sardar.[MemCompression].pdf".
- β¨β¨β¨
- π½ So, what was the kernel thread in the context of MemCompression doing anyway?
- Here's the duplicated callstack portion, to avoid wearing down the encoder of your mouse scrollwheel:
- 00 ffffe509`f8198568 fffff801`14794dee nt!KeBugCheckEx
- ...
- 08 ffffe509`f8199650 fffff801`144d10d0 nt!KiPageFault+0x443
- 09 ffffe509`f81997e8 fffff801`144a6bf0 nt!RtlDecompressBufferXpressLz+0x50 π½π₯
- 0a ffffe509`f8199800 fffff801`144a6938 nt!RtlDecompressBufferEx+0x60
- 0b ffffe509`f8199850 fffff801`144a67c5 nt!ST_STORE<SM_TRAITS>::StDmSinglePageCopy+0x150
- ...
- 16 ffffe509`f8199df0 fffff801`1445e0a0 nt!SmPageRead+0x33
- 17 ffffe509`f8199e40 fffff801`1445bb4d nt!MiIssueHardFaultIo+0x10c
- 18 ffffe509`f8199e90 fffff801`14528278 nt!MiIssueHardFault+0x29d
- 19 ffffe509`f8199f50 fffff801`1442a4d2 nt!MmAccessFault+0x468 π½π¦ "fake" fault (described below)
- 1a ffffe509`f819a0f0 fffff801`14460836 nt!MiDeleteSubsectionPages+0x172
- 1b ffffe509`f819a1b0 fffff801`14808d56 nt!MiDeleteSegmentPages+0x56
- 1c ffffe509`f819a210 fffff801`14584a89 nt!MiSegmentDelete+0x92
- 1d ffffe509`f819a260 fffff801`145ba179 nt!MiProcessDereferenceList+0xc1 π½ποΈ
- 1e ffffe509`f819a320 fffff801`144f53b5 nt!MiDereferenceSegmentThread+0x129
- 1f ffffe509`f819a550 fffff801`145fe278 nt!PspSystemThreadStartup+0x55
- 20 ffffe509`f819a5a0 00000000`00000000 nt!KiStartSystemThread+0x28
- π½ From the looks of it, thread was... Deleting a segment? I.e. deleting a section object, I guess?
- But is that right? Why would MemCompression process would be deleting a segment? Ah, of course. Let's see:
- β¨β¨β¨
- 2: kd> !thread -1 π½ using "-1" to display current thread
- THREAD ffffb005df2c8480 Cid 0004.01c0 Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 2
- Not impersonating
- Owning Process ffffb005c509f100 Image: System π½ thread reallly belongs to System, but
- Attached Process ffffb005e91bc040 Image: MemCompression π½ was KeStackAttach'd to MemCompression
- Wait Start TickCount 37292117 Ticks: 78 (0:00:00:01.218)
- Context Switch Count 8329 IdealProcessor: 3
- UserTime 00:00:00.000
- KernelTime 00:00:03.328
- Win32 Start Address nt!MiDereferenceSegmentThread (0xfffff801145ba050)
- Stack Init ffffe509f819a5d0 Current ffffe509f8198ef0
- Base ffffe509f819b000 Limit ffffe509f8194000 Call 0000000000000000
- Priority 19 BasePriority 8 IoPriority 2 PagePriority 5
- β¨β¨β¨
- So yeah, it makes more sense now. Thread in the System process was deleting a section object, and simply attached the
- address space to the MemCompression process at certain point. If you were working at Microsoft at the time, you might
- have seen evil internal memos: memory compression was too good, so to force users to upgrade their hardware Microsoft
- slowed it down by separating it into own process (to incur more TLB flushes). Same with the Registry process, btw.
- π½ Anyway, at certain point thread issued a fake/manual π½π¦ MmAccessFault (frame 0x1A to 0x19).
- That looks a bit sus, let's verify:
- β¨β¨β¨
- 2: kd> .cxr π½ reset the debugger context, just in case
- 2: kd> .frame /c /r 1A π½ perform virtual unwind to frame 0x1A
- 1a ffffe509`f819a0f0 fffff801`14460836 nt!MiDeleteSubsectionPages+0x172
- rax=fffff801144d1080 rbx=0000000000000000 rcx=ffffd3011992f000 π½ it is NOT a full context: we asked debugger to do
- rdx=ffffd3011992f000 rsi=ffff9c894f503000 rdi=ffffe509f819a218 π½ a Virtual Unwind using ".frame /c /r #", so only
- rip=fffff8011442a4d2 rsp=ffffe509f819a0f0 rbp=0000000000000000 π½ NON-volatile regs are valid; there's no way to
- r8=0000027e296ab9f0 r9=0000000000000015 r10=ffffd3011992fea0 π½ restore volatile regs like rax, so debugger has
- r11=0000027e296aba05 r12=0000000000000000 r13=ffffb005f0086010 π½ set them to values from in the closest TrapFrame,
- r14=0000000000000000 r15=0000000000000000 π½ address of which can be seen with "kv" command
- iopl=0 nv up ei pl zr na po nc
- cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00040246
- nt!MiDeleteSubsectionPages+0x172:
- fffff801`1442a4d2 eb90 jmp nt!MiDeleteSubsectionPages+0x104 (fffff801`1442a464)
- β¨β¨β¨
- 2: kd> ub . LD π½ check disasm (Unassemble Backwards), 0xD opcodes
- nt!MiDeleteSubsectionPages+0x145:
- fffff801`1442a4a5 a802 test al,2
- fffff801`1442a4a7 752b jne nt!MiDeleteSubsectionPages+0x174 (fffff801`1442a4d4)
- fffff801`1442a4a9 488d9424d0000000 lea rdx,[rsp+0D0h]
- fffff801`1442a4b1 488bce mov rcx,rsi π½ rcx: address of proto _MMPTE
- fffff801`1442a4b4 e827faffff call nt!MiLockProtoPoolPage (fffff801`14429ee0) π½π this failed ->...
- fffff801`1442a4b9 488be8 mov rbp,rax π½ rax: address of locked _MMPFN
- fffff801`1442a4bc 4885c0 test rax,rax π½ (but this func failed: rax==0)
- fffff801`1442a4bf 7531 jne nt!MiDeleteSubsectionPages+0x192 (fffff801`1442a4f2)
- fffff801`1442a4c1 4533c9 xor r9d,r9d
- fffff801`1442a4c4 8d4802 lea ecx,[rax+2] π½ ecx: 2, MiFaultWrite
- fffff801`1442a4c7 4533c0 xor r8d,r8d
- fffff801`1442a4ca 488bd6 mov rdx,rsi π½ rdx: address of proto _MMPTE
- fffff801`1442a4cd e83ed90f00 call nt!MmAccessFault (fffff801`14527e10) π½π¦
- π½ ^^ What do you know? In this case we can easily reconstruct all four args to the "fake" π½π¦ MmAccessFault, just
- from this tiny disasm snippet and unwound non-volatile regs alone. [Well, strictly speaking we might need more than this
- disasm, but if you issue "uf nt!MiDeleteSubsectionPages" (Unassemble Function), you'll see basic blocks are in order].
- ππ½π¦ MmAccessFault(FaultStatus=MiFaultWrite`2, VirtualAddress=ffff9c894f503000, PreviousMode=Kernel, TrapInfo=null).
- π½ As noted in the snippet comments above, the MiLockProtoPoolPage intakes address of the prototype PTE (_MMPTE), and
- returns address of the corresponding _MMPFN, now locked. But in this case MiLockProtoPoolPage failed, returning null.
- That's a normal situation, e.g. it can happen if *address* of the proto PTE itself is not valid (or proto PTE is in
- copy-on-write memory). To resolve that, oskernel invokes π½π¦ MmAccessFault() to basically page-in the prototype PTE.
- cyra> Do you want me to show what section was being deleted?
- π½ As you'll see shortly, the section being deleted is not that relevat, but just for kicks let's check section info.
- β¨β¨β¨
- 2: kd> .frame /c /r 1d π½ποΈ do virtual unwind to frame 0x1D
- 1d ffffe509`f819a260 fffff801`145ba179 nt!MiProcessDereferenceList+0xc1
- rax=fffff801144d1080 rbx=0000000000000000 rcx=ffffd3011992f000 π½ got valid non-volatile regs
- rdx=ffffd3011992f000 rsi=ffffb005f0086018 rdi=fffff80114e50b00
- rip=fffff80114584a89 rsp=ffffe509f819a260 rbp=ffffe509f819a2e0
- r8=0000027e296ab9f0 r9=0000000000000015 r10=ffffd3011992fea0
- r11=0000027e296aba05 r12=000000000000031f r13=fffff80114e51040
- r14=0000000000000000 r15=fffff80114e51110
- iopl=0 nv up ei pl zr na po nc
- cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00040246
- nt!MiProcessDereferenceList+0xc1:
- fffff801`14584a89 498bcd mov rcx,r13
- 2: kd> ub . L2 π½ disasm around the call
- nt!MiProcessDereferenceList+0xb8:
- fffff801`14584a80 488d4ef8 lea rcx,[rsi-8] π½ποΈ rcx: address of _CONTROL_AREA
- fffff801`14584a84 e83b422800 call nt!MiSegmentDelete
- π½ ^^ Again, it was very easy to find out the argument [for the MiSegmentDelete]. Sometimes it's not that easy, and you
- gotta check multiple frames, or do some very hard add/sub math to find stack slot location for the spilled argument.
- π½ Argument info for MiSgmentDelete was in my training set, so I know the first argument is pointer to _CONTROL_AREA.
- Let's assign it to $t0 pseudo-register for later use; go with C++ syntax (with type info) via "r?" instead of plain "r".
- β¨β¨β¨
- 2: kd> r?$t0=(nt!_control_area*)(@rsi-8) π½ποΈ use non-vol rsi, not rcx
- 2: kd> ?? @$t0 π½ and dump the CONTROL_AREA immediately
- struct _CONTROL_AREA * 0xffffb005`f0086010
- +0x000 Segment : 0xffff9c89`6570e840 _SEGMENT
- +0x008 ListHead : _LIST_ENTRY [ 0xffffb005`f0086018 - 0xffffb005`f0086018 ]
- +0x008 AweContext : 0xffffb005`f0086018 Void
- +0x018 NumberOfSectionReferences : 0
- +0x020 NumberOfPfnReferences : 0
- +0x028 NumberOfMappedViews : 0
- +0x030 NumberOfUserReferences : 0
- +0x038 u : <anonymous-tag> π½π±οΈ click this link
- +0x03c u1 : <anonymous-tag>
- +0x040 FilePointer : _EX_FAST_REF π½ποΈ +40, CONTROL_AREA.FilePointer
- +0x048 ControlAreaLock : 0n0
- +0x04c ModifiedWriteCount : 0
- +0x050 WaitList : (null)
- +0x058 u2 : <anonymous-tag>
- +0x068 FileObjectLock : _EX_PUSH_LOCK
- +0x070 LockedPages : 1
- +0x078 u3 : <anonymous-tag>
- π½ ^^ You don't see it here, but a lot of members above are actually clickable links in Windbg. So don't freak out
- by the couple of commands below, I've just clicked the links to "enter" them.
- β¨β¨β¨
- 2: kd> dx -id 0,0,ffffb005e91bc040 -r1 (*((ntkrnlmp!_CONTROL_AREA *)0xffffb005f0086010)).u π½π±οΈ clicked "u" above
- (*((ntkrnlmp!_CONTROL_AREA *)0xffffb005f0086010)).u [Type: <anonymous-tag>]
- [+0x000] LongFlags : 0x800a1 [Type: unsigned long]
- [+0x000] Flags [Type: _MMSECTION_FLAGS] π½π±οΈ clicked this link
- 2: kd> dx -id 0,0,ffffb005e91bc040 -r1 (*((ntkrnlmp!_MMSECTION_FLAGS *)0xffffb005f0086048)) π½ got _MMSECTION_FLAGS
- (*((ntkrnlmp!_MMSECTION_FLAGS *)0xffffb005f0086048)) [Type: _MMSECTION_FLAGS]
- [+0x000 ( 0: 0)] BeingDeleted : 0x1 [Type: unsigned int] π½ correct, the section is being deleted!
- [+0x000 ( 1: 1)] BeingCreated : 0x0 [Type: unsigned int]
- [+0x000 ( 2: 2)] BeingPurged : 0x0 [Type: unsigned int]
- [+0x000 ( 3: 3)] NoModifiedWriting : 0x0 [Type: unsigned int]
- [+0x000 ( 4: 4)] FailAllIo : 0x0 [Type: unsigned int]
- [+0x000 ( 5: 5)] Image : 0x1 [Type: unsigned int] π½ it's an image section (exe/dll)
- [+0x000 ( 6: 6)] Based : 0x0 [Type: unsigned int]
- [+0x000 ( 7: 7)] File : 0x1 [Type: unsigned int]
- [+0x000 ( 8: 8)] AttemptingDelete : 0x0 [Type: unsigned int]
- [+0x000 ( 9: 9)] PrefetchCreated : 0x0 [Type: unsigned int]
- [+0x000 (10:10)] PhysicalMemory : 0x0 [Type: unsigned int]
- [+0x000 (11:11)] ImageControlAreaOnRemovableMedia : 0x0 [Type: unsigned int]
- [+0x000 (12:12)] Reserve : 0x0 [Type: unsigned int]
- [+0x000 (13:13)] Commit : 0x0 [Type: unsigned int]
- [+0x000 (14:14)] NoChange : 0x0 [Type: unsigned int]
- [+0x000 (15:15)] WasPurged : 0x0 [Type: unsigned int]
- [+0x000 (16:16)] UserReference : 0x0 [Type: unsigned int]
- [+0x000 (17:17)] GlobalMemory : 0x0 [Type: unsigned int]
- [+0x000 (18:18)] DeleteOnClose : 0x0 [Type: unsigned int]
- [+0x000 (19:19)] FilePointerNull : 0x1 [Type: unsigned int]
- [+0x000 (25:20)] PreferredNode : 0x0 [Type: unsigned long]
- [+0x000 (26:26)] GlobalOnlyPerSession : 0x0 [Type: unsigned int]
- [+0x000 (27:27)] UserWritable : 0x0 [Type: unsigned int]
- [+0x000 (28:28)] SystemVaAllocated : 0x0 [Type: unsigned int]
- [+0x000 (29:29)] PreferredFsCompressionBoundary : 0x0 [Type: unsigned int]
- [+0x000 (30:30)] UsingFileExtents : 0x0 [Type: unsigned int]
- [+0x000 (31:31)] PageSize64K : 0x0 [Type: unsigned int]
- 2: kd> dq @@(&@$t0->FilePointer) L1 π½ποΈ +40, CONTROL_AREA.FilePointer
- ffffb005`f0086050 ffffb005`f611bcd6
- π½ CONTROL_AREA.FilePointer is actually EX_FAST_REF (pointer-with-embedded-refcount), so align it down by 0x10
- 2: kd> r?$t1=(nt!_file_object*)(@$p&-0x10) π½ use @$p to access the last db/dw/dd/dq value
- 2: kd> !fileobj @$t1 π½ or we could've used "?? @$t1" for entire struct
- \Program Files\WindowsApps\Microsoft.OneConnect_5.2011.3081.0_x64__8wekyb3d8bbwe\OneConnect.dll π
- Device Object: 0xffffb005cc3f1c00 \Driver\volmgr π½ ^^^ got filepath
- Vpb: 0xffffb005cc3d5cd0
- Access: Read SharedRead SharedDelete π½ ...got share access
- Flags: 0x44042 π½ ...and got decoded flags
- Synchronous IO
- Cache Supported
- Cleanup Complete
- Handle Created
- FsContext: 0xffff9c8959df69f0 FsContext2: 0xffff9c8967d8c640
- CurrentByteOffset: 0
- Cache Data:
- Section Object Pointers: ffffb005f90731d8
- Shared Cache Map: 00000000
- π½ Now we know the filepath for the section which was being deleted! That's very nice.
- Just think how useful it is! Well, for this analysis it's absolutely useless. Hahaha.
- π½ Since we've already sidetracked a bit, let's also check something else related to section objects.
- Right beyond the _CONTROL_AREA for section image there's a subsection (not a coincidence, it's designed that way).
- Or rather, there are multiple subsections: one for the file header (MZ header), and one for each image section.
- Let's display subsection for the file header (with MZ signature):
- β¨β¨β¨
- 2: kd> dt _subsection @@(@$t0+1) π½ C++ expression: right after the CONTROL_AREA
- nt!_SUBSECTION
- +0x000 ControlArea : 0xffffb005`f0086010 _CONTROL_AREA π½ points back to the CONTROL_AREA in $t0
- +0x008 SubsectionBase : 0xffff9c89`4f503000 _MMPTE π½ππ ptr to an array of π1 (one) prototype PTEs
- +0x010 NextSubsection : 0xffffb005`f00860c8 _SUBSECTION π½π±οΈ click this link
- +0x018 GlobalPerSessionHead : _RTL_AVL_TREE
- +0x018 CreationWaitList : (null)
- +0x018 SessionDriverProtos : (null)
- +0x020 u : <anonymous-tag>
- +0x024 StartingSector : 0
- +0x028 NumberOfFullSectors : 3 π½ 3 disk sectors for file header
- +0x02c PtesInSubsection : 1 π½π 1 PTE (1 page) for the file header
- +0x030 u1 : <anonymous-tag>
- +0x034 UnusedPtes : 0y000000000000000000000000000000 (0)
- +0x034 ExtentQueryNeeded : 0y0
- +0x034 DirtyPages : 0y0
- π½π±οΈ Clicked link right above. It's actually just an array of _SUBSECTION structs. This one is for the first PE section.
- 2: kd> dx -id 0,0,ffffb005e91bc040 -r1 ((ntkrnlmp!_SUBSECTION *)0xffffb005f00860c8)
- ((ntkrnlmp!_SUBSECTION *)0xffffb005f00860c8) : 0xffffb005f00860c8 [Type: _SUBSECTION*]
- [+0x000] ControlArea : 0xffffb005f0086010 [Type: _CONTROL_AREA*]
- [+0x008] SubsectionBase : 0xffff9c894f503008 [Type: _MMPTE*] π½ ptr to an array of π 0x4C3 prototype PTEs
- [+0x010] NextSubsection : 0xffffb005f0086100 [Type: _SUBSECTION*] π½ the last subsection will have null there
- [+0x018] GlobalPerSessionHead [Type: _RTL_AVL_TREE]
- [+0x018] CreationWaitList : 0x0 [Type: _MI_CONTROL_AREA_WAIT_BLOCK *]
- [+0x018] SessionDriverProtos : 0x0 [Type: _MI_PER_SESSION_PROTOS *]
- [+0x020] u [Type: <anonymous-tag>]
- [+0x024] StartingSector : 0x3 [Type: unsigned long]
- [+0x028] NumberOfFullSectors : 0x2612 [Type: unsigned long]
- [+0x02c] PtesInSubsection : 0x4c3 [Type: unsigned long] π½π 0x4C3 PTEs for the first PE section
- [+0x030] u1 [Type: <anonymous-tag>]
- [+0x034 (29: 0)] UnusedPtes : 0x0 [Type: unsigned long]
- [+0x034 (30:30)] ExtentQueryNeeded : 0x0 [Type: unsigned long]
- [+0x034 (31:31)] DirtyPages : 0x0 [Type: unsigned long]
- β¨β¨β¨
- Here's the relevant portion of the callstack:
- 18 ffffe509`f8199e90 fffff801`14528278 nt!MiIssueHardFault+0x29d
- 19 ffffe509`f8199f50 fffff801`1442a4d2 nt!MmAccessFault+0x468 π½π¦ "fake" fault
- 1a ffffe509`f819a0f0 fffff801`14460836 nt!MiDeleteSubsectionPages+0x172 π½ deref backing PFNs/pagefiles for subsection
- 1b ffffe509`f819a1b0 fffff801`14808d56 nt!MiDeleteSegmentPages+0x56 π½ deref backing PFNs/pagefiles
- 1c ffffe509`f819a210 fffff801`14584a89 nt!MiSegmentDelete+0x92 π½ deleting CONTROL_AREA 0xffffb005`f0086010
- Okay, let's reiterate once more. The segment (section object) was being deleted (frame 0x1C).
- As part of cleanup MiDeleteSegmentPages was invoked, which proceeded to call MiDeleteSubsectionPages for each
- SUBSECTION struct in the segment.
- We've just dumped two SUBSECTION structs: the one for the file MZ header, and the next one - for the first PE section.
- Job of MiDeleteSubsectionPages appears to dereference/cleanup backing PFNs/pagefiles of prototype PTEs.
- And it appears in certain situation the function may need to lock pages which contain the prototype PTEs; it does it
- via MiLockProtoPoolPage. In this case that function failed, forcing OS to issue MmAccessFault in order to make the PTE
- describing the prototype PTE valid.
- Here it is (line copypasted from above): vvv π½ππ vvv
- ππ½π¦ MmAccessFault(FaultStatus=MiFaultWrite`2, VirtualAddress=ffff9c894f503000, PreviousMode=Kernel, TrapInfo=null).
- As you can see, the address which ought to be accessed is the address of the prototype PTE for the file header.
- π½ Was MmAccessFault call really needed?
- β¨β¨β¨
- 2: kd> !pte ffff9c894f503000 π½π
- VA ffff9c894f503000
- PXE at FFFFFCFE7F3F99C8 PPE at FFFFFCFE7F339128 PDE at FFFFFCFE672253D0 PTE at FFFFFCCE44A7A818 π½π
- contains 0A0000047C068863 contains 0A0000047C069863 contains 0A000003CE6B8863 contains 00000003DBF30880
- pfn 47c068 ---DA--KWEV pfn 47c069 ---DA--KWEV pfn 3ce6b8 ---DA--KWEV not valid
- Transition: 3dbf30 π½π¦
- Protect: 4 - ReadWrite
- π½ ^^ Apparently yes - address π ffff9c894f503000 (which contains Prototype PTE) is not valid, because PTE which
- describes it has bit 0 cleared (the PTE 'Valid' bit). Windbg conveniently displayed the PFN - 0x3dbf30 π¦.
- But have you noticed there's tons of bugs today in πͺ³π¦Windbgπ?! We gotta verify the PTE/PFN manually, just in case:
- 2: kd> dt _mmpte . FFFFFCCE44A7A818 π½π
- nt!_MMPTE
- +0x000 u :
- +0x000 Long : 0x00000003`dbf30880
- +0x000 VolatileLong : 0x00000003`dbf30880
- +0x000 Hard : _MMPTE_HARDWARE
- +0x000 Proto : _MMPTE_PROTOTYPE π½π±οΈ click this link
- +0x000 Soft : _MMPTE_SOFTWARE
- +0x000 TimeStamp : _MMPTE_TIMESTAMP
- +0x000 Trans : _MMPTE_TRANSITION
- +0x000 Subsect : _MMPTE_SUBSECTION
- +0x000 List : _MMPTE_LIST
- 2: kd> dx -id 0,0,ffffb005e91bc040 -r1 (*((ntkrnlmp!_MMPTE_TRANSITION *)0xfffffcce44a7a818))
- (*((ntkrnlmp!_MMPTE_TRANSITION *)0xfffffcce44a7a818)) [Type: _MMPTE_TRANSITION]
- [+0x000 ( 0: 0)] Valid : 0x0 [Type: unsigned __int64]
- [+0x000 ( 1: 1)] Write : 0x0 [Type: unsigned __int64]
- [+0x000 ( 2: 2)] Spare : 0x0 [Type: unsigned __int64]
- [+0x000 ( 3: 3)] IoTracker : 0x0 [Type: unsigned __int64]
- [+0x000 ( 4: 4)] SwizzleBit : 0x0 [Type: unsigned __int64]
- [+0x000 ( 9: 5)] Protection : 0x4 [Type: unsigned __int64]
- [+0x000 (10:10)] Prototype : 0x0 [Type: unsigned __int64]
- [+0x000 (11:11)] Transition : 0x1 [Type: unsigned __int64] π½ yes, marked as transition
- [+0x000 (47:12)] PageFrameNumber : 0x3dbf30 [Type: unsigned __int64] π½π¦ yes, PFN was valid
- [+0x000 (63:48)] Unused : 0x0 [Type: unsigned __int64]
- 2: kd> !pfn 0x3dbf30 π½π¦
- PFN 003DBF30 at address FFFFEA000B93D900 π½π¦ got address of _mmpfn in PFN db
- flink 5FF1175C0 blink / share count 00000000 pteaddress FFFFFCCE44A7A818
- reference count 0001 used entry count 0000 Cached color 0 Priority 5
- restore pte 78D80700002084 containing page 3CE6B8 Standby R
- ReadInProgress
- 2: kd> dt _mmpfn FFFFEA000B93D900 π½π¦
- nt!_MMPFN
- +0x000 ListEntry : _LIST_ENTRY [ 0xffffb005`ff1175c0 - 0xfffffcce`44a7a818 ]
- +0x000 TreeNode : _RTL_BALANCED_NODE
- +0x000 u1 : <anonymous-tag>
- +0x008 PteAddress : 0xfffffcce`44a7a818 _MMPTE
- +0x008 PteLong : 0xfffffcce`44a7a818
- +0x010 OriginalPte : _MMPTE π½π±οΈ click this link
- +0x018 u2 : _MIPFNBLINK
- +0x020 u3 : <anonymous-tag>
- +0x024 NodeBlinkLow : 0xffff
- +0x026 Unused : 0y0000
- +0x026 Unused2 : 0y0000
- +0x027 ViewCount : 0x31 '1'
- +0x027 NodeFlinkLow : 0x31 '1'
- +0x027 ModifiedListBucketIndex : 0y0001
- +0x027 AnchorLargePageSize : 0y01
- +0x028 u4 : <anonymous-tag>
- 2: kd> dx -id 0,0,ffffb005e91bc040 -r1 (*((ntkrnlmp!_MMPTE *)0xffffea000b93d910))
- (*((ntkrnlmp!_MMPTE *)0xffffea000b93d910)) [Type: _MMPTE]
- [+0x000] u [Type: <anonymous-tag>] π½π±οΈ and click this
- 2: kd> dx -id 0,0,ffffb005e91bc040 -r1 (*((ntkrnlmp!_MMPTE *)0xffffea000b93d910)).u
- (*((ntkrnlmp!_MMPTE *)0xffffea000b93d910)).u [Type: <anonymous-tag>]
- [+0x000] Long : 0x78d80700002084 [Type: unsigned __int64]
- [+0x000] VolatileLong : 0x78d80700002084 [Type: unsigned __int64]
- [+0x000] Hard [Type: _MMPTE_HARDWARE]
- [+0x000] Proto [Type: _MMPTE_PROTOTYPE]
- [+0x000] Soft [Type: _MMPTE_SOFTWARE] π½π±οΈ this one we really want
- [+0x000] TimeStamp [Type: _MMPTE_TIMESTAMP]
- [+0x000] Trans [Type: _MMPTE_TRANSITION]
- [+0x000] Subsect [Type: _MMPTE_SUBSECTION]
- [+0x000] List [Type: _MMPTE_LIST]
- 2: kd> dx -id 0,0,ffffb005e91bc040 -r1 (*((ntkrnlmp!_MMPTE_SOFTWARE *)0xffffea000b93d910))
- (*((ntkrnlmp!_MMPTE_SOFTWARE *)0xffffea000b93d910)) [Type: _MMPTE_SOFTWARE]
- [+0x000 ( 0: 0)] Valid : 0x0 [Type: unsigned __int64]
- [+0x000 ( 1: 1)] PageFileReserved : 0x0 [Type: unsigned __int64]
- [+0x000 ( 2: 2)] PageFileAllocated : 0x1 [Type: unsigned __int64] π½
- [+0x000 ( 3: 3)] ColdPage : 0x0 [Type: unsigned __int64]
- [+0x000 ( 4: 4)] SwizzleBit : 0x0 [Type: unsigned __int64]
- [+0x000 ( 9: 5)] Protection : 0x4 [Type: unsigned __int64]
- [+0x000 (10:10)] Prototype : 0x0 [Type: unsigned __int64]
- [+0x000 (11:11)] Transition : 0x0 [Type: unsigned __int64]
- [+0x000 (15:12)] PageFileLow : 0x2 [Type: unsigned __int64] π½π aha, got pagefile number!
- [+0x000 (25:16)] UsedPageTableEntries : 0x0 [Type: unsigned __int64]
- [+0x000 (26:26)] ShadowStack : 0x0 [Type: unsigned __int64]
- [+0x000 (31:27)] Unused : 0x0 [Type: unsigned __int64]
- [+0x000 (63:32)] PageFileHigh : 0x78d807 [Type: unsigned __int64]
- β¨β¨β¨
- π½ Here's the relevant callstack, as we may need to check a few more things.
- 16 ffffe509`f8199df0 fffff801`1445e0a0 nt!SmPageRead+0x33
- 17 ffffe509`f8199e40 fffff801`1445bb4d nt!MiIssueHardFaultIo+0x10c
- 18 ffffe509`f8199e90 fffff801`14528278 nt!MiIssueHardFault+0x29d
- 19 ffffe509`f8199f50 fffff801`1442a4d2 nt!MmAccessFault+0x468
- β¨β¨β¨
- 2: kd> .cxr
- Resetting default scope
- 2: kd> .frame /c /r 18
- 18 ffffe509`f8199e90 fffff801`14528278 nt!MiIssueHardFault+0x29d
- rax=fffff801144d1080 rbx=0000000000000002 rcx=ffffd3011992f000
- rdx=ffffd3011992f000 rsi=ffffe509f819a048 rdi=ffffb005ff1175a0
- rip=fffff8011445bb4d rsp=ffffe509f8199e90 rbp=ffffe509f8199ed0
- r8=0000027e296ab9f0 r9=0000000000000015 r10=ffffd3011992fea0
- r11=0000027e296aba05 r12=ffffb005df2c8480 r13=ffffe509f819a010
- r14=0000000000000000 r15=0000000000000000
- iopl=0 nv up ei pl zr na po nc
- cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00040246
- nt!MiIssueHardFault+0x29d:
- fffff801`1445bb4d eb09 jmp nt!MiIssueHardFault+0x2a8 (fffff801`1445bb58)
- 2: kd> ub .
- nt!MiIssueHardFault+0x282:
- fffff801`1445bb32 33d2 xor edx,edx
- fffff801`1445bb34 e8c73effff call nt!KiStackAttachProcess (fffff801`1444fa00)
- fffff801`1445bb39 4d8b4510 mov r8,qword ptr [r13+10h]
- fffff801`1445bb3d 83cb02 or ebx,2
- fffff801`1445bb40 8bd3 mov edx,ebx
- fffff801`1445bb42 488bcf mov rcx,rdi
- fffff801`1445bb45 83e201 and edx,1
- fffff801`1445bb48 e847240000 call nt!MiIssueHardFaultIo (fffff801`1445df94)
- β¨β¨β¨
- 2: kd> dt @rdi nt!_mminpage_support π½ dump arg1 (rcx/rdi) for MiIssueHardFaultIo
- +0x000 ListEntry : _LIST_ENTRY [ 0x00000000`00000000 - 0x00000000`00000000 ]
- +0x000 SListEntry : _SLIST_ENTRY
- +0x010 ListHead : _LIST_ENTRY [ 0xffffb005`ff1175b0 - 0xffffb005`ff1175b0 ]
- +0x020 Event : _KEVENT
- +0x038 CollidedEvent : _KEVENT
- +0x050 IoStatus : _IO_STATUS_BLOCK
- +0x060 ReadOffset : _LARGE_INTEGER 0x20000000`0078d807
- +0x068 u2 : <anonymous-tag>
- +0x098 Thread : 0xffffb005`df2c8480 _ETHREAD
- +0x0a0 LockedProtoPfn : (null)
- +0x0a8 PteContents : _MMPTE
- +0x0b0 WaitCount : 0n1
- +0x0b4 InjectRetry : 0n0
- +0x0b8 ByteCount : 0x1000
- +0x0bc u3 : <anonymous-tag>
- +0x0c0 u1 : <anonymous-tag> π½π±οΈ click
- +0x0c8 FilePointer : (null)
- +0x0c8 PagingFile : (null)
- +0x0d0 ControlArea : (null)
- +0x0d0 Subsection : (null)
- +0x0d8 Autoboost : 0xffffb005`df2c8ad0 Void
- +0x0e0 FaultingAddress : 0xffff9c89`4f503000 Void
- +0x0e8 PointerPte : 0xfffffcce`44a7a818 _MMPTE
- +0x0f0 BasePte : 0xfffffcce`44a7a818 _MMPTE
- +0x0f8 Pfn : 0xffffea00`0b93d900 _MMPFN
- +0x100 PrefetchMdl : (null)
- +0x108 ProbeCount : 0n0
- +0x110 Mdl : _MDL
- +0x140 Page : [16] 0x3dbf30 π½π¦ our PFN we've seen before
- +0x140 FlowThrough : _MMINPAGE_SUPPORT_FLOW_THROUGH
- 2: kd> dx -id 0,0,ffffb005e91bc040 -r1 (*((ntkrnlmp!_MMINPAGE_SUPPORT *)0xffffb005ff1175a0)).u1
- (*((ntkrnlmp!_MMINPAGE_SUPPORT *)0xffffb005ff1175a0)).u1 [Type: <anonymous-tag>]
- [+0x000] e1 [Type: _MMINPAGE_FLAGS] π½π±οΈ click
- [+0x000] LongFlags : 0x284b00 [Type: unsigned long]
- 2: kd> dx -id 0,0,ffffb005e91bc040 -r1 (*((ntkrnlmp!_MMINPAGE_FLAGS *)0xffffb005ff117660))
- (*((ntkrnlmp!_MMINPAGE_FLAGS *)0xffffb005ff117660)) [Type: _MMINPAGE_FLAGS]
- [+0x000 ( 0: 0)] GetExtents : 0x0 [Type: unsigned long]
- [+0x000 ( 2: 1)] PrefetchSystemVmType : 0x0 [Type: unsigned long]
- [+0x000 ( 3: 3)] VaPrefetchReadBlock : 0x0 [Type: unsigned long]
- [+0x000 ( 4: 4)] CollidedFlowThrough : 0x0 [Type: unsigned long]
- [+0x000 ( 5: 5)] ForceCollisions : 0x0 [Type: unsigned long]
- [+0x000 ( 6: 6)] InPageExpanded : 0x0 [Type: unsigned long]
- [+0x000 ( 7: 7)] IssuedAtLowPriority : 0x0 [Type: unsigned long]
- [+0x000 ( 8: 8)] FaultFromStore : 0x1 [Type: unsigned long] π½ yes, from store
- [+0x000 (11: 9)] PagePriority : 0x5 [Type: unsigned long]
- [+0x000 (14:12)] ClusteredPagePriority : 0x4 [Type: unsigned long]
- [+0x000 (15:15)] MakeClusterValid : 0x0 [Type: unsigned long]
- [+0x000 (16:16)] PerformRelocations : 0x0 [Type: unsigned long]
- [+0x000 (17:17)] ZeroLastPage : 0x0 [Type: unsigned long]
- [+0x000 (18:18)] UserFault : 0x0 [Type: unsigned long]
- [+0x000 (19:19)] StandbyProtectionNeeded : 0x1 [Type: unsigned long]
- [+0x000 (20:20)] PteChanged : 0x0 [Type: unsigned long]
- [+0x000 (21:21)] PageFileFault : 0x1 [Type: unsigned long] π½ kinda
- [+0x000 (22:22)] PageFilePageHashActive : 0x0 [Type: unsigned long]
- [+0x000 (23:23)] CoalescedIo : 0x0 [Type: unsigned long]
- [+0x000 (24:24)] VmLockNotNeeded : 0x0 [Type: unsigned long]
- [+0x000 (25:25)] Spare0 : 0x0 [Type: unsigned long]
- [+0x000 (31:26)] Spare1 : 0x0 [Type: unsigned long]
- β¨β¨β¨β¨β¨β¨β¨β¨
- Okay, checkpoint. Let's see what we have. To delete a segment, system needed to lock the page containing prototype PTE
- for the file header, but that page was not valid. So OS called MmAccessFault to make it valid. The "invalid" PTE is
- marked as transition, and contains PFN. Via PFN database we found out contents of the original PTE (MMPFN.OriginalPte).
- It contained "offset" and pagefile number == 2 π.
- If you read "2019.Extracting Compressed Pages from the Windows 10 Virtual Store.Sardar.[MemCompression].pdf", you'll
- know that pagefile number 2 refers to fake pagefile - the store manager; i.e. the page was compressed. OS needs to
- decompress the page, so it invokes SmPageRead (frame 0x16).
- That means funcs MiIssueHardFault/MiIssueHardFaultIo do not imply disk read request at all! Such claims are incorrect.
- 08 ffffe509`f8199650 fffff801`144d10d0 nt!KiPageFault+0x443 π½π called the "real" MmAccessFault
- 09 ffffe509`f81997e8 fffff801`144a6bf0 nt!RtlDecompressBufferXpressLz+0x50 π½π₯
- 0a ffffe509`f8199800 fffff801`144a6938 nt!RtlDecompressBufferEx+0x60
- 0b ffffe509`f8199850 fffff801`144a67c5 nt!ST_STORE<SM_TRAITS>::StDmSinglePageCopy+0x150
- ...
- 15 ffffe509`f8199d80 fffff801`144fa96b nt!SMKM_STORE_MGR<SM_TRAITS>::SmPageRead+0x167
- 16 ffffe509`f8199df0 fffff801`1445e0a0 nt!SmPageRead+0x33
- 17 ffffe509`f8199e40 fffff801`1445bb4d nt!MiIssueHardFaultIo+0x10c
- 18 ffffe509`f8199e90 fffff801`14528278 nt!MiIssueHardFault+0x29d
- 19 ffffe509`f8199f50 fffff801`1442a4d2 nt!MmAccessFault+0x468 π½π¦ "fake" fault (described below)
- 1a ffffe509`f819a0f0 fffff801`14460836 nt!MiDeleteSubsectionPages+0x172
- 1b ffffe509`f819a1b0 fffff801`14808d56 nt!MiDeleteSegmentPages+0x56
- 1c ffffe509`f819a210 fffff801`14584a89 nt!MiSegmentDelete+0x92
- 1d ffffe509`f819a260 fffff801`145ba179 nt!MiProcessDereferenceList+0xc1 π½ποΈ
- π½ We've confirmed that everything was in order, and we're back at pagefault at frames 09/08. To decompress the
- packed page, RtlDecompressBufferXpressLz was invoked. And here's the twist: the compressed data itself was paged out!
- So the real pagefault happened (frame 8). Is it normal to page out the compressed data? Actually yes, it can happen.
- 2: kd> .cxr 0xffffe509f8198de0 π½π° restore context at the moment of #PF
- rax=fffff801144d1080 rbx=ffffd3011992f000 rcx=ffffd3011992f000 π½ (it's .cxr, so context is fully valid)
- rdx=ffffd3011992f000 rsi=0000000000000002 rdi=0000027e296ab9f0
- rip=fffff801144d10d0 rsp=ffffe509f81997e8 rbp=0000027e296ab9af
- r8=0000027e296ab9f0 r9=0000000000000015 r10=ffffd3011992fea0
- r11=0000027e296aba05 r12=ffffe509f8199a58 r13=ffffb005ee4ef000
- r14=ffffd30119930000 r15=0000000000000000
- iopl=0 nv up ei pl zr na po nc
- cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00050246
- nt!RtlDecompressBufferXpressLz+0x50:
- fffff801`144d10d0 418b08 mov ecx,dword ptr [r8] ds:002b:0000027e`296ab9f0=???????? π½π₯
- π½ You can see the faulted address is in usermode range. That's normal, that's just MemCompression process stores
- the packed data. It also explains the reason why the System-owned thread had to attach to MemCompression process.
- We can use `!pte` command to help us find out the pagefile which contains the compressed data.
- 2: kd> !pte 27e`296ab9f0 π½π₯
- VA 0000027e296ab9f0
- PXE at FFFFFCFE7F3F9020 PPE at FFFFFCFE7F204FC0 PDE at FFFFFCFE409F8A58 PTE at FFFFFC813F14B558
- Page 131a53 not present in the dump file. Type ".hh dbgerr004" for details
- Unable to get PXE FFFFFCFE7F204FC0
- π½ Oops! No, we can't use `!pte` here. The address is in usermode range, and the dump is kernel-only dump;
- apparently it means that PTEs for usermode ranges are not included in the dump either.
- But we need the relevant dump file location. Because we know that system tried to read the compressed page from the
- pagefile, and that read failed with π C000000E (STATUS_NO_SUCH_DEVICE). Yet there can be multiple pagefiles, on
- different disks: we *really* want to know which disk read failed.
- π½ But whatever; OS allows less than 0x10 pagefiles, let's simply list all of them.
- β¨β¨β¨β¨β¨β¨β¨β¨
- 2: kd> !vm
- Page File: \??\C:\pagefile.sys π½ the only real pagefile, on C:
- Current: 12582912 Kb Free Space: 11681548 Kb
- Minimum: 12582912 Kb Maximum: 31023400 Kb
- Page File: \??\C:\swapfile.sys π½ for UWP, not our case
- Current: 16384 Kb Free Space: 16376 Kb
- Minimum: 16384 Kb Maximum: 24818720 Kb
- No Name for Paging File π½ fake pagefile; it's the Store Manager (compressed data)
- Current: 47601456 Kb Free Space: 41454724 Kb
- Minimum: 47601456 Kb Maximum: 47601456 Kb
- Physical Memory: 4144514 ( 16578056 Kb)
- Available Pages: 719871 ( 2879484 Kb)
- ResAvail Pages: 3437549 ( 13750196 Kb)
- Locked IO Pages: 0 ( 0 Kb)
- Free System PTEs: 4294975607 (17179902428 Kb)
- ******* 69376 kernel stack PTE allocations have failed ******
- ******* 350546176 kernel stack growth attempts have failed ******
- π½ ^^ `!vm` command shows obviously bogus alloc failure info; no way system sustained that many allocation failures.
- Reason for this bogus info is Microsoft's fail to provide correct _MI_SYSTEM_INFORMATION struct symbols (at nt!MiState).
- After many years MS fixed symbols btw, but only for some win11 builds; MS generally neglects OS kernel debugging.
- Modified Pages: 8438 ( 33752 Kb)
- Modified PF Pages: 8436 ( 33744 Kb)
- Modified No Write Pages: 24 ( 96 Kb)
- NonPagedPool Usage: 241 ( 964 Kb)
- NonPagedPoolNx Usage: 233372 ( 933488 Kb)
- NonPagedPool Max: 4294967296 (17179869184 Kb)
- PagedPool Usage: 130023 ( 520092 Kb)
- PagedPool Maximum: 4294967296 (17179869184 Kb)
- Processor Commit: 1304 ( 5216 Kb)
- Unable to read nt!_LIST_ENTRY.Flink at 0000000000000000
- Session Commit: 0 ( 0 Kb)
- Shared Commit: 766838 ( 3067352 Kb)
- Special Pool: 0 ( 0 Kb)
- Kernel Stacks: 41507 ( 166028 Kb)
- Pages For MDLs: 52320 ( 209280 Kb)
- ContigMem Pages: 0 ( 0 Kb)
- Partition Pages: 0 ( 0 Kb)
- Pages For AWE: 0 ( 0 Kb)
- NonPagedPool Commit: 238303 ( 953212 Kb)
- PagedPool Commit: 130023 ( 520092 Kb)
- Driver Commit: 44256 ( 177024 Kb)
- Boot Commit: 4794 ( 19176 Kb)
- PFN Array Commit: 49119 ( 196476 Kb)
- SmallNonPagedPtesCommit: 875 ( 3500 Kb)
- SlabAllocatorPages: 4608 ( 18432 Kb)
- SkPagesInUnchargedSlabs: 0 ( 0 Kb)
- System PageTables: 5695 ( 22780 Kb)
- ProcessLockedFilePages: 123 ( 492 Kb)
- Pagefile Hash Pages: 462 ( 1848 Kb)
- Sum System Commit: 1340227 ( 5360908 Kb)
- Total Private: 4620955 ( 18483820 Kb)
- Misc/Transient Commit: 59369 ( 237476 Kb)
- Committed pages: 6020551 ( 24082204 Kb)
- Commit limit: 7290242 ( 29160968 Kb)
- Pid ImageName Commit SharedCommit Debt
- bb0 chrome.exe 1365620 Kb 864360 Kb 0 Kb
- ... <tons of processes here, removed>
- ...
- β¨β¨β¨β¨β¨β¨β¨β¨
- π½ So we learned that there's only one real pagefile - C:\pagefile.sys. Thus the device stack which failed the read
- request with π C000000E (STATUS_NO_SUCH_DEVICE) is related to the C: volume.
- β¨β¨β¨
- 2: kd> !driveinfo C:
- Drive C:, DriveObject ffff9c894949acd0 π½ not really a drive, it is just the "C:" symlink object;
- Directory Object: ffff9c8947629280 Name: C: π½ you get same output via `!object \\GLOBAL??\\C:`
- Flags: 00000000 ( Local )
- Target String is '\Device\HarddiskVolume4' π½π₯
- Drive Letter Index is 3 (C:)
- Volume DevObj: ffffb005cc3f1c00 π½β½ device object for \Driver\volmgr =VPB.RealDevice
- Vpb: ffffb005cc3d5cd0 DeviceObject: ffffb005df2d5030 ππ device object for \FileSystem\Ntfs =VPB.DeviceObject
- FileSystem: \FileSystem\Ntfs
- Cannot get ntfs!VOLUME_DEVICE_OBJECT.Vcb @ ffffb005df2d5030
- π½ ^^ Wow, what a horrible performance! It took 6 bloody minutes to complete this simple command, I'm kidding you not.
- When the whole dump analysis takes may be 15-30 minutes, that's prohibitively expensive.
- And the info this command gave us, while useful, is quite incomplete: it doesn't tell us anything about the disk device.
- β¨β¨β¨
- π½ A while ago I've made a simple windbg script to list ntfs volumes and free space (because Microsoft's `!diskspace`
- command was broken [naturally π]). Let's adjust it a little bit and run it here:
- 2: kd> r$t0=0; r$t1=0;.foreach(v {#"lock cmpxchg" ntfs!NtfsAllocateBitmapRun L1000}) {.if (@$t1<2) {r$t1=@$t1+1} .elsif (@$t1<9) { r$t1=( v >>18&FF)+( v >>8&FF00) }};
- 2: kd> .if(@$t0){r?$t0=(nt!_FILE_OBJECT*)@$t0;r?$t2=@$t0->Vpb->DeviceObject->DeviceExtension;r$t3=@$t2+8;r$t2=poi(@$t3)}.else{r$t2=ntfs!NtfsData+0x18;r$t3=poi(@$t2)};.while(@$t3!=@$t2){r$t4=@$t3-8;.if(wo(@$t4)!=701){.printf "dt ntfs!_VCB %p : bad VCB\n",@$t4}.else{r?$t5=((nt!_DEVICE_OBJECT*)(@$t4)-1);.while(@@(@$t5->DeviceExtension != @$t4)){r?$t5=(nt!_DEVICE_OBJECT*)((int64)@$t5-0x10)};.printf /D "dt <link cmd=\"dt nt!_DEVICE_OBJECT %p\">nt!_DEVICE_OBJECT</link> %p\ndt ntfs!_VCB %p\n TotalClusters : %p\n FreeClusters : %p\n LowestFreeClusters : %p\n HighestFreeClusters : %p\n ClusterSize : %p\n",@$t5,@$t5,@$t4,qwo(@$t4+128),qwo(@$t4+130),qwo(@$t4+@$t1),qwo(@$t4+@$t1+8),dwo(@$t4+160);r?$t5=@$t5->DeviceObjectExtension->Vpb;??@$t5;!devobj @@(@$t5->RealDevice); .printf "\n"};r$t3=poi(@$t3);}
- β¨β¨β¨
- π½ ^^ Isnt't this 2-line script just beautiful? Like a tiny pearl! Or a writhing ball of worms. Ew. Lol. Anyway, script
- output is below, and since it works instantly, the next time we can save a few minutes.
- dt nt!_DEVICE_OBJECT ffffb005df2d5030
- dt ntfs!_VCB ffffb005df2d5180
- TotalClusters : 0000000003b2c251
- FreeClusters : 000000000284f806
- LowestFreeClusters : 000000000284f7f6
- HighestFreeClusters : 0000000002aaf799
- ClusterSize : 0000000000001000
- struct _VPB * 0xffffb005`cc3d5cd0 π½ that's Volume Parameters Block
- +0x000 Type : 0n10
- +0x002 Size : 0n96
- +0x004 Flags : 1
- +0x006 VolumeLabelLength : 4
- +0x008 DeviceObject : 0xffffb005`df2d5030 _DEVICE_OBJECT ππ
- +0x010 RealDevice : 0xffffb005`cc3f1c00 _DEVICE_OBJECT π½β½
- +0x018 SerialNumber : 0x36008800
- +0x01c ReferenceCount : 0x5530
- +0x020 VolumeLabel : [32] "OS" π½ apparently volume had label
- Device object (ffffb005cc3f1c00) is for:
- HarddiskVolume4 \Driver\volmgr DriverObject ffffb005c5106e20 π½π₯
- Current Irp 00000000 RefCount 21808 Type 00000007 Flags 00001150
- Vpb 0xffffb005cc3d5cd0 SecurityDescriptor ffff9c8949423920 DevExt ffffb005cc3f1d50 DevObjExt ffffb005cc3f1f18 Dope ffffb005df287490 DevNode ffffb005df28eba0
- ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
- Characteristics (0x00020000) FILE_DEVICE_ALLOW_APPCONTAINER_TRAVERSAL
- AttachedDevice (Upper) ffffb005df2be030 \Driver\fvevol
- Device queue is not busy.
- dt nt!_DEVICE_OBJECT ffffb005e4cd6030
- dt ntfs!_VCB ffffb005e4cd6180
- TotalClusters : 000000000e8e0bff
- FreeClusters : 000000000e8d521c
- LowestFreeClusters : 000000000e8d521c
- HighestFreeClusters : 000000000e8d521c
- ClusterSize : 0000000000001000
- struct _VPB * 0xffffb005`e4b7bd20
- +0x000 Type : 0n10
- +0x002 Size : 0n96
- +0x004 Flags : 1
- +0x006 VolumeLabelLength : 8
- +0x008 DeviceObject : 0xffffb005`e4cd6030 _DEVICE_OBJECT
- +0x010 RealDevice : 0xffffb005`df25cc40 _DEVICE_OBJECT
- +0x018 SerialNumber : 0x7463ceff
- +0x01c ReferenceCount : 0x24
- +0x020 VolumeLabel : [32] "DATA"
- Device object (ffffb005df25cc40) is for:
- HarddiskVolume1 \Driver\volmgr DriverObject ffffb005c5106e20
- Current Irp 00000000 RefCount 36 Type 00000007 Flags 00003050
- Vpb 0xffffb005e4b7bd20 SecurityDescriptor ffff9c8949423920 DevExt ffffb005df25cd90 DevObjExt ffffb005df25cf58 Dope ffffb005df286d20 DevNode ffffb005df26abb0
- ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
- Characteristics (0x00020000) FILE_DEVICE_ALLOW_APPCONTAINER_TRAVERSAL
- AttachedDevice (Upper) ffffb005df2ab030 \Driver\fvevol
- Device queue is not busy.
- <..>
- dt nt!_DEVICE_OBJECT ffffb005f7cbb030
- dt ntfs!_VCB ffffb005f7cbb180
- TotalClusters : 0000000003b2c251
- FreeClusters : 0000000002ab3146
- LowestFreeClusters : 0000000002ab3146
- HighestFreeClusters : 0000000002ab3146
- ClusterSize : 0000000000001000
- struct _VPB * 0xffffb005`edd65a30
- +0x000 Type : 0n10
- +0x002 Size : 0n96
- +0x004 Flags : 1
- +0x006 VolumeLabelLength : 4
- +0x008 DeviceObject : 0xffffb005`f7cbb030 _DEVICE_OBJECT
- +0x010 RealDevice : 0xffffb005`f7b7f2a0 _DEVICE_OBJECT
- +0x018 SerialNumber : 0x36008800
- +0x01c ReferenceCount : 0x17b
- +0x020 VolumeLabel : [32] "OS"
- Device object (ffffb005f7b7f2a0) is for:
- HarddiskVolumeShadowCopy4 \Driver\volsnap DriverObject ffffb005cc364d30 π½ shadow copy volume, ignore it
- Current Irp 00000000 RefCount 379 Type 00000024 Flags 00001050
- Vpb 0xffffb005edd65a30 SecurityDescriptor ffff9c8949423920 DevExt ffffb005f7b7f3f0 DevObjExt ffffb005f7b7f988 Dope ffffb005edd65b80 DevNode ffffb005efe04cc0
- ExtensionFlags (0000000000)
- Characteristics (0000000000)
- Device queue is not busy.
- π½ Let's continue with information we've just retrieved.
- β¨β¨β¨
- 2: kd> dt _device_object ffffb005cc3f1c00 π½β½ checkout volume "RealDevice"; drv: \Driver\volmgr
- nt!_DEVICE_OBJECT π½ it's pointed to by FILE_OBJECT.DeviceObject
- +0x000 Type : 0n3
- +0x002 Size : 0x318
- +0x004 ReferenceCount : 0n21808
- +0x008 DriverObject : 0xffffb005`c5106e20 _DRIVER_OBJECT
- +0x010 NextDevice : 0xffffb005`df264c40 _DEVICE_OBJECT
- +0x018 AttachedDevice : 0xffffb005`df2be030 _DEVICE_OBJECT
- +0x020 CurrentIrp : (null)
- +0x028 Timer : (null)
- +0x030 Flags : 0x1150
- +0x034 Characteristics : 0x20000
- +0x038 Vpb : 0xffffb005`cc3d5cd0 _VPB π½π VPB pointer we've seen above
- +0x040 DeviceExtension : 0xffffb005`cc3f1d50 Void π½ not the device extension we want (see below)
- +0x048 DeviceType : 7
- +0x04c StackSize : 6 ''
- +0x050 Queue : <anonymous-tag>
- +0x098 AlignmentRequirement : 3
- +0x0a0 DeviceQueue : _KDEVICE_QUEUE
- +0x0c8 Dpc : _KDPC
- +0x108 ActiveThreadCount : 0
- +0x110 SecurityDescriptor : 0xffff9c89`49423920 Void
- +0x118 DeviceLock : _KEVENT
- +0x130 SectorSize : 0x200
- +0x132 Spare1 : 1
- +0x138 DeviceObjectExtension : 0xffffb005`cc3f1f18 _DEVOBJ_EXTENSION
- +0x140 Reserved : (null)
- 2: kd> !devobj ffffb005cc3f1c00 π½β½ same "RealDevice", just different command
- Device object (ffffb005cc3f1c00) is for:
- HarddiskVolume4 \Driver\volmgr DriverObject ffffb005c5106e20
- Current Irp 00000000 RefCount 21808 Type 00000007 Flags 00001150
- Vpb 0xffffb005cc3d5cd0 SecurityDescriptor ffff9c8949423920 DevExt ffffb005cc3f1d50 DevObjExt ffffb005cc3f1f18 Dope ffffb005df287490 DevNode ffffb005df28eba0
- ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
- Characteristics (0x00020000) FILE_DEVICE_ALLOW_APPCONTAINER_TRAVERSAL
- AttachedDevice (Upper) ffffb005df2be030 \Driver\fvevol
- Device queue is not busy.
- 2: kd> !devstack ffffb005cc3f1c00 π½β½ check where's the device in the device stack
- !DevObj !DrvObj !DevExt ObjectName
- ffffb005df2b9080 \Driver\volsnap ffffb005df2b91d0
- ffffb005cc3f2e10 \Driver\volume ffffb005cc3f2f60
- ffffb005df2bf7d0 \Driver\iorate ffffb005df2bf920
- ffffb005df2be030 \Driver\fvevol ffffb005df2be180
- > ffffb005cc3f1c00 \Driver\volmgr ffffb005cc3f1d50 HarddiskVolume4 π½β½ ...here it is
- !DevNode ffffb005df28eba0 :
- DeviceInst is "STORAGE\Volume\{b3d462db-0a60-11eb-9bca-806e6f6e6963}#0000000011500000"
- ServiceName is "volume"
- π½ ^^ Note devices/drivers in device stack. Everything is standard.
- If you have doubts about driver, download it to your symstore and check if vendor is MS, e.g. via `!chkimg iorate`.
- β¨β¨β¨
- 2: kd> dt _device_object ffffb005df2d5030 π½π checkout "DeviceObject"; drv: \FileSystem\Ntfs
- nt!_DEVICE_OBJECT
- +0x000 Type : 0n3
- +0x002 Size : 0x2b20
- +0x004 ReferenceCount : 0n0
- +0x008 DriverObject : 0xffffb005`c82eeb50 _DRIVER_OBJECT
- +0x010 NextDevice : 0xffffb005`c8232a70 _DEVICE_OBJECT
- +0x018 AttachedDevice : 0xffffb005`df267c20 _DEVICE_OBJECT
- +0x020 CurrentIrp : (null)
- +0x028 Timer : (null)
- +0x030 Flags : 0x8060000
- +0x034 Characteristics : 0
- +0x038 Vpb : (null)
- +0x040 DeviceExtension : 0xffffb005`df2d5180 Void π½ pointer to ntfs!_VCB (Volume Control Block)
- +0x048 DeviceType : 8
- +0x04c StackSize : 11 ''
- +0x050 Queue : <anonymous-tag>
- +0x098 AlignmentRequirement : 3
- +0x0a0 DeviceQueue : _KDEVICE_QUEUE
- +0x0c8 Dpc : _KDPC
- +0x108 ActiveThreadCount : 0
- +0x110 SecurityDescriptor : 0xffff9c89`49423920 Void
- +0x118 DeviceLock : _KEVENT
- +0x130 SectorSize : 0x200
- +0x132 Spare1 : 1
- +0x138 DeviceObjectExtension : 0xffffb005`df2d7b50 _DEVOBJ_EXTENSION
- +0x140 Reserved : (null)
- 2: kd> !devobj π½π same "DeviceObject"
- Device object not found
- 2: kd> !devobj ffffb005df2d5030
- Device object (ffffb005df2d5030) is for:
- \FileSystem\Ntfs DriverObject ffffb005c82eeb50
- Current Irp 00000000 RefCount 0 Type 00000008 Flags 08060000
- SecurityDescriptor ffff9c8949423920 DevExt ffffb005df2d5180 DevObjExt ffffb005df2d7b50
- ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
- Characteristics (0000000000)
- AttachedDevice (Upper) ffffb005df267c20 \FileSystem\FltMgr
- Device queue is not busy.
- 2: kd> !devstack ffffb005df2d5030 π½π check where's the device in the device stack
- !DevObj !DrvObj !DevExt ObjectName
- ffffb005df267c20 \FileSystem\FltMgr ffffb005df267d70 π½ there can be minifilters there
- > ffffb005df2d5030 \FileSystem\Ntfs ffffb005df2d5180
- β¨β¨β¨β¨β¨β¨β¨β¨
- π½ Well, the device stack here is fairly standard. What I'm not sure is filesystem filters (or rather minifilters).
- I don't know if they really can affect paging path (probably they shouldn't, but at the same time they probably can).
- So let's dump filters.
- 2: kd> !fltkd.filters π½ note the "S" in filterS
- Filter List: ffffb005c82600c0 "Frame 0"
- FLT_FILTER: ffffb005e9097010 "bindflt" "409800" π½ for mounting
- FLT_INSTANCE: ffffb005ee495050 "bindflt Instance" "409800"
- FLT_FILTER: ffffb005c82ef7e0 "WdFilter" "328010" π½ Windows Defender
- FLT_INSTANCE: ffffb005df26eab0 "WdFilter Instance" "328010"
- FLT_INSTANCE: ffffb005df320b40 "WdFilter Instance" "328010"
- FLT_INSTANCE: ffffb005dfb1d010 "WdFilter Instance" "328010"
- FLT_INSTANCE: ffffb005dfb19b30 "WdFilter Instance" "328010"
- FLT_INSTANCE: ffffb005e4d51b40 "WdFilter Instance" "328010"
- FLT_INSTANCE: ffffb005f5124820 "WdFilter Instance" "328010"
- FLT_INSTANCE: ffffb005f57ea260 "WdFilter Instance" "328010"
- FLT_INSTANCE: ffffb005f6370700 "WdFilter Instance" "328010"
- FLT_FILTER: ffffb005cc224210 "mfehidk" "321300.00" π½π©π crap, that's McAfee
- FLT_INSTANCE: ffffb005df26f010 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005df5e94e0 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005e41d97e0 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005e48f4060 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005e4d3b010 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005e4d515f0 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005ef37b010 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005f49ed010 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005f2ced490 "mfehidk" "321300.00"
- FLT_FILTER: ffffb005e4d43be0 "storqosflt" "244000" π½ for throttling
- FLT_FILTER: ffffb005e66c9a20 "wcifs" "189900" π½ Windows Container Isolation
- FLT_FILTER: ffffb005e6370520 "CldFlt" "180451" π½ OneDrive and the like
- FLT_INSTANCE: ffffb005e90e2a20 "CldFlt" "180451"
- FLT_INSTANCE: ffffb005f4ae7010 "CldFlt" "180451"
- FLT_INSTANCE: ffffb005f56f5a20 "CldFlt" "180451"
- FLT_INSTANCE: ffffb005f4cea010 "CldFlt" "180451"
- FLT_FILTER: ffffb005df75a5e0 "FileCrypt" "141100" π½ EFS
- FLT_FILTER: ffffb005e4eed010 "luafv" "135000" π½ redir to virtual store from protected dirs
- FLT_INSTANCE: ffffb005e90b5010 "luafv" "135000"
- FLT_FILTER: ffffb005e48f8ca0 "npsvctrig" "46000" π½ triggers services start on pipes access
- FLT_INSTANCE: ffffb005e3f11b10 "npsvctrig" "46000"
- FLT_FILTER: ffffb005c81d97e0 "Wof" "40700" π½ Windows Overlay Filesystem
- FLT_INSTANCE: ffffb005df5e5800 "Wof Instance" "40700"
- FLT_INSTANCE: ffffb005e4d34520 "Wof Instance" "40700"
- FLT_INSTANCE: ffffb005e4d34050 "Wof Instance" "40700"
- FLT_INSTANCE: ffffb005ebf67010 "Wof Instance" "40700"
- FLT_INSTANCE: ffffb005ed352520 "Wof Instance" "40700"
- FLT_INSTANCE: ffffb005ebbd6b20 "Wof Instance" "40700"
- FLT_FILTER: ffffb005c83099b0 "FileInfo" "40500" π½ Prefetch-related
- FLT_INSTANCE: ffffb005df26e010 "FileInfo" "40500"
- FLT_INSTANCE: ffffb005df5ef9f0 "FileInfo" "40500"
- FLT_INSTANCE: ffffb005e3f34340 "FileInfo" "40500"
- FLT_INSTANCE: ffffb005e4817690 "FileInfo" "40500"
- FLT_INSTANCE: ffffb005e41857c0 "FileInfo" "40500"
- FLT_INSTANCE: ffffb005f28d2010 "FileInfo" "40500"
- FLT_INSTANCE: ffffb005f4bf0a20 "FileInfo" "40500"
- FLT_INSTANCE: ffffb005f5005a20 "FileInfo" "40500"
- π½ Let's check McAfee. Command below outputs bunch of errors, I've cleaned it up for clarity.
- β¨β¨β¨
- 2: kd> !fltkd.filter ffffb005cc224210 π½π© check the McAfee (note singular "filter")
- FLT_FILTER: ffffb005cc224210 "mfehidk" "321300.00"
- FLT_OBJECT: ffffb005cc224210 [02000000] Filter
- RundownRef : 0x00000000000093a8 (18900)
- PointerCount : 0x00000001
- PrimaryLink : [ffffb005e4d43bf0-ffffb005c82ef7f0]
- Frame : ffffb005c8260010 "Frame 0"
- Flags : [0000001a] FilteringInitiated SupportsPipesMailslots BackedByPagefile
- DriverObject : ffffb005c82f0830 π½π
- FilterLink : [ffffb005e4d43bf0-ffffb005c82ef7f0]
- PreVolumeMount : 0000000000000000 (null)
- PostVolumeMount : 0000000000000000 (null) Unable to load image \SystemRoot\system32\drivers\mfehidk.sys, Win32 error 0n2
- FilterUnload : fffff8011802ee00 mfehidk+0x7ee00
- InstanceSetup : fffff8011802e3b0 mfehidk+0x7e3b0
- InstanceQueryTeardown : 0000000000000000 (null)
- InstanceTeardownStart : fffff8011802ec40 mfehidk+0x7ec40
- InstanceTeardownComplete : fffff8011802ecf0 mfehidk+0x7ecf0
- ActiveOpens : (ffffb005cc2243c8) mCount=0
- Communication Port List : (ffffb005cc224418) mCount=0
- Client Port List : (ffffb005cc224468) mCount=0
- VerifierExtension : 0000000000000000
- Operations : ffffb005cc2244c0
- OldDriverUnload : 0000000000000000 (null)
- SupportedContexts : (ffffb005cc224340)
- VolumeContexts : (ffffb005cc224340)
- InstanceContexts : (ffffb005cc224340)
- FileContexts : (ffffb005cc224340)
- StreamContexts : (ffffb005cc224340)
- StreamHandleContexts : (ffffb005cc224340)
- TransactionContext : (ffffb005cc224340)
- (null) : (ffffb005cc224340)
- InstanceList : (ffffb005cc224278)
- FLT_INSTANCE: ffffb005df26f010 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005df5e94e0 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005e41d97e0 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005e48f4060 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005e4d3b010 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005e4d515f0 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005ef37b010 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005f49ed010 "mfehidk" "321300.00"
- FLT_INSTANCE: ffffb005f2ced490 "mfehidk" "321300.00"
- β¨β¨β¨
- 2: kd> !drvobj ffffb005c82f0830 π½π
- Driver object (ffffb005c82f0830) is for:
- \Driver\mfehidk π½π
- Driver Extension List: (id , addr)
- Device Object list:
- ffffb005c82f3ab0 ffffb005c82f3830
- 2: kd> lmvm mfehidk π½π "LoadedModules, Verbose, by-pattern-Match"
- Browse full module list
- start end module name
- fffff801`17fb0000 fffff801`180b5000 mfehidk (export symbols) mfehidk.sys
- Loaded symbol image file: mfehidk.sys
- Image path: \SystemRoot\system32\drivers\mfehidk.sys
- Image name: mfehidk.sys
- Browse all global symbols functions data
- Timestamp: Tue Dec 8 21:10:49 2020 (5FCFEBD9) π½π McAfee driver is ~7 months old
- CheckSum: 000FF041
- ImageSize: 00105000
- Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
- Information from resource tables:
- β¨β¨β¨
- Okay, all that info is very pretty, but it doesn't tell us anything substantial right now.
- I'm not even sure this filter affects the paging path. McAfee driver is ~7 months old - not fresh, but not old either.
- We'll keep it in mind as a potential culprit, but most likely McAfee simply was in a wrong place at a wrong time.
- β¨β¨β¨β¨β¨β¨β¨β¨
- π½ Alright, what else do we have? The device stack is standard. And I highly doubt that Microsoft `volmgr` driver or
- `Ntfs` driver were directly involved in returning π STATUS_NO_SUCH_DEVICE out of the blue.
- What we need to examine now is not the volume, but the disk device object, and its device stack. How to do it?
- Run Sysinternals WinObj. You'll see directories `\Device\Harddisk0`, `\Device\Harddisk1`, etc. These directories contain
- single device object, like `DR0` or `DR1` (physical drive 0, physical drive 1), and a bunch of symlinks for that drive
- partitions. Symlinks would point to partition devices, such as `\Device\HarddiskVolume4`.
- β¨β¨β¨
- 2: kd> !object \Device\Harddisk0 π½ explore Physical Drive 0
- Object: ffff9c89490cc5a0 Type: (ffffb005c50cf640) Directory
- ObjectHeader: ffff9c89490cc570 (new version)
- HandleCount: 1 PointerCount: 5
- Directory Object: ffff9c8947603780 Name: Harddisk0
- Hash Address Type Name
- ---- ------- ---- ----
- 21 ffffb005df271170 Device DR0
- 25 ffff9c8949498460 SymbolicLink Partition0 π½ Parition0 is not actually a parition
- 26 ffff9c8949499f50 SymbolicLink Partition1 π½ the only partition on drive0
- 2: kd> !object ffff9c8949498460 π½ check symlink for Partition0...
- Object: ffff9c8949498460 Type: (ffffb005c50cfd20) SymbolicLink
- ObjectHeader: ffff9c8949498430 (new version)
- HandleCount: 0 PointerCount: 1
- Directory Object: ffff9c89490cc5a0 Name: Partition0
- Flags: 00000000 ( Local )
- Target String is '\Device\Harddisk0\DR0' π½ ...it's kind of a loopback, back to the drive
- 2: kd> !object ffff9c8949499f50
- Object: ffff9c8949499f50 Type: (ffffb005c50cfd20) SymbolicLink π½ check symlink for Partition1...
- ObjectHeader: ffff9c8949499f20 (new version)
- HandleCount: 0 PointerCount: 1
- Directory Object: ffff9c89490cc5a0 Name: Partition1
- Flags: 00000000 ( Local )
- Target String is '\Device\HarddiskVolume1' π½ ...it's not our HarddiskVolume4; move on
- β¨β¨β¨
- 2: kd> !object \Device\Harddisk1 π½ explore Physical Drive 1
- Object: ffff9c89490cbce0 Type: (ffffb005c50cf640) Directory
- ObjectHeader: ffff9c89490cbcb0 (new version)
- HandleCount: 1 PointerCount: 8
- Directory Object: ffff9c8947603780 Name: Harddisk1
- Hash Address Type Name
- ---- ------- ---- ----
- 22 ffffb005df273060 Device DR1 π½πΎ
- 25 ffff9c89494994a0 SymbolicLink Partition0
- 26 ffff9c89494991d0 SymbolicLink Partition1 π½ if you click this, that'll be HarddiskVolume2
- 27 ffff9c8949499920 SymbolicLink Partition2
- 28 ffff9c894949a580 SymbolicLink Partition3 π½π±οΈ I'm feeling lucky, let's just click this
- 29 ffff9c894949abb0 SymbolicLink Partition4
- 2: kd> !object ffff9c894949a580 π½ check symlink for Partition 3...
- Object: ffff9c894949a580 Type: (ffffb005c50cfd20) SymbolicLink
- ObjectHeader: ffff9c894949a550 (new version)
- HandleCount: 0 PointerCount: 1
- Directory Object: ffff9c89490cbce0 Name: Partition3
- Flags: 00000000 ( Local )
- Target String is '\Device\HarddiskVolume4' π½ ...yes, it's the C: volume
- β¨β¨β¨β¨β¨β¨β¨β¨
- π½ Excellent, we've identified that drive device with pagefile is \Device\Harddisk1\DR1, πΎ ffffb005df273060.
- 2: kd> dt _device_object ffffb005df273060 π½πΎ eye the disk device object
- nt!_DEVICE_OBJECT
- +0x000 Type : 0n3
- +0x002 Size : 0xa00
- +0x004 ReferenceCount : 0n11
- +0x008 DriverObject : 0xffffb005`df26fdc0 _DRIVER_OBJECT
- +0x010 NextDevice : 0xffffb005`df271170 _DEVICE_OBJECT
- +0x018 AttachedDevice : 0xffffb005`df274040 _DEVICE_OBJECT
- +0x020 CurrentIrp : (null)
- +0x028 Timer : (null)
- +0x030 Flags : 0x1000050
- +0x034 Characteristics : 0x100
- +0x038 Vpb : 0xffffb005`df2867e0 _VPB
- +0x040 DeviceExtension : 0xffffb005`df2731b0 Void
- +0x048 DeviceType : 7
- +0x04c StackSize : 3 ''
- +0x050 Queue : <anonymous-tag>
- +0x098 AlignmentRequirement : 3
- +0x0a0 DeviceQueue : _KDEVICE_QUEUE
- +0x0c8 Dpc : _KDPC
- +0x108 ActiveThreadCount : 0
- +0x110 SecurityDescriptor : 0xffff9c89`49279860 Void
- +0x118 DeviceLock : _KEVENT
- +0x130 SectorSize : 0
- +0x132 Spare1 : 1
- +0x138 DeviceObjectExtension : 0xffffb005`df273a60 _DEVOBJ_EXTENSION
- +0x140 Reserved : (null)
- 2: kd> !devobj ffffb005df273060 π½πΎ eye the disk device object
- Device object (ffffb005df273060) is for:
- DR1 \Driver\disk DriverObject ffffb005df26fdc0
- Current Irp 00000000 RefCount 11 Type 00000007 Flags 01000050
- Vpb 0xffffb005df2867e0 SecurityDescriptor ffff9c8949279860 DevExt ffffb005df2731b0 DevObjExt ffffb005df273a60 Dope ffffb005df286770
- ExtensionFlags (0000000000)
- Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
- AttachedDevice (Upper) ffffb005df274040 \Driver\partmgr
- AttachedTo (Lower) ffffb005c5106b00 \Driver\ACPI
- Device queue is not busy.
- β¨β¨β¨
- 2: kd> !devstack ffffb005df273060 π½πΎ check where's the device in the device stack
- !DevObj !DrvObj !DevExt ObjectName
- ffffb005df274040 \Driver\partmgr ffffb005df274190
- > ffffb005df273060 \Driver\disk ffffb005df2731b0 DR1
- ffffb005c5106b00 \Driver\ACPI ffffb005c80d5be0
- ffffb005cc218050 Unable to load image \SystemRoot\System32\drivers\iaStorAC.sys, Win32 error 0n2 π½ wtf: no symbols
- \Driver\iaStorAC ffffb005cc2181a0 0000003e
- !DevNode ffffb005c50db010 :
- DeviceInst is "SCSI\Disk&Ven_NVMe&Prod_WDC_PC_SN530_SDB\4&e0fc7e4&0&030000"
- ServiceName is "disk"
- 2: kd> !devstack ffffb005df273060 π½πΎ repeat the command to get rid of the error
- !DevObj !DrvObj !DevExt ObjectName
- ffffb005df274040 \Driver\partmgr ffffb005df274190
- > ffffb005df273060 \Driver\disk ffffb005df2731b0 DR1
- ffffb005c5106b00 \Driver\ACPI ffffb005c80d5be0
- ffffb005cc218050 \Driver\iaStorAC ffffb005cc2181a0 0000003e π½β£οΈπ Intel-bloody-Rapid-Storage in device stack
- !DevNode ffffb005c50db010 :
- DeviceInst is "SCSI\Disk&Ven_NVMe&Prod_WDC_PC_SN530_SDB\4&e0fc7e4&0&030000" π½πΏπ hdd device name
- ServiceName is "disk"
- β¨β¨β¨
- 2: kd> !DevNode ffffb005c50db010
- DevNode 0xffffb005c50db010 for PDO 0xffffb005cc218050
- Parent 0xffffb005c81eeca0 Sibling 0000000000 Child 0000000000
- InstancePath is "SCSI\Disk&Ven_NVMe&Prod_WDC_PC_SN530_SDB\4&e0fc7e4&0&030000"
- ServiceName is "disk"
- State = DeviceNodeStarted (0x308)
- Previous State = DeviceNodeEnumerateCompletion (0x30d)
- StateHistory[13] = DeviceNodeEnumerateCompletion (0x30d)
- StateHistory[12] = DeviceNodeEnumeratePending (0x30c)
- StateHistory[11] = DeviceNodeStarted (0x308) π½ unsure if these "starts" normal, may be they are
- StateHistory[10] = DeviceNodeEnumerateCompletion (0x30d)
- StateHistory[09] = DeviceNodeEnumeratePending (0x30c)
- StateHistory[08] = DeviceNodeStarted (0x308)
- StateHistory[07] = DeviceNodeEnumerateCompletion (0x30d)
- StateHistory[06] = DeviceNodeEnumeratePending (0x30c)
- StateHistory[05] = DeviceNodeStarted (0x308)
- StateHistory[04] = DeviceNodeEnumerateCompletion (0x30d)
- StateHistory[03] = DeviceNodeEnumeratePending (0x30c)
- StateHistory[02] = DeviceNodeStarted (0x308)
- StateHistory[01] = DeviceNodeEnumerateCompletion (0x30d)
- StateHistory[00] = DeviceNodeEnumeratePending (0x30c)
- StateHistory[19] = DeviceNodeStarted (0x308)
- StateHistory[18] = DeviceNodeEnumerateCompletion (0x30d)
- StateHistory[17] = DeviceNodeEnumeratePending (0x30c)
- StateHistory[16] = DeviceNodeStarted (0x308)
- StateHistory[15] = DeviceNodeEnumerateCompletion (0x30d)
- StateHistory[14] = DeviceNodeEnumeratePending (0x30c)
- Flags (0x24000130) DNF_ENUMERATED, DNF_IDS_QUERIED,
- DNF_NO_RESOURCE_REQUIRED, DNF_NO_LOWER_DEVICE_FILTERS,
- DNF_NO_UPPER_DEVICE_FILTERS
- UserFlags (0x00000008) DNUF_NOT_DISABLEABLE
- CapabilityFlags (0x00400380) SilentInstall, RawDeviceOK,
- SurpriseRemovalOK
- Unknown flags 0x00400000
- DisableableDepends = 1 (including self)
- β¨β¨β¨
- 2: kd> lmvm iaStorAC π½β£οΈ "LoadedModules, Verbose, by-pattern-Match"
- Browse full module list
- start end module name
- fffff801`171e0000 fffff801`17dc4000 iaStorAC (deferred)
- Image path: \SystemRoot\System32\drivers\iaStorAC.sys
- Image name: iaStorAC.sys
- Browse all global symbols functions data
- Timestamp: Wed Mar 18 08:02:55 2020 (5E71D5AF)
- CheckSum: 00157209
- ImageSize: 00BE4000
- Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
- Information from resource tables:
- β¨β¨β¨β¨β¨β¨β¨β¨
- π½ Now that's a hit. "iaStorAC.sys" is related to Intel Rapid Storage (Intel RST) technology.
- It is a well-known offender! And it's right in our storage device stack, so it very well may have returned error.
- I don't know if the hardware controller is crap, or if the driver is crap, or if it's the combination of both, but in
- my own experience the technology is a mess with unknown benefit. If you google "iaStorAC", the first link would be
- about BSOD (on Microsoft.com), the second link would be about BSOD (on Intel.com, in its own knowledge base πΉ), and
- in fact all other links of the page would be about iaStorAC BSODs.
- β¨β¨β¨
- It might not sound fair to blame the driver just because it sits in the failing devstack and is known to have caused
- a bunch of BSODs in the past. But if we won't find more evidence against this driver, we'd still recommend disable the
- Intel Rapid Storage Technology in the BIOS.
- SPOILER: we will find more evidence towards the end of the article, using storagekd extension.
- β¨β¨β¨β¨β¨β¨β¨β¨
- π½ But let's continue investigation in search for more clues. We may still learn something new about the device or the
- system. We know the hdd model name, so let's display PoFx-registered devices and find our π½πΏ Prod_WDC_PC_SN530_SDB.
- β¨β¨β¨
- 2: kd> !fxdevice π½ display info about all devices registered in Power Management Framework (PoFx)
- ********************************************************************************
- Dumping non-idle PoFx devices
- ********************************************************************************
- !fxdevice 0xffffb005c826bae0
- Device Object: 0xffffb005c5056e10
- DevNode: 0xffffb005c82068a0
- UniqueId: "\_SB.PCI0"
- InstancePath: "ACPI\PNP0A08\0"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F1 - ACTIVE (RefCount = 18)
- !fxdevice 0xffffb005c8272010
- Device Object: 0xffffb005c8294360
- DevNode: 0xffffb005c8211ca0
- UniqueId: "\_SB.PCI0.RP05"
- InstancePath: "PCI\VEN_8086&DEV_34BC&SUBSYS_10521043&REV_30\3&11583659&1&E4"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- !fxdevice 0xffffb005c82a35e0
- Device Object: 0xffffb005c8290360
- DevNode: 0xffffb005c818eca0
- UniqueId: "\_SB.PCI0.RP01"
- InstancePath: "PCI\VEN_8086&DEV_34B8&SUBSYS_10521043&REV_30\3&11583659&1&E0"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F1 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005cc3668a0
- Device Object: 0xffffb005c81ec360
- DevNode: 0xffffb005c820dca0
- UniqueId: "\_SB.PCI0.XHC"
- InstancePath: "PCI\VEN_8086&DEV_34ED&SUBSYS_201F1043&REV_30\3&11583659&1&A0"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005df26c010
- Device Object: 0xffffb005cc33cdc0
- DevNode: 0xffffb005cc33fcb0
- UniqueId: "\_SB.PCI0.XHC.RHUB"
- InstancePath: "USB\ROOT_HUB30\4&36f9711c&0&0"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005df28a050
- Device Object: 0xffffb005cc216050
- DevNode: 0xffffb005c81dcc30
- UniqueId: "\_SB.PCI0.SAT0.PRT0"
- InstancePath: "SCSI\Disk&Ven_WDC&Prod_WD10SPZX-80Z10T2\4&e0fc7e4&0&000000"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005df2a0050 π½π we'll enter this command below
- Device Object: 0xffffb005cc218050
- DevNode: 0xffffb005c50db010
- UniqueId: "\_SB.PCI0.SAT0.NVM3"
- InstancePath: "SCSI\Disk&Ven_NVMe&Prod_WDC_PC_SN530_SDB\4&e0fc7e4&0&030000" π½πΏ found the hdd!
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 63)
- !fxdevice 0xffffb005df5db010
- Device Object: 0xffffb005df556830
- DevNode: 0xffffb005df54f8a0
- UniqueId: "USB\VID_046D&PID_C52B&MI_01\6&1458a8f4&0&0001"
- InstancePath: "USB\VID_046D&PID_C52B&MI_01\6&1458a8f4&0&0001"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 3)
- !fxdevice 0xffffb005df5a7050
- Device Object: 0xffffb005df82f060
- DevNode: 0xffffb005df54fbd0
- UniqueId: "USB\VID_046D&PID_C52B&MI_02\6&1458a8f4&0&0002"
- InstancePath: "USB\VID_046D&PID_C52B&MI_02\6&1458a8f4&0&0002"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 2)
- !fxdevice 0xffffb005dfaad8e0
- Device Object: 0xffffb005df996d60
- DevNode: 0xffffb005c8206bd0
- UniqueId: "\_SB.PR00"
- InstancePath: "ACPI\GenuineIntel_-_Intel64_Family_6_Model_126_-_Intel(R)_Core(TM)_i7-1065G7_CPU_@_1.30GHz\_1"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005dfacbac0
- Device Object: 0xffffb005dfa3a790
- DevNode: 0xffffb005c81e08a0
- UniqueId: "\_SB.PR01"
- InstancePath: "ACPI\GenuineIntel_-_Intel64_Family_6_Model_126_-_Intel(R)_Core(TM)_i7-1065G7_CPU_@_1.30GHz\_2"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005dfab48a0
- Device Object: 0xffffb005dfa3acc0
- DevNode: 0xffffb005c81e0bd0
- UniqueId: "\_SB.PR02"
- InstancePath: "ACPI\GenuineIntel_-_Intel64_Family_6_Model_126_-_Intel(R)_Core(TM)_i7-1065G7_CPU_@_1.30GHz\_3"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005dfabb8a0
- Device Object: 0xffffb005dfa3db60
- DevNode: 0xffffb005c81e18a0
- UniqueId: "\_SB.PR03"
- InstancePath: "ACPI\GenuineIntel_-_Intel64_Family_6_Model_126_-_Intel(R)_Core(TM)_i7-1065G7_CPU_@_1.30GHz\_4"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005dfac88a0
- Device Object: 0xffffb005dfa3dda0
- DevNode: 0xffffb005c81e1bd0
- UniqueId: "\_SB.PR04"
- InstancePath: "ACPI\GenuineIntel_-_Intel64_Family_6_Model_126_-_Intel(R)_Core(TM)_i7-1065G7_CPU_@_1.30GHz\_5"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005dfaae8a0
- Device Object: 0xffffb005dfa48040
- DevNode: 0xffffb005c81e28a0
- UniqueId: "\_SB.PR05"
- InstancePath: "ACPI\GenuineIntel_-_Intel64_Family_6_Model_126_-_Intel(R)_Core(TM)_i7-1065G7_CPU_@_1.30GHz\_6"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005dfa988a0
- Device Object: 0xffffb005dfa48d80
- DevNode: 0xffffb005c81e2bd0
- UniqueId: "\_SB.PR06"
- InstancePath: "ACPI\GenuineIntel_-_Intel64_Family_6_Model_126_-_Intel(R)_Core(TM)_i7-1065G7_CPU_@_1.30GHz\_7"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005dfaba8a0
- Device Object: 0xffffb005dfa4b410
- DevNode: 0xffffb005c81e38a0
- UniqueId: "\_SB.PR07"
- InstancePath: "ACPI\GenuineIntel_-_Intel64_Family_6_Model_126_-_Intel(R)_Core(TM)_i7-1065G7_CPU_@_1.30GHz\_8"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005dfaaf8a0
- Device Object: 0xffffb005c5107c60
- DevNode: 0xffffb005c81e5bd0
- UniqueId: "\_SB.GPI0"
- InstancePath: "ACPI\INT3455\2&daba3ff&1"
- Device Power State: PowerDeviceD0
- Component Count: 11
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 2)
- Component 1: Current:F0/Deepest:F0 - ACTIVE (RefCount = 2)
- Component 2: Current:F0/Deepest:F0 - ACTIVE (RefCount = 2)
- Component 3: Current:F0/Deepest:F0 - ACTIVE (RefCount = 2)
- Component 4: Current:F0/Deepest:F0 - ACTIVE (RefCount = 2)
- Component 5: Current:F0/Deepest:F0 - ACTIVE (RefCount = 2)
- Component 6: Current:F0/Deepest:F0 - ACTIVE (RefCount = 4)
- Component 7: Current:F0/Deepest:F0 - ACTIVE (RefCount = 2)
- Component 8: Current:F0/Deepest:F0 - ACTIVE (RefCount = 2)
- Component 9: Current:F0/Deepest:F0 - ACTIVE (RefCount = 2)
- Component 10: Current:F0/Deepest:F0 - ACTIVE (RefCount = 2)
- !fxdevice 0xffffb005dfae0010
- Device Object: 0xffffb005c828c360
- DevNode: 0xffffb005c826fca0
- UniqueId: "\_SB.PCI0.HECI"
- InstancePath: "PCI\VEN_8086&DEV_34E0&SUBSYS_10521043&REV_30\3&11583659&1&B0"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F1 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005dfadf520
- Device Object: 0xffffb005c8205060
- DevNode: 0xffffb005c8296aa0
- UniqueId: "\_SB.PCI0.HDAS"
- InstancePath: "PCI\VEN_8086&DEV_34C8&SUBSYS_10521043&REV_30\3&11583659&1&FB"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F1 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005e422f820
- Device Object: 0xffffb005c820b360
- DevNode: 0xffffb005c828eca0
- UniqueId: "\_SB.PCI0.PSDC"
- InstancePath: "PCI\VEN_8086&DEV_34F8&SUBSYS_72708086&REV_30\3&11583659&1&A5"
- Device Power State: PowerDeviceD3
- Component Count: 1
- Component 0: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- !fxdevice 0xffffb005e40a6820
- Device Object: 0xffffb005dfb22b50
- DevNode: 0xffffb005e4058b00
- UniqueId: "\_SB.PCI0.I2C1.ETPD"
- InstancePath: "ACPI\ELAN1300\1"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005df948010
- Device Object: 0xffffb005dfb09c00
- DevNode: 0xffffb005dfc2f160
- UniqueId: "INTELAUDIO\DSP_CTLR_DEV_34C8&VEN_8086&DEV_0222&SUBSYS_10521043&REV_0030\4&24c22537&0&0800"
- InstancePath: "INTELAUDIO\DSP_CTLR_DEV_34C8&VEN_8086&DEV_0222&SUBSYS_10521043&REV_0030\4&24c22537&0&0800"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 1)
- !fxdevice 0xffffb005e4d3b560
- Device Object: 0xffffb005df5cc030
- DevNode: 0xffffb005c818aca0
- UniqueId: "\_SB.PCI0.GFX0"
- InstancePath: "PCI\VEN_8086&DEV_8A52&SUBSYS_1B2F1043&REV_07\3&11583659&1&10"
- Device Power State: PowerDeviceD0
- Component Count: 17
- Component 0: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 1: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 2: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 3: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 4: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 5: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 6: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 7: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 8: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 9: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 10: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 11: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 12: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 13: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 14: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 15: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 16: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- !fxdevice 0xffffb005e7ff1a30
- Device Object: 0xffffb005df94d030
- DevNode: 0xffffb005c8271520
- UniqueId: "\_SB.PCI0.RP05.PEGP"
- InstancePath: "PCI\VEN_10DE&DEV_1D16&SUBSYS_1B2F1043&REV_A1\4&38bf707b&0&00E4"
- Device Power State: PowerDeviceD0
- Component Count: 16
- Component 0: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 1: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 2: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 3: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 4: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 5: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 6: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 7: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 8: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 9: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 10: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 11: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 12: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- Component 13: Current:F0/Deepest:F1 - ACTIVE (RefCount = 14)
- Component 14: Current:F0/Deepest:F0 - ACTIVE (RefCount = 3)
- Component 15: Current:F0/Deepest:F1 - ACTIVE (RefCount = 2)
- !fxdevice 0xffffb005e4d76010
- Device Object: 0xffffb005dfb22d80
- DevNode: 0xffffb005dfc2f490
- UniqueId: "\_SB.PCI0.SPI0.FPRT"
- InstancePath: "ACPI\ELAN7001\4&1240dbbf&0"
- Device Power State: PowerDeviceD3
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 3)
- !fxdevice 0xffffb005eb71f010
- Device Object: 0xffffb005df558880
- DevNode: 0xffffb005df549b70
- UniqueId: "USB\VID_046D&PID_C52B&MI_00\6&1458a8f4&0&0000"
- InstancePath: "USB\VID_046D&PID_C52B&MI_00\6&1458a8f4&0&0000"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 4)
- ********************************************************************************
- Dumping idle D0 PoFx devices
- ********************************************************************************
- !fxdevice 0xffffb005dfae0a30
- Device Object: 0xffffb005e47bf050
- DevNode: 0xffffb005e40584a0
- UniqueId: "INTELAUDIO\FUNC_01&VEN_10EC&DEV_0256&SUBSYS_10431052&REV_1000\5&55d82b7&0&0001"
- InstancePath: "INTELAUDIO\FUNC_01&VEN_10EC&DEV_0256&SUBSYS_10431052&REV_1000\5&55d82b7&0&0001"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - IDLE (RefCount = 0)
- !fxdevice 0xffffb005df9b2010
- Device Object: 0xffffb005dfb24530
- DevNode: 0xffffb005dfc1d980
- UniqueId: "INTELAUDIO\FUNC_01&VEN_8086&DEV_280F&SUBSYS_80860101&REV_1000\5&55d82b7&0&0201"
- InstancePath: "INTELAUDIO\FUNC_01&VEN_8086&DEV_280F&SUBSYS_80860101&REV_1000\5&55d82b7&0&0201"
- Device Power State: PowerDeviceD0
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - IDLE (RefCount = 0)
- ********************************************************************************
- Dumping idle non-D0 PoFx devices
- ********************************************************************************
- !fxdevice 0xffffb005dfadea30
- Device Object: 0xffffb005c820f360
- DevNode: 0xffffb005c8294ca0
- UniqueId: "\_SB.PCI0.I2C1"
- InstancePath: "PCI\VEN_8086&DEV_34E9&SUBSYS_10521043&REV_30\3&11583659&1&A9"
- Device Power State: PowerDeviceD3
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - IDLE (RefCount = 0)
- !fxdevice 0xffffb005dfade010
- Device Object: 0xffffb005c820d360
- DevNode: 0xffffb005c8290ca0
- UniqueId: "\_SB.PCI0.I2C0"
- InstancePath: "PCI\VEN_8086&DEV_34E8&SUBSYS_10521043&REV_30\3&11583659&1&A8"
- Device Power State: PowerDeviceD3
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - IDLE (RefCount = 0)
- !fxdevice 0xffffb005e3d9c820
- Device Object: 0xffffb005c81ee360
- DevNode: 0xffffb005c81e8aa0
- UniqueId: "\_SB.PCI0.UA00"
- InstancePath: "PCI\VEN_8086&DEV_34A8&SUBSYS_10521043&REV_30\3&11583659&1&F0"
- Device Power State: PowerDeviceD3
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - IDLE (RefCount = 0)
- !fxdevice 0xffffb005e4285820
- Device Object: 0xffffb005c818e360
- DevNode: 0xffffb005c818caa0
- UniqueId: "\_SB.PCI0.SPI0"
- InstancePath: "PCI\VEN_8086&DEV_34AA&SUBSYS_10521043&REV_30\3&11583659&1&F2"
- Device Power State: PowerDeviceD3
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - IDLE (RefCount = 0)
- !fxdevice 0xffffb005e4dbd010
- Device Object: 0xffffb005dfad8c80
- DevNode: 0xffffb005e40587d0
- UniqueId: "{DD8E82AE-334B-49A2-AEAE-AEB0FD5C40DD}\DetectionVerification\5&55d82b7&0&0"
- InstancePath: "{DD8E82AE-334B-49A2-AEAE-AEB0FD5C40DD}\DetectionVerification\5&55d82b7&0&0"
- Device Power State: PowerDeviceD3
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - IDLE (RefCount = 0)
- π½ ^^ That was a lot of output, but we've found our hdd. Let's check it out.
- β¨β¨β¨
- 2: kd> !fxdevice 0xffffb005df2a0050 π½π enter suggested command from above
- !fxdevice 0xffffb005df2a0050
- Device Object: 0xffffb005cc218050 π½ the device
- DevNode: 0xffffb005c50db010
- UniqueId: "\_SB.PCI0.SAT0.NVM3"
- InstancePath: "SCSI\Disk&Ven_NVMe&Prod_WDC_PC_SN530_SDB\4&e0fc7e4&0&030000" π½πΏ hdd model name
- Device Power State: PowerDeviceD0 π½ power state: D0, fully powered
- PEP Owner: Default PEP
- Acpi Plugin: 0
- Acpi Handle: 0
- Device Status Flags: DevicePowerRequired
- Device Idle Timeout: 0x2cb417800
- Device Power On: No Activity
- Device Power Off: No Activity
- Device Unregister: No Activity
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 63)
- Component Unsatisfied DRIPS Constraint Time: 05:32:41.907
- Pep Component: 0xffffb005df262bf0
- Active: 0 Latency: 0 Residency: 0 Wake: 0 Dx IRP: 0 WW IRP: 0
- Component Idle State Change: No Activity
- Component Activation: No Activity
- Component Active: No Activity
- 2: kd> !devobj 0xffffb005cc218050 π½ the device
- Device object (ffffb005cc218050) is for:
- 0000003e \Driver\iaStorAC DriverObject ffffb005c81d0c60 π½β£οΈ yeah, iaStorAC
- Current Irp 00000000 RefCount 0 Type 00000007 Flags 00001050
- SecurityDescriptor ffff9c8949279860 DevExt ffffb005cc2181a0 DevObjExt ffffb005cc219120 DevNode ffffb005c50db010
- ExtensionFlags (0000000000)
- Characteristics (0x00000180) FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
- AttachedDevice (Upper) ffffb005c5106b00 \Driver\ACPI
- Device queue is not busy.
- π½ Let's see a magic trick, the power of β.
- β¨β¨β¨
- 2: kd> !fxdevice -v 0xffffb005df2a0050 π½π enter suggested command from above, with "-v"
- !fxdevice 0xffffb005df2a0050
- Device Object: 0xffffb005cc218050
- DevNode: 0xffffb005c50db010
- UniqueId: "\_SB.PCI0.SAT0.NVM3"
- InstancePath: "SCSI\Disk&Ven_NVMe&Prod_WDC_PC_SN530_SDB\4&e0fc7e4&0&030000"
- Device Power State: PowerDeviceD0
- PEP Owner: Default PEP
- Acpi Plugin: 0
- Acpi Handle: 0
- Device Status Flags: DevicePowerRequired
- Device Idle Timeout: 0x2cb417800
- Device Power On: No Activity
- Device Power Off: No Activity
- Device Unregister: No Activity
- Component Count: 1
- Component 0: Current:F0/Deepest:F0 - ACTIVE (RefCount = 63)
- Component Unsatisfied DRIPS Constraint Time: 05:32:41.907
- Pep Component: 0xffffb005df262bf0
- Active: 0 Latency: 0 Residency: 0 Wake: 0 Dx IRP: 0 WW IRP: 0
- Component Idle State Change: No Activity
- Component Activation: No Activity
- Component Active: No Activity
- Log has 445938 entries starting at 50: π½ got PoFx log for 64 last events for the device
- # IntTime CPU Cid Tid
- --- ---------------- ---- ---- ----
- π½π this column is InterruptTime (that is, uptime in centums), aka kuser.InterruptTime
- 50 00000504cd2465fb 4 0 0 Power not required from default PEP
- 51 00000504cd2a29e8 3 4 7064 Power required from default PEP
- 52 00000504cd2a29e8 3 4 7064 Device powered
- 53 00000504cdc4c080 6 4 18 Power not required from default PEP
- 54 00000504cdec698b 6 4 7064 Power required from default PEP
- 55 00000504cdec698b 6 4 7064 Device powered
- 56 00000504ce8748cb 0 4 18 Power not required from default PEP
- 57 00000504cec8b90a 6 4 7598 Power required from default PEP
- 58 00000504cec8b90a 6 4 7598 Device powered
- 59 00000504cf633629 3 4 18 Power not required from default PEP
- 60 00000504cfe8666e 6 4 12a0 Power required from default PEP
- 61 00000504cfe8666e 6 4 12a0 Device powered
- 62 00000504cfe9e730 6 0 0 Power not required from default PEP
- 63 00000504d0ea2750 1 4 5558 Power required from default PEP
- 0 00000504d0ea2750 1 4 5558 Device powered
- 1 00000504d0ebac70 1 0 0 Power not required from default PEP
- 2 00000504d0ebac70 1 4 5558 Power required from default PEP
- 3 00000504d0ebac70 1 4 5558 Device powered
- 4 00000504d1848e50 1 4 18 Power not required from default PEP
- 5 00000504d1fe4bf0 6 7c 35c Power required from default PEP
- 6 00000504d1fe4bf0 6 7c 35c Device powered
- 7 00000504d1ffd66f 6 0 0 Power not required from default PEP
- 8 00000504d1ffdabe 2 4 1d0 Power required from default PEP
- 9 00000504d1ffdabe 2 4 1d0 Device powered
- 10 00000504d298f046 7 4 18 Power not required from default PEP
- 11 00000504d3e86e68 4 4 7064 Power required from default PEP
- 12 00000504d3e86e68 4 4 7064 Device powered
- 13 00000504d3e9f857 4 0 0 Power not required from default PEP
- 14 00000504d3e9fcfd 3 4 7064 Power required from default PEP
- 15 00000504d3e9fcfd 3 4 7064 Device powered
- 16 00000504d484bbc7 4 4 18 Power not required from default PEP
- 17 00000504d6d49cb1 6 4 7064 Power required from default PEP
- 18 00000504d6d49cb1 6 4 7064 Device powered
- 19 00000504d6da123e 6 0 0 Power not required from default PEP
- 20 00000504d6da1605 2 4 7064 Power required from default PEP
- 21 00000504d6da1605 2 4 7064 Device powered
- 22 00000504d7735f88 0 4 18 Power not required from default PEP
- 23 00000504d7856111 6 4 7064 Power required from default PEP
- 24 00000504d7856111 6 4 7064 Device powered
- 25 00000504d8209a3c 1 4 18 Power not required from default PEP
- 26 00000504d8ed6265 2 4 e4 Power required from default PEP
- 27 00000504d8ed6265 2 4 e4 Device powered
- 28 00000504d8eec3ab 2 0 0 Power not required from default PEP
- 29 00000504d8eec3ab 2 4 e4 Power required from default PEP
- 30 00000504d8eec3ab 2 4 e4 Device powered
- 31 00000504d937ef65 7 4 4f98 Power IRP requested with status 0
- 32 00000504d937ef65 7 4 4f98 Power IRP type D3 dispatched to device stack
- 33 00000504d93950de 4 4 10c Power IRP completed with status 0
- 34 00000504d93950de 4 4 10c Device power state changed to D3 π½ D3: lowest power state
- 35 0000051e33474576 6 4 7e78 Power IRP requested with status 0 π½ note InterruptTime gap
- 36 0000051e33474576 6 4 7e78 Power IRP type D0 dispatched to device stack
- 37 0000051e3440aeac 6 0 0 Device power state changed to D0 π½ D0: device working state
- 38 0000051e34689268 6 0 0 Power IRP completed with status 0
- 39 0000051e3468e0fe 3 12a4 1710 Power not required from default PEP
- 40 0000051e3468e0fe 2 4 745c Power required from default PEP
- 41 0000051e3468e0fe 2 4 745c Device powered
- 42 0000051e35304f56 2 4 7494 Power IRP requested with status 0
- 43 0000051e35304f56 2 4 7494 Power IRP type D3 dispatched to device stack
- 44 0000051e35311477 4 4 10c Power IRP completed with status 0
- 45 0000051e35311477 4 4 10c Device power state changed to D3 π½ D3: lowest power state
- 46 0000054cae43feb3 1 4 2760 Power IRP requested with status 0 π½ note InterruptTime gap again
- 47 0000054cae43feb3 1 4 2760 Power IRP type D0 dispatched to device stack
- 48 0000054cae7aee1f 1 4 72cc Device power state changed to D0 π½ D0: device working state
- 49 0000054caea24ca6 1 0 0 Power IRP completed with status 0 π½β° note IRP completion InterruptTime
- β¨β¨β¨
- π½ We got ourselves nice PoFx log for the disk device, with exact time of each event.
- The time is in centums (100 ns units) since system boot. SystemTime changes do not affect the InterruptTime while
- system is working. But InterruptTime includes Sleep/Hibernate time (you can sorta conclude that from D3->D0 time gaps).
- If you see this message, you may want to visit the mysterious area is.gd/laboratory_rule38 - just for fun.
- Now, there are generally two ways to get InterruptTime: read its last snapshot from KUSER_SHARED_DATA, or get the
- "precise" time by adding snapshot and the fraction of TSC ticks (rdtsc) elapsed since the last snapshot. For more info,
- see https://ntdoc.m417z.com/kuser_shared_data.
- I don't know if PoFx uses snapshot or the precise InterruptTime for its logs, so let's find out possible error by
- retrieving current clock timer period (how often the Clock Owner Processor updates InterruptTime/SystemTime/TickCount).
- β¨β¨β¨
- 2: kd> dd nt!KeTimeIncrement L1
- fffff801`14efc468 0000270f
- 2: kd> ? 0000270f
- Evaluate expression: 9999 = 00000000`0000270f
- π½ ^^ that's 9999 centums == 999.9 us == 0.9999 ms. This box uses APIC timer with frequency 0.3 MHz, so we may as well
- round up current clock timer period to 1 ms.
- β¨β¨β¨
- 2: kd> !time
- CURRENT TIME:
- System: 01d768b3`64a7f260 (2021 Jun 24 04:42:52.788)
- Interrupt: 0000054c`aea24ca6 (6 days, 17:51:30.552) π½β°π omg, same as the last event above
- Unbiased Interrupt: 000001ba`87a64e35 (2 days, 04:47:45.136)
- 2: kd> ? 0000054caea24ca6-0000054cae7aee1f π½ time elapsed since event 48...
- Evaluate expression: 2580103 = 00000000`00275e87
- 2: kd> ? (0000054caea24ca6-0000054cae7aee1f)/(0n10*0n1000)
- Evaluate expression: 258 = 00000000`00000102 π½ ...is 258 ms
- 2: kd> ? (0000054caea24ca6-0000054cae43feb3)/(0n10*0n1000)
- Evaluate expression: 618 = 00000000`0000026a π½ time since event 46 is 618 ms
- β¨β¨β¨
- π½ So we just learned that current kuser.InterruptTime is β° 0000054caea24ca6, which is the same time as when the
- Power IRP completed for the disk device. I think that's a bit too close. Sure, event 48 says that device power state
- changed to D0 258 ms prior, but still the Power IRP has completed only about right now. π May be there are some edge
- cases in power handling in the Intel iaStorAC.sys driver, which could have prevented disk read request during page-in.
- π½ Let's take one step back and explore what system was doing - how come the disk device received "power on to D0"
- request only 618 ms ago?
- β¨β¨β¨β¨β¨β¨β¨β¨
- 2: kd> !powertriage π½ very nice command, but lot's of errors in output which I had to clean up here
- System Capabilities :
- Machine is not AOAC capable.
- Power Capabilities:
- PopCapabilities @ 0xfffff80114e23e60
- Misc Supported Features: PwrButton SlpButton Lid S3 S4 S5 HiberFile VideoDim
- Processor Features: Thermal
- Disk Features:
- Battery Features: BatteriesPresent
- Battery 0 - Capacity: 0 Granularity: 0
- Battery 1 - Capacity: 0 Granularity: 0
- Battery 2 - Capacity: 0 Granularity: 0
- Wake Caps
- Ac OnLine Wake: Sx
- Soft Lid Wake: Sx
- RTC Wake: S4
- Min Device Wake: Sx
- Default Wake: Sx
- Power Action:
- PopAction :fffff80114e23240 π½π address of _POP_POWER_ACTION
- Current System State..: Hibernate π½ that's weird, hibernate to hibernate?
- Target System State...: Hibernate π½ let's assume one of these states was not updated yet
- State.................: Set System State in progress(3)
- Devices with allocated Power IRPs:
- + PCI\VEN_8086&DEV_8A52&SUBSYS_1B2F1043&REV_07\3&11583659&1&10
- 0xffffb005c826f360 pci D0 !podev FxDevice: !fxdevice !rcdrlogdump
- Upper DO 0xffffb005c54d2720 ACPI !podev
- Upper DO 0xffffb005df5cc030 igfxn SET_POWER_IRP !irp Related Threads SET_POWER_IRP !irp Related Threads !podev
- + USB\VID_046D&PID_C52B\5&139e9f7f&0&3
- 0xffffb005df82ed80 USBHUB3 D0 !podev SET_POWER_IRP !irp Related Threads !rcdrlogdump !wdfdriverinfo !wdflogdump
- Upper DO 0xffffb005c54ce720 ACPI !podev
- Upper DO 0xffffb005df556060 usbccgp !podev !rcdrlogdump
- + USB\VID_046D&PID_C52B&MI_00\6&1458a8f4&0&0000
- 0xffffb005df558880 usbccgp D0 !podev FxDevice: !fxdevice SET_POWER_IRP !irp Related Threads !rcdrlogdump
- Upper DO 0xffffb005df759120 HidUsb !podev
- + HID\VID_046D&PID_C52B&MI_00\7&3da2ba5&0&0000
- 0xffffb005eb60e060 HidUsb D0 !podev WAIT_WAKE_IRP !irp Related Threads
- Upper DO 0xffffb005eb614040 kbdhid !podev
- Upper DO 0xffffb005e4db1060 kbdclass !podev
- + USB\VID_046D&PID_C52B&MI_01\6&1458a8f4&0&0001
- 0xffffb005df556830 usbccgp D0 !podev FxDevice: !fxdevice SET_POWER_IRP !irp Related Threads !rcdrlogdump
- Upper DO 0xffffb005df74d120 HidUsb !podev
- + HID\VID_046D&PID_C52B&MI_01&Col01\7&27b16967&0&0000
- 0xffffb005df7044b0 HidUsb D0 !podev WAIT_WAKE_IRP !irp Related Threads
- Upper DO 0xffffb005df738550 mouhid !podev
- Upper DO 0xffffb005df73b8e0 mouclass !podev
- + USB\VID_046D&PID_C52B&MI_02\6&1458a8f4&0&0002
- 0xffffb005df82f060 usbccgp D0 !podev FxDevice: !fxdevice SET_POWER_IRP !irp Related Threads !rcdrlogdump
- Upper DO 0xffffb005df753120 HidUsb !podev
- + USB\VID_8087&PID_0AAA\5&139e9f7f&0&10
- 0xffffb005df2a2ac0 USBHUB3 D0 !podev SET_POWER_IRP !irp Related Threads !rcdrlogdump !wdfdriverinfo !wdflogdump
- Upper DO 0xffffb005df716290 ACPI !podev
- Upper DO 0xffffb005df573b10 ibtusb !podev
- Upper DO 0xffffb005df739b90 BTHUSB !podev
- + PCI\VEN_10DE&DEV_1D16&SUBSYS_1B2F1043&REV_A1\4&38bf707b&0&00E4
- 0xffffb005c829f120 pci D0 !podev FxDevice: !fxdevice !rcdrlogdump
- Upper DO 0xffffb005c81e8e00 ACPI !podev
- Upper DO 0xffffb005df94d030 nvlddmkm SET_POWER_IRP !irp Related Threads SET_POWER_IRP !irp Related Threads !podev
- + {DD8E82AE-334B-49A2-AEAE-AEB0FD5C40DD}\DetectionVerification\5&55d82b7&0&0
- 0xffffb005dfad8c80 IntcOED D3 !podev FxDevice: !fxdevice WAIT_WAKE_IRP !irp Related Threads
- Upper DO 0xffffb005e81e24c0 WUDFRd !podev !rcdrlogdump !wdfdriverinfo !wdflogdump
- + ACPI\INT3455\2&daba3ff&1
- 0xffffb005c5107c60 ACPI D0 !podev FxDevice: !fxdevice SET_POWER_IRP !irp Related Threads
- Upper DO 0xffffb005dfa56860 iaLPSS2_GPIO2_ICL SET_POWER_IRP !irp Related Threads !podev
- Device Tree Info:
- !devpowerstate
- !devpowerstate Complete
- Links:
- !poaction π½π±οΈ we'll click this
- !cstriage
- !pdctriage
- !pdcclients
- !fxdevice
- !pnptriage
- β¨β¨β¨
- 2: kd> !poaction
- PopAction: fffff80114e23240 π½π address of _POP_POWER_ACTION (same as before)
- State..........: 3 - Set System State π½ okay, that one believable
- Updates........: 0
- Action.........: Sleep π½ confusing; see below for better info
- Lightest State.: Hibernate
- Flags..........: 80000024 OverrideApps|Critical
- Irp minor......: SetPower
- System State...: Hibernate
- Hiber Context..: ffffb005e46dfd70
- Allocated power irps (PopIrpList - fffff80114e239b0)
- IRP: ffffb005efff4010 (set/S0), PDO: ffffb005c5107c60, NOTIFY: ffffb005c81e5c70
- IRP: ffffb005df5f2520 (set/D0,), PDO: ffffb005c5107c60, CURRENT: ffffb005dfa56860
- IRP: ffffb005ed63ca20 (set/S0), PDO: ffffb005c826f360, CURRENT: ffffb005df5cc030, NOTIFY: ffffb005c818ad40
- IRP: ffffb005e41b2360 (set/D0,), PDO: ffffb005c826f360, CURRENT: ffffb005df5cc030
- IRP: ffffb005f3ad5a20 (set/S0), PDO: ffffb005c829f120, CURRENT: ffffb005df94d030, NOTIFY: ffffb005c82715c0
- IRP: ffffb005e41afa20 (set/D0,), PDO: ffffb005c829f120, CURRENT: ffffb005df94d030
- IRP: ffffb005f28c7a20 (set/D0,), PDO: ffffb005df82ed80, CURRENT: ffffb005df82ed80
- IRP: ffffb005f50819e0 (set/D0,), PDO: ffffb005df2a2ac0, CURRENT: ffffb005df2a2ac0
- IRP: ffffb005eb720010 (set/D0,), PDO: ffffb005df558880, CURRENT: ffffb005df558880
- IRP: ffffb005df717930 (set/D0,), PDO: ffffb005df82f060, CURRENT: ffffb005df82f060
- IRP: ffffb005fc1db8a0 (wait-wake/S4), PDO: ffffb005eb60e060
- IRP: ffffb005df705010 (set/D0,), PDO: ffffb005df556830, CURRENT: ffffb005df556830
- IRP: ffffb005f68888a0 (wait-wake/S4), PDO: ffffb005df7044b0
- IRP: ffffb005f02c0250 (wait-wake/S0), PDO: ffffb005dfad8c80
- Irp worker threads (PopIrpThreadList - fffff80114e20960)
- THREAD: ffffb005c510f040 (static)
- THREAD: ffffb005c510e040 (static)
- THREAD: ffffb005f3ae4500 (dynamic)
- THREAD: ffffb005e41cf080 (dynamic), IRP: ffffb005e41afa20, DEVICE: ffffb005df94d030
- THREAD: ffffb005f5478040 (dynamic)
- THREAD: ffffb005f1f13040 (dynamic)
- THREAD: ffffb005f0b74040 (dynamic)
- THREAD: ffffb005eb30a040 (dynamic)
- THREAD: ffffb005f6dd8040 (dynamic)
- THREAD: ffffb005f3cbe040 (dynamic), IRP: ffffb005e41b2360, DEVICE: ffffb005df5cc030
- THREAD: ffffb005f5013080 (dynamic)
- THREAD: ffffb005e9e044c0 (dynamic)
- THREAD: ffffb005f53a8040 (dynamic)
- THREAD: ffffb005cc20b040 (dynamic)
- THREAD: ffffb005eed0e040 (dynamic)
- Broadcast in progress: TRUE
- Is Directed DRIPS Transition: FALSE
- Device State ffffb005c83ec0e0
- Irp minor......: SetPower
- System State...: Working
- Worker thread..: ffffb005ebd76040
- Status.........: 0
- Waking.........: TRUE π½ the system is waking from Hibernation?
- Cancelled......: FALSE
- Ignore errors..: TRUE
- Ignore not imp.: FALSE
- Order: π½ lot's of info in this block, we'll ignore it for now
- Level 4 (ffffb005c83ec240) 0/21 Paged, Root-Enum
- ReadyS0:
- ffffb005c51dcac0: 00000000 \Driver\BasicDisplay
- ffffb005c51ddac0: 00000000 \Driver\Vid
- ffffb005c51deac0: 00000000 \Driver\CompositeBus
- ffffb005c51e0ac0: 00000000 \Driver\vdrvroot
- ffffb005c5111ac0: 00000000 \Driver\umbus
- ffffb005c50b8730: 00000000 \Driver\BasicRender
- ffffb005c50b8a60: 00000000 \Driver\NdisVirtualBus
- ffffb005c5141ac0: 00000000 \Driver\CAD
- ffffb005c50a39f0: 00000000 \Driver\swenum
- ffffb005e4f1a0b0: 00000000 \Driver\RasSstp \Device\NDMP4
- ffffb005e4f1c710: 00000000 \Driver\RasAgileVpn \Device\NDMP5
- ffffb005e4f1b3e0: 00000000 \Driver\Rasl2tp \Device\NDMP6
- ffffb005ea0beb80: 00000000 \Driver\PptpMiniport \Device\NDMP7
- ffffb005e4f1a3e0: 00000000 \Driver\RasPppoe \Device\NDMP8
- ffffb005e4f1f3e0: 00000000 \Driver\NdisWan \Device\NDMP9
- ffffb005ea0c7ac0: 00000000 \Driver\NdisWan \Device\NDMP10
- ffffb005ea0bfac0: 00000000 \Driver\NdisWan \Device\NDMP11
- ffffb005df272c50: 00000000 \Driver\volsnap
- ffffb005df274c50: 00000000 \Driver\volsnap
- ffffb005df28fc40: 00000000 \Driver\volsnap
- ffffb005df26ac50: 00000000 \Driver\volsnap
- Level 3 (ffffb005c83ec1f8) 76/84 Paged, PnP
- WaitSleep:
- ffffb005c81e0940: 00000000 \Driver\intelppm
- ffffb005c81e0c70: 00000000 \Driver\intelppm
- ffffb005c8206c70: 00000000 \Driver\intelppm
- ffffb005c81e1940: 00000000 \Driver\intelppm
- ffffb005c81e2940: 00000000 \Driver\intelppm
- ffffb005c81e1c70: 00000000 \Driver\intelppm
- ffffb005c81e2c70: 00000000 \Driver\intelppm
- ffffb005c81e3940: 00000000 \Driver\intelppm
- ffffb005c81e3c70: 00000000 \Driver\acpipagr
- ffffb005c81e4940: 00000000 \Driver\acpitime
- ffffb005c8271c70: 00000000 \Driver\TPM
- ffffb005c8273c70: 00000000 \Driver\dptf_acpi
- ffffb005c8274940: 00000000 \Driver\dptf_acpi
- ffffb005c820dd40: 00000000 \Driver\USBXHCI \Device\USBFDO-0
- ffffb005c8290d40: 00000000 \Driver\iaLPSS2_I2C_ICL \Device\0000004f
- ffffb005c8294d40: 00000000 \Driver\iaLPSS2_I2C_ICL \Device\00000050
- ffffb005c826fd40: 00000000 \Driver\MEIx64
- ffffb005c828cd40: 00000000 \Driver\vwifibus
- ffffb005c81e8b40: 00000000 \Driver\iaLPSS2_UART2_ICL \Device\00000051
- ffffb005c818cb40: 00000000 \Driver\iaLPSS2_SPI_ICL \Device\00000052
- ffffb005c8296b40: 00000000 \Driver\IntcAudioBus
- ffffb005c81dccd0: 00000000 \Driver\partmgr
- ffffb005c50be0b0: 00000000 \Driver\kbdclass \Device\KeyboardClass1
- ffffb005c82a1170: 00000000 \Driver\dptf_acpi
- ffffb005c82a14a0: 00000000 \Driver\dptf_acpi
- ffffb005c82a17d0: 00000000 \Driver\dptf_acpi
- ffffb005c82a1b00: 00000000 \Driver\dptf_acpi
- ffffb005c820bd40: 00000000 \Driver\WudfRd
- ffffb005cc33fd50: 00000000 \Driver\USBHUB3
- ffffb005dfc24a80: 00000000 \Driver\SoftwareDevice \Device\00000059
- ffffb005e4058ba0: 00000000 \Driver\mshidkmdf \Device\_HID00000003
- ffffb005dfc24750: 00000000 \Driver\SoftwareDevice \Device\0000005a
- ffffb005dfc24420: 00000000 \Driver\SoftwareDevice \Device\0000005b
- ffffb005dfc240f0: 00000000 \Driver\SoftwareDevice \Device\0000005c
- ffffb005dfc2fb90: 00000000 \Driver\SoftwareDevice \Device\0000005d
- ffffb005dfc2f860: 00000000 \Driver\SoftwareDevice \Device\0000005e
- ffffb005e3dee0f0: 00000000 \Driver\SoftwareDevice \Device\00000061
- ffffb005ee1f8a80: 00000000 \Driver\vwifimp \Device\NDMP12
- ffffb005e4f1f0b0: 00000000 \Driver\vwifimp \Device\NDMP3
- ffffb005dfc2f200: 00000000 \Driver\IntcOED \Device\OE_DEVICE
- ffffb005df826d20: 00000000 \Driver\usbccgp \Device\00000041
- ffffb005df5afce0: 00000000 \Driver\BTHUSB
- ffffb005df5b2d10: 00000000 \Driver\usbccgp \Device\0000004d
- ffffb005dfc1dd50: 00000000 \Driver\mshidkmdf \Device\00000066
- ffffb005e3dee420: 00000000 \Driver\mouclass \Device\PointerClass1
- ffffb005dfc1d6f0: 00000000 \Driver\AsusPTPDrv
- ffffb005dfc21cc0: 00000000 \Driver\MTConfig
- ffffb005dfc1da20: 00000000 \Driver\ksthunk \Device\0000006d
- ffffb005e4058540: 00000000 \Driver\ksthunk \Device\0000006b
- ffffb005df54fc70: 00000000 \Driver\HidUsb \Device\_HID00000002
- ffffb005df549c10: 00000000 \Driver\HidUsb \Device\_HID00000004
- ffffb005e4260750: 00000000 \Driver\BthEnum \Device\BthEnum0
- ffffb005e4260a80: 00000000 \Driver\BthEnum \Device\BthEnum1
- ffffb005df54f940: 00000000 \Driver\HidUsb \Device\_HID00000001
- ffffb005e42870f0: 00000000 \Driver\BthPan \Device\NDMP2
- ffffb005e420e0f0: 00000000 \Driver\BthLEEnum
- ffffb005e4235c20: 00000000 \Driver\SoftwareDevice \Device\0000006e
- ffffb005e425c0f0: 00000000 \Driver\SoftwareDevice \Device\0000006f
- ffffb005e425c420: 00000000 \Driver\SoftwareDevice \Device\00000070
- ffffb005e425c750: 00000000 \Driver\SoftwareDevice \Device\00000071
- ffffb005e425ca80: 00000000 \Driver\SoftwareDevice \Device\00000072
- ffffb005e425e0f0: 00000000 \Driver\SoftwareDevice \Device\00000073
- ffffb005e4f24750: 00000000 \Driver\SoftwareDevice \Device\0000007b
- ffffb005e4f1a710: 00000000 \Driver\SoftwareDevice \Device\0000007c
- ffffb005df5b3c20: 00000000 \Driver\HidUsb \Device\0000004b
- ffffb005df5b35c0: 00000000 \Driver\HidUsb \Device\0000004a
- ffffb005df5b60b0: 00000000 \Driver\HidUsb \Device\0000004c
- ffffb005e4f1b710: 00000000 \Driver\kbdclass \Device\KeyboardClass2
- ffffb005df70bc40: 00000000 \Driver\HidUsb \Device\00000047
- ffffb005df72dc80: 00000000 \Driver\mouclass \Device\PointerClass0
- ffffb005df714c40: 00000000 \Driver\HidUsb \Device\00000048
- ffffb005df7130b0: 00000000 \Driver\HidUsb \Device\00000049
- ffffb005dfa71990: 00000000 \Driver\ksthunk \Device\0000009b
- ffffb005e4058870: 00000000 \Driver\WudfRd
- ffffb005c81e02e0: 00000000 \Driver\CmBatt
- ffffb005c81853e0: 00000000 \Driver\CmBatt
- WaitS0:
- ffffb005df99c0f0: 00000000 \Driver\SoftwareDevice \Device\00000054
- ffffb005df9b3300: 00000000 \Driver\SoftwareDevice \Device\00000055
- ffffb005e4f1ea40: 00000000 \Driver\monitor
- ffffb005dfc2f530: 00000000 \Driver\WudfRd
- ffffb005c828ed40: 00000000 \Driver\sdbus \Device\SdBus-HC0
- Level 1 (ffffb005c83ec168) 21/21 Non-Paged, Root-Enum
- WaitSleep:
- ffffb005c51e1ac0: 00000000 \Driver\spaceport \Device\Spaceport
- ffffb005c52e6ac0: 00000000 \Driver\kdnic
- ffffb005e4f11710: 00000000 \Driver\SoftwareDevice \Device\00000079
- ffffb005c50a36c0: 00000000 \Driver\mssmbios
- ffffb005c50d60f0: 00000000 \Driver\rdpbus \Device\RdpBus
- ffffb005e4f0b710: 00000000 \Driver\SoftwareDevice \Device\0000007d
- ffffb005e4f1ca40: 00000000 \Driver\SoftwareDevice \Device\00000082
- ffffb005e4f1aa40: 00000000 \Driver\SoftwareDevice \Device\0000007e
- ffffb005e4f1f710: 00000000 \Driver\SoftwareDevice \Device\0000008c
- ffffb005c510dac0: 00000000 \Driver\volmgr \Device\VolMgrControl
- ffffb005e4f10a40: 00000000 \Driver\SoftwareDevice \Device\0000007f
- ffffb005e4f240f0: 00000000 \Driver\SoftwareDevice \Device\00000081
- ffffb005e9ed7ac0: 00000000 \Driver\SoftwareDevice \Device\0000008f
- ffffb005e4f113e0: 00000000 \Driver\SoftwareDevice \Device\0000008d
- ffffb005e4f11a40: 00000000 \Driver\SoftwareDevice \Device\00000090
- ffffb005ea0c5ac0: 00000000 \Driver\SoftwareDevice \Device\00000091
- ffffb005f9f26b10: 00000000 \Driver\SoftwareDevice \Device\0000009d
- ffffb005df28ec40: 00000000 \Driver\volsnap
- ffffb005df269c90: 00000000 \Driver\volsnap \Device\HarddiskVolumeShadowCopy2
- ffffb005df258c90: 00000000 \Driver\volsnap \Device\HarddiskVolumeShadowCopy3
- ffffb005efe04d60: 00000000 \Driver\volsnap \Device\HarddiskVolumeShadowCopy4
- Level 0 (ffffb005c83ec120) 35/35 Non-Paged, PnP
- WaitSleep:
- ffffb005c51e2ac0: 00000000 \Driver\ACPI_HAL
- ffffb005c553fd10: 00000000 \Driver\UEFI
- ffffb005dfc5f0f0: 00000000 \Driver\UEFI \Device\00000058
- ffffb005c50bf0b0: 00000000 \Driver\ACPI
- ffffb005c81e4c70: 00000000 \Driver\ACPI \Device\0000001d
- ffffb005c8185940: 00000000 \Driver\ACPI \Device\00000020
- ffffb005c8270940: 00000000 \Driver\WmiAcpi
- ffffb005c8270c70: 00000000 \Driver\intelpep
- ffffb005c81e5940: 00000000 \Driver\ACPI \Device\0000001e
- ffffb005c8272c70: 00000000 \Driver\ACPI \Device\00000027
- ffffb005c8185c70: 00000000 \Driver\WmiAcpi
- ffffb005c8272940: 00000000 \Driver\WmiAcpi
- ffffb005c8274c70: 00000000 \Driver\ACPI \Device\0000002b
- ffffb005c8206940: 00000000 \Driver\pci
- ffffb005c8273940: 00000000 \Driver\ACPI \Device\00000028
- ffffb005c8188d40: 00000000 \Driver\pci \Device\NTPNP_PCI0000
- ffffb005c8271940: 00000000 \Driver\ACPI \Device\00000024
- ffffb005c820fd40: 00000000 \Driver\pci \Device\NTPNP_PCI0004
- ffffb005c81eed40: 00000000 \Driver\iaStorAC \Device\RaidPort0
- ffffb005c8224b00: 00000000 \Driver\pci \Device\NTPNP_PCI0018
- ffffb005c81dfb00: 00000000 \Driver\ACPI
- ffffb005c8292b40: 00000000 \Driver\msisadrv
- ffffb005c828ab00: 00000000 \Driver\ACPI \Device\0000002c
- ffffb005c81ceb00: 00000000 \Driver\WmiAcpi
- ffffb005c8183ac0: 00000000 \Driver\WmiAcpi
- ffffb005c82745c0: 00000000 \Driver\ACPI \Device\0000002f
- ffffb005c81e6480: 00000000 \Driver\ACPI \Device\00000030
- ffffb005c82730b0: 00000000 \Driver\ACPI \Device\00000031
- ffffb005c82733e0: 00000000 \Driver\ACPI \Device\00000032
- ffffb005c82090b0: 00000000 \Driver\ACPI \Device\00000033
- ffffb005c82093e0: 00000000 \Driver\ACPI \Device\00000034
- ffffb005c50db0b0: 00000000 \Driver\partmgr
- ffffb005c81850b0: 00000000 \Driver\ACPI \Device\00000037
- ffffb005c8211d40: 00000000 \Driver\pci
- ffffb005c818ed40: 00000000 \Driver\pci
- π½ Some output above was a bit confusing, so let's examine power structures manually.
- β¨β¨β¨
- 2: kd> dt nt!_POP_POWER_ACTION fffff80114e23240 π½π address from above
- +0x000 Updates : 0 ''
- +0x001 State : 0x3 ''
- +0x002 Shutdown : 0 ''
- +0x004 Action : 2 ( PowerActionSleep )
- +0x008 LightestState : 5 ( PowerSystemHibernate )
- +0x00c Flags : 0x80000024
- +0x010 Status : 0n0
- +0x014 DeviceType : 6 ( PolicyImmediateDozeS4 )
- +0x018 DeviceTypeFlags : 0
- +0x01c IrpMinor : 0x2 ''
- +0x01d Waking : 0x1 ''
- +0x020 SystemState : 5 ( PowerSystemHibernate ) π½ okay, so system is "still" in Hibernate state?
- +0x024 NextSystemState : 1 ( PowerSystemWorking ) π½ but the next state should be the Working state
- +0x028 EffectiveSystemState : 5 ( PowerSystemHibernate )
- +0x02c CurrentSystemState : 5 ( PowerSystemHibernate )
- +0x030 ShutdownBugCode : (null)
- +0x038 DevState : 0xffffb005`c83ec0e0 _POP_DEVICE_SYS_STATE π½π±οΈ1
- +0x040 HiberContext : 0xffffb005`e46dfd70 _POP_HIBER_CONTEXT π½π±οΈ2
- +0x048 WakeTime : 0x0000054c`ae3f2d59 π½β we can trust it: InterruptTime when system woke up
- +0x050 SleepTime : 0x0000051e`3539a223 π½π€ InterruptTime when system went to sleep (long ago)
- +0x058 WakeFirstUnattendedTime : 0
- +0x060 WakeAlarmSignaled : 3 ( PoConditionMaximum )
- +0x068 WakeAlarm : [3] <anonymous-tag>
- +0x0b0 WakeAlarmPaused : 0x1 ''
- +0x0b8 WakeAlarmLastTime : 0x0000051d`fe45117d
- +0x0c0 DozeDeferralStartTime : 0x00000504`d8f7d97d
- +0x0c8 FilteredCapabilities : SYSTEM_POWER_CAPABILITIES
- +0x118 WatchdogLock : 0
- +0x120 WatchdogDpc : _KDPC
- +0x160 WatchdogTimer : _KTIMER
- +0x1a0 WatchdogInitialized : 0x1 ''
- +0x1a4 WatchdogState : 2 ( PopPowerActionWatchdogStateResuming )
- +0x1a8 WatchdogStartTime : 0x0000051e`3546dcd0
- +0x1b0 ActionWorkerThread : 0xffffb005`ebd76040 _KTHREAD
- +0x1b8 PromoteActionWorkerThread : (null)
- +0x1c0 UnlockAfterSleepWorkerThread : (null)
- β¨β¨β¨
- 2: kd> !time
- CURRENT TIME:
- System: 01d768b3`64a7f260 (2021 Jun 24 04:42:52.788)
- Interrupt: 0000054c`aea24ca6 (6 days, 17:51:30.552) π½β° current InterruptTime
- Unbiased Interrupt: 000001ba`87a64e35 (2 days, 04:47:45.136)
- 2: kd> ? 0000054c`aea24ca6-0x0000054c`ae3f2d59 π½ delta: current timeβ° - wakeup timeβ
- Evaluate expression: 6496077 = 00000000`00631f4d
- 2: kd> ? (0000054c`aea24ca6-0x0000054c`ae3f2d59)/(0n10*0n1000) π½ yeah, same but in milliseconds
- Evaluate expression: 649 = 00000000`00000289 π½π system has woken up only 649 ms ago!
- β¨β¨β¨
- π½π That's interesting: system has woken up 649 ms ago, then 618 ms ago there was power up request for the device in
- disk stack; 258 ms ago that device state change to D0, but only 0 ms ago (now) the power IRP has completed.
- π½ Let's click some links in the just dumped structure to explore more stuff, just for reference.
- β¨β¨β¨β¨β¨β¨β¨β¨
- 2: kd> dx -id 0,0,ffffb005e91bc040 -r1 ((ntkrnlmp!_POP_DEVICE_SYS_STATE *)0xffffb005c83ec0e0) π½π±οΈ1
- ((ntkrnlmp!_POP_DEVICE_SYS_STATE *)0xffffb005c83ec0e0) : 0xffffb005c83ec0e0 [Type: _POP_DEVICE_SYS_STATE *]
- [+0x000] IrpMinor : 0x2 [Type: unsigned char]
- [+0x004] SystemState : PowerSystemWorking (1) [Type: _SYSTEM_POWER_STATE] π½ this one tells OS is working :)
- [+0x008] SpinLock : 0x0 [Type: unsigned __int64]
- [+0x010] Thread : 0xffffb005ebd76040 [Type: _KTHREAD *]
- [+0x018] AbortEvent : 0x0 [Type: _KEVENT *]
- [+0x020] ReadySemaphore : 0xffffe50a03816db8 [Type: _KSEMAPHORE *]
- [+0x028] FinishedSemaphore : 0xffffe50a03816d98 [Type: _KSEMAPHORE *]
- [+0x030] Order [Type: _PO_DEVICE_NOTIFY_ORDER]
- [+0x1b0] Pending [Type: _LIST_ENTRY]
- [+0x1c0] Status : 0 [Type: long]
- [+0x1c8] FailedDevice : 0x0 [Type: _DEVICE_OBJECT *]
- [+0x1d0] Waking : 0x1 [Type: unsigned char]
- [+0x1d1] Cancelled : 0x0 [Type: unsigned char]
- [+0x1d2] IgnoreErrors : 0x1 [Type: unsigned char]
- [+0x1d3] IgnoreNotImplemented : 0x0 [Type: unsigned char]
- [+0x1d4] TimeRefreshLockAcquired : 0x0 [Type: unsigned char]
- 2: kd> dx -id 0,0,ffffb005e91bc040 -r1 ((ntkrnlmp!_POP_HIBER_CONTEXT *)0xffffb005e46dfd70) π½π±οΈ2
- ((ntkrnlmp!_POP_HIBER_CONTEXT *)0xffffb005e46dfd70) : 0xffffb005e46dfd70 [Type: _POP_HIBER_CONTEXT *]
- [+0x000] Reset : 0x0 [Type: unsigned char]
- [+0x001] HiberFlags : 0x1 [Type: unsigned char]
- [+0x002] WroteHiberFile : 0x1 [Type: unsigned char]
- [+0x003] KernelPhaseVerificationActive : 0x0 [Type: unsigned char]
- [+0x004] InitializationFinished : 0x1 [Type: unsigned char]
- [+0x008] NextTableLockHeld : 0 [Type: long]
- [+0x00c] BootPhaseFinishedBarrier : 0 [Type: long]
- [+0x010] KernelResumeFinishedBarrier : 8 [Type: long]
- [+0x014] HvCaptureReadyBarrier : 0 [Type: long]
- [+0x018] HvCaptureCompletedBarrier : 0 [Type: long]
- [+0x01c] MapFrozen : 0x1 [Type: unsigned char]
- [+0x020] DiscardMap [Type: _RTL_BITMAP]
- [+0x020] KernelPhaseMap [Type: _RTL_BITMAP]
- [+0x030] BootPhaseMap [Type: _RTL_BITMAP]
- [+0x040] ClonedRanges [Type: _LIST_ENTRY]
- [+0x050] ClonedRangeCount : 0x5 [Type: unsigned long]
- [+0x058] ClonedPageCount : 0x6 [Type: unsigned __int64]
- [+0x060] CurrentMap : 0xffffb005e46dfda0 [Type: _RTL_BITMAP *]
- [+0x068] NextCloneRange : 0xffffb005e46dfdb0 [Type: _LIST_ENTRY *]
- [+0x070] NextPreserve : 0x18619e [Type: unsigned __int64]
- [+0x078] LoaderMdl : 0xffffb0060009b000 [Type: _MDL *]
- [+0x080] AllocatedMdl : 0xffffb005fff18c10 [Type: _MDL *]
- [+0x088] PagesOut : 0xa1f0 [Type: unsigned __int64]
- [+0x090] IoPages : 0xffffd3011f748000 [Type: void *]
- [+0x098] IoPagesCount : 0x29 [Type: unsigned long]
- [+0x0a0] CurrentMcb : 0xffffe50a039e3090 [Type: void *]
- [+0x0a8] DumpStack : 0xffffb005eca4b010 [Type: _DUMP_STACK_CONTEXT *]
- [+0x0b0] WakeState : 0xfffff80114eecb90 [Type: _KPROCESSOR_STATE *]
- [+0x0b8] IoProgress : 0xa [Type: unsigned long]
- [+0x0bc] Status : 1073742484 [Type: long]
- [+0x0c0] GraphicsProc : 0x7 [Type: unsigned long]
- [+0x0c8] MemoryImage : 0xffff9c894a010000 [Type: PO_MEMORY_IMAGE *] π½π±οΈ3
- [+0x0d0] PerformanceStats : 0x0 [Type: unsigned long *]
- [+0x0d8] BootLoaderLogMdl : 0xffff9c894a14a000 [Type: _MDL *]
- [+0x0e0] FirmwareRuntimeInformationMdl : 0xffff9c894a14a1a0 [Type: _MDL *]
- [+0x0e8] FirmwareRuntimeInformationVa : 0xffff9c894a029000 [Type: void *]
- [+0x0f0] ResumeContext : 0xffffb005feb97000 [Type: void *]
- [+0x0f8] ResumeContextPages : 0x4 [Type: unsigned long]
- [+0x0fc] SecurePages : 0x0 [Type: unsigned long]
- [+0x100] ProcessorCount : 0x8 [Type: unsigned long]
- [+0x108] ProcessorContext : 0xffffb00600800000 [Type: _POP_PER_PROCESSOR_CONTEXT *]
- [+0x110] ProdConsBuffer : 0xffffb00602c1b000 : "g???" [Type: char *]
- [+0x118] ProdConsSize : 0x190000 [Type: unsigned long]
- [+0x11c] MaxDataPages : 0x10 [Type: unsigned long]
- [+0x120] ExtraBuffer : 0xffffb00600800000 [Type: void *]
- [+0x128] ExtraBufferSize : 0x26ab000 [Type: unsigned __int64]
- [+0x130] ExtraMapVa : 0xffffd3011f66c000 [Type: void *]
- [+0x138] BitlockerKeyPFN : 0x0 [Type: unsigned __int64] π½π π½
- [+0x140] IoInfo [Type: _POP_IO_INFO]
- [+0x1b0] IoChecksums : 0xffffb006012cf000 : "" [Type: wchar_t *]
- [+0x1b8] IoChecksumsSize : 0x194bcd0 [Type: unsigned __int64]
- [+0x1c0] HardwareConfigurationSignature : 0xaacd9f3 [Type: unsigned long]
- [+0x1c4] IumEnabled : 0x0 [Type: unsigned char]
- [+0x1c5] SecureBoot : 0x1 [Type: unsigned char]
- 2: kd> dx -id 0,0,ffffb005e91bc040 -r1 ((ntkrnlmp!PO_MEMORY_IMAGE *)0xffff9c894a010000) π½π±οΈ3
- ((ntkrnlmp!PO_MEMORY_IMAGE *)0xffff9c894a010000) : 0xffff9c894a010000 [Type: PO_MEMORY_IMAGE *]
- [+0x000] Signature : 0x52424948 [Type: unsigned long] π½ 'HIBR'
- [+0x004] ImageType : 0x9 [Type: unsigned long]
- [+0x008] CheckSum : 0x285d [Type: unsigned long]
- [+0x00c] LengthSelf : 0x3e0 [Type: unsigned long]
- [+0x010] PageSelf : 0x2c55b8 [Type: unsigned __int64]
- [+0x018] PageSize : 0x1000 [Type: unsigned long]
- [+0x020] SystemTime : {132689634122483680} [Type: _LARGE_INTEGER]
- [+0x028] InterruptTime : 0x51e3539a223 [Type: unsigned __int64] π½π€ InterruptTime when went to sleep
- [+0x030] FeatureFlags : 0x1fa4efbd9bbfff [Type: unsigned __int64]
- [+0x038] HiberFlags : 0x1 [Type: unsigned char]
- [+0x039] HiberSimulateFlags : 0xca [Type: unsigned char]
- [+0x03a] spare [Type: unsigned char [2]]
- [+0x03c] NoHiberPtes : 0xa [Type: unsigned long]
- [+0x040] HiberVa : 0xffffd3011e7e0000 [Type: unsigned __int64]
- [+0x048] NoFreePages : 0xa1b1 [Type: unsigned long]
- [+0x04c] FreeMapCheck : 0xe249 [Type: unsigned long]
- [+0x050] WakeCheck : 0xc641 [Type: unsigned long]
- [+0x058] NumPagesForLoader : 0x214e6 [Type: unsigned __int64]
- [+0x060] FirstSecureRestorePage : 0x0 [Type: unsigned __int64]
- [+0x068] FirstBootRestorePage : 0x2f [Type: unsigned __int64]
- [+0x070] FirstKernelRestorePage : 0x64cf [Type: unsigned __int64]
- [+0x078] FirstChecksumRestorePage : 0x1555df [Type: unsigned __int64]
- [+0x080] NoChecksumEntries : 0xaaaeb6 [Type: unsigned __int64]
- [+0x088] PerfInfo [Type: _PO_HIBER_PERF]
- [+0x280] FirmwareRuntimeInformationPages : 0x1 [Type: unsigned long]
- [+0x288] FirmwareRuntimeInformation [Type: unsigned __int64 [1]]
- [+0x290] SpareUlong : 0x0 [Type: unsigned long]
- [+0x294] NoBootLoaderLogPages : 0x18 [Type: unsigned long]
- [+0x298] BootLoaderLogPages [Type: unsigned __int64 [24]]
- [+0x358] NotUsed : 0x0 [Type: unsigned long]
- [+0x35c] ResumeContextCheck : 0x4add [Type: unsigned long]
- [+0x360] ResumeContextPages : 0x4 [Type: unsigned long]
- [+0x364] Hiberboot : 0x0 [Type: unsigned char]
- [+0x365] SecureLaunched : 0x0 [Type: unsigned char]
- [+0x366] SecureBoot : 0x1 [Type: unsigned char]
- [+0x368] HvPageTableRoot : 0x0 [Type: unsigned __int64]
- [+0x370] HvEntryPoint : 0x0 [Type: unsigned __int64]
- [+0x378] HvReservedTransitionAddress : 0x0 [Type: unsigned __int64]
- [+0x380] HvReservedTransitionAddressSize : 0x0 [Type: unsigned __int64]
- [+0x388] BootFlags : 0x0 [Type: unsigned __int64]
- [+0x390] RestoreProcessorStateRoutine : 0x0 [Type: unsigned __int64]
- [+0x398] HighestPhysicalPage : 0x47ffff [Type: unsigned __int64]
- [+0x3a0] BitlockerKeyPfns [Type: unsigned __int64 [4]] π½π π½ (all four PFNs are zero)
- [+0x3c0] HardwareSignature : 0xaacd9f3 [Type: unsigned long]
- [+0x3c8] SMBiosTablePhysicalAddress : {1977802752} [Type: _LARGE_INTEGER]
- [+0x3d0] SMBiosTableLength : 0xc12 [Type: unsigned long]
- [+0x3d4] SMBiosMajorVersion : 0x3 [Type: unsigned char]
- [+0x3d5] SMBiosMinorVersion : 0x2 [Type: unsigned char]
- [+0x3d6] HiberResumeXhciHandoffSkip : 0x1 [Type: unsigned char]
- [+0x3d7] InitializeUSBCore : 0x0 [Type: unsigned char]
- [+0x3d8] ValidUSBCoreId : 0x0 [Type: unsigned char]
- [+0x3d9] USBCoreId : 0x0 [Type: unsigned char]
- [+0x3da] SkipMemoryMapValidation : 0x0 [Type: unsigned char]
- π½ Okay, we're done with this section. What else can we check? Let's check callstacks of runningthreads.
- β¨β¨β¨β¨β¨β¨β¨β¨
- 2: kd> !running -t
- System Processors: (00000000000000ff) π½ there are 8 cpus, and 8 threads are running
- Idle Processors: (0000000000000000)
- π½ cpu0: nothing sus
- Prcbs Current (pri) Next (pri) Idle
- 0 fffff8010f533180 ffffb005e8039240 (16) fffff80114f27a00 ................
- # Child-SP RetAddr Call Site
- 00 fffff801`1946de20 fffff801`34e97898 IntcAudioBus+0xb16c
- 01 fffff801`1946de60 fffff801`16ab3ca5 IntcAudioBus+0x27898
- 02 fffff801`1946df00 fffff801`1447e795 Wdf01000!FxInterrupt::_InterruptThunk+0x75 [minkernel\wdf\framework\shared\irphandlers\pnp\km\interruptobjectkm.cpp @ 369]
- 03 fffff801`1946df40 fffff801`145f844f nt!KiCallInterruptServiceRoutine+0xa5
- 04 fffff801`1946df90 fffff801`145f8717 nt!KiInterruptSubDispatch+0x11f
- 05 ffffe509`f8436bb0 fffff801`3500c7ee nt!KiInterruptDispatch+0x37
- 06 ffffe509`f8436d40 fffff801`3500ea46 nvlddmkm+0xcc7ee
- 07 ffffe509`f8436de0 fffff801`350d446c nvlddmkm+0xcea46
- 08 ffffe509`f8436e10 fffff801`350acc9e nvlddmkm+0x19446c
- 09 ffffe509`f8436e40 fffff801`35274d15 nvlddmkm+0x16cc9e
- 0a ffffe509`f8436e70 fffff801`350e79f1 nvlddmkm+0x334d15
- 0b ffffe509`f8436ed0 fffff801`350acbf2 nvlddmkm+0x1a79f1
- 0c ffffe509`f8436f00 fffff801`350aae20 nvlddmkm+0x16cbf2
- 0d ffffe509`f8436fc0 fffff801`350ab05e nvlddmkm+0x16ae20
- 0e ffffe509`f84371c0 fffff801`350ab0fe nvlddmkm+0x16b05e
- 0f ffffe509`f8437220 fffff801`34ff708d nvlddmkm+0x16b0fe
- 10 ffffe509`f84374c0 fffff801`34ff6fff nvlddmkm+0xb708d
- 11 ffffe509`f8437570 fffff801`35753d59 nvlddmkm+0xb6fff
- 12 ffffe509`f84375b0 fffff801`35753fb1 nvlddmkm+0x813d59
- 13 ffffe509`f8437640 fffff801`34f46608 nvlddmkm+0x813fb1
- 14 ffffe509`f84376a0 fffff801`35c70f08 nvlddmkm+0x6608
- 15 ffffe509`f84376f0 fffff801`35b9a0e2 nvlddmkm+0xd30f08
- 16 ffffe509`f8437810 fffff801`2d97212e nvlddmkm+0xc5a0e2
- 17 ffffe509`f84378f0 fffff801`2d82d849 dxgkrnl!ADAPTER_RENDER::DdiUnmapCpuHostAperture+0xba
- 18 ffffe509`f84379a0 fffff801`2ee896f5 dxgkrnl!ADAPTER_RENDER_DdiUnmapCpuHostAperture+0x9
- 19 ffffe509`f84379d0 fffff801`2eefe2c8 dxgmms2!VIDMM_CPU_HOST_APERTURE::UnmapRange+0xad
- 1a ffffe509`f8437a20 fffff801`2eed18af dxgmms2!VIDMM_PAGE_TABLE_BASE::FreeCpuVisibleAddress+0x2a488
- 1b ffffe509`f8437a50 fffff801`2eebfb12 dxgmms2!VIDMM_PAGE_TABLE_BASE::FreeDriverUpdateAddress+0x37
- 1c ffffe509`f8437a80 fffff801`2eefe578 dxgmms2!VIDMM_PAGE_TABLE::UpdatePageTableInvalidate+0x10e
- 1d ffffe509`f8437b50 fffff801`2eed21ad dxgmms2!VIDMM_PAGE_TABLE::CommitVirtualAddressRange+0x2a6a0
- 1e ffffe509`f8437bf0 fffff801`2eefd3bc dxgmms2!VIDMM_PAGE_DIRECTORY::CommitVirtualAddressRange+0x77d
- 1f ffffe509`f8437d60 fffff801`2eed146a dxgmms2!VIDMM_PAGE_DIRECTORY::CommitVirtualAddressRange+0x2b98c
- 20 ffffe509`f8437ed0 fffff801`2ef0e18c dxgmms2!CVirtualAddressAllocator::CommitVirtualAddressRange+0x2f6
- 21 ffffe509`f8438050 fffff801`2eefefe4 dxgmms2!VIDMM_GLOBAL::InitPagingProcessVaSpace+0x187cc
- 22 ffffe509`f84381c0 fffff801`2eeecb52 dxgmms2!VIDMM_GLOBAL::ProcessSystemCommand+0x2a3b0
- 23 ffffe509`f8438340 fffff801`2eef6739 dxgmms2!VIDMM_WORKER_THREAD::Run+0x1462
- 24 ffffe509`f8438520 fffff801`144f53b5 dxgmms2!VidMmWorkerThreadProc+0x9
- 25 ffffe509`f8438550 fffff801`145fe278 nt!PspSystemThreadStartup+0x55
- 26 ffffe509`f84385a0 00000000`00000000 nt!KiStartSystemThread+0x28
- π½ cpu1: nothing sus
- 1 ffffd30119a5c180 ffffb005f534d080 (10) ffffd30119a67240 ................
- # Child-SP RetAddr Call Site
- 00 ffffe50a`027697c0 fffff801`144730e2 nt!ExAcquireSpinLockExclusiveAtDpcLevel+0x2
- 01 ffffe50a`027697d0 fffff801`1440aed9 nt!KiAbEntryRemoveFromTree+0xb2
- 02 ffffe50a`02769860 fffff801`145000ef nt!KeAbPostRelease+0x1e9
- 03 ffffe50a`027698c0 fffff801`147fb4f2 nt!MiZeroSectionObjectPointer+0x33
- 04 ffffe50a`027698f0 fffff801`147faa64 nt!MiCreateImageOrDataSection+0x3b2
- 05 ffffe50a`027699e0 fffff801`14817b32 nt!MiCreateSection+0xf4
- 06 ffffe50a`02769b60 fffff801`14814ca9 nt!MmCreateSpecialImageSection+0xc6
- 07 ffffe50a`02769c10 fffff801`146085b5 nt!NtCreateUserProcess+0x709
- 08 ffffe50a`0276a3d0 00007ffb`b7b6e714 nt!KiSystemServiceCopyEnd+0x25
- 09 0000005f`a977e218 00000000`00000000 0x00007ffb`b7b6e714
- π½ cpu2: that's our current CPU, we've explored this BSOD'ed thread in details already
- 2 ffffd30119b17180 ffffb005df2c8480 (19) ffffd30119b22240 ................
- # Child-SP RetAddr Call Site
- 00 ffffe509`f8198568 fffff801`14794dee nt!KeBugCheckEx
- 01 ffffe509`f8198570 fffff801`14610023 nt!SMKM_STORE<SM_TRAITS>::SmStUnhandledExceptionFilter+0x7e
- 02 ffffe509`f81985c0 fffff801`145cca4f nt!`SMKM_STORE<SM_TRAITS>::SmStDirectReadIssue'::`1'::filt$0+0x22
- 03 ffffe509`f81985f0 fffff801`145ffadf nt!_C_specific_handler+0x9f
- 04 ffffe509`f8198660 fffff801`14487547 nt!RtlpExecuteHandlerForException+0xf
- 05 ffffe509`f8198690 fffff801`14486136 nt!RtlDispatchException+0x297
- 06 ffffe509`f8198db0 fffff801`14608cac nt!KiDispatchException+0x186
- 07 ffffe509`f8199470 fffff801`14604e43 nt!KiExceptionDispatch+0x12c
- 08 ffffe509`f8199650 fffff801`144d10d0 nt!KiPageFault+0x443
- 09 ffffe509`f81997e8 fffff801`144a6bf0 nt!RtlDecompressBufferXpressLz+0x50
- 0a ffffe509`f8199800 fffff801`144a6938 nt!RtlDecompressBufferEx+0x60
- 0b ffffe509`f8199850 fffff801`144a67c5 nt!ST_STORE<SM_TRAITS>::StDmSinglePageCopy+0x150
- 0c ffffe509`f8199910 fffff801`144a5ffc nt!ST_STORE<SM_TRAITS>::StDmSinglePageTransfer+0xa5
- 0d ffffe509`f8199960 fffff801`144a5e2c nt!ST_STORE<SM_TRAITS>::StDmpSinglePageRetrieve+0x180
- 0e ffffe509`f8199a00 fffff801`144a5c79 nt!ST_STORE<SM_TRAITS>::StDmPageRetrieve+0xc8
- 0f ffffe509`f8199ab0 fffff801`144a5b31 nt!SMKM_STORE<SM_TRAITS>::SmStDirectReadIssue+0x85
- 10 ffffe509`f8199b30 fffff801`14498bc8 nt!SMKM_STORE<SM_TRAITS>::SmStDirectReadCallout+0x21
- 11 ffffe509`f8199b60 fffff801`144a368f nt!KeExpandKernelStackAndCalloutInternal+0x78
- 12 ffffe509`f8199bd0 fffff801`14559934 nt!SMKM_STORE<SM_TRAITS>::SmStDirectRead+0xc7
- 13 ffffe509`f8199ca0 fffff801`14559368 nt!SMKM_STORE<SM_TRAITS>::SmStWorkItemQueue+0x1ac
- 14 ffffe509`f8199cf0 fffff801`144a4117 nt!SMKM_STORE_MGR<SM_TRAITS>::SmIoCtxQueueWork+0xc0
- 15 ffffe509`f8199d80 fffff801`144fa96b nt!SMKM_STORE_MGR<SM_TRAITS>::SmPageRead+0x167
- 16 ffffe509`f8199df0 fffff801`1445e0a0 nt!SmPageRead+0x33
- 17 ffffe509`f8199e40 fffff801`1445bb4d nt!MiIssueHardFaultIo+0x10c
- 18 ffffe509`f8199e90 fffff801`14528278 nt!MiIssueHardFault+0x29d
- 19 ffffe509`f8199f50 fffff801`1442a4d2 nt!MmAccessFault+0x468
- 1a ffffe509`f819a0f0 fffff801`14460836 nt!MiDeleteSubsectionPages+0x172
- 1b ffffe509`f819a1b0 fffff801`14808d56 nt!MiDeleteSegmentPages+0x56
- 1c ffffe509`f819a210 fffff801`14584a89 nt!MiSegmentDelete+0x92
- 1d ffffe509`f819a260 fffff801`145ba179 nt!MiProcessDereferenceList+0xc1
- 1e ffffe509`f819a320 fffff801`144f53b5 nt!MiDereferenceSegmentThread+0x129
- 1f ffffe509`f819a550 fffff801`145fe278 nt!PspSystemThreadStartup+0x55
- 20 ffffe509`f819a5a0 00000000`00000000 nt!KiStartSystemThread+0x28
- π½ cpu3: nothing sus
- 3 ffffd30119bd2180 ffffb005f32b7080 ( 9) ffffd30119bdd240 ................
- # Child-SP RetAddr Call Site
- 00 ffffe509`fd17a500 fffff801`167b5b37 FLTMGR!FltpPerformPreCallbacksWorker+0x584
- 01 ffffe509`fd17a620 fffff801`167b4b46 FLTMGR!FltpPassThroughInternal+0xc7
- 02 ffffe509`fd17a670 fffff801`167b48bb FLTMGR!FltpPassThrough+0x1d6
- 03 ffffe509`fd17a710 fffff801`145185b5 FLTMGR!FltpDispatch+0x8b
- 04 ffffe509`fd17a770 fffff801`14428073 nt!IofCallDriver+0x55
- 05 ffffe509`fd17a7b0 fffff801`144dbff0 nt!IoSynchronousPageWriteEx+0x13b
- 06 ffffe509`fd17a7f0 fffff801`14535852 nt!MiIssueSynchronousFlush+0x70
- 07 ffffe509`fd17a870 fffff801`1454b199 nt!MiFlushSectionInternal+0x862
- 08 ffffe509`fd17ab40 fffff801`1468eb7a nt!MmFlushSection+0x155
- 09 ffffe509`fd17abf0 fffff801`144bec7f nt!CcFlushCachePriv+0x1471aa
- 0a ffffe509`fd17ad30 fffff801`181ef81d nt!CcCoherencyFlushAndPurgeCache+0x6f
- 0b ffffe509`fd17ad80 fffff801`181ef6db Ntfs!NtfsCoherencyFlushAndPurgeCache+0x55
- 0c ffffe509`fd17adc0 fffff801`181ef58d Ntfs!NtfsFlushUserStream+0xa3
- 0d ffffe509`fd17ae50 fffff801`181eff72 Ntfs!NtfsPerformOptimisticFlush+0xa1
- 0e ffffe509`fd17aea0 fffff801`181efd19 Ntfs!NtfsCommonFlushBuffers+0x1d6
- 0f ffffe509`fd17afc0 fffff801`14498bc8 Ntfs!NtfsCommonFlushBuffersCallout+0x19
- 10 ffffe509`fd17aff0 fffff801`14498b3d nt!KeExpandKernelStackAndCalloutInternal+0x78
- 11 ffffe509`fd17b060 fffff801`181c7f6b nt!KeExpandKernelStackAndCalloutEx+0x1d
- 12 ffffe509`fd17b0a0 fffff801`181c7e95 Ntfs!NtfsCommonFlushBuffersOnNewStack+0x67
- 13 ffffe509`fd17b110 fffff801`145185b5 Ntfs!NtfsFsdFlushBuffers+0xe5
- 14 ffffe509`fd17b180 fffff801`167b6ccf nt!IofCallDriver+0x55
- 15 ffffe509`fd17b1c0 fffff801`167b48d3 FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x28f
- 16 ffffe509`fd17b230 fffff801`145185b5 FLTMGR!FltpDispatch+0xa3
- 17 ffffe509`fd17b290 fffff801`148e2748 nt!IofCallDriver+0x55
- 18 ffffe509`fd17b2d0 fffff801`14898f19 nt!IopSynchronousServiceTail+0x1a8
- 19 ffffe509`fd17b370 fffff801`14898d06 nt!NtFlushBuffersFileEx+0x1f9
- 1a ffffe509`fd17b400 fffff801`146085b5 nt!NtFlushBuffersFile+0x16
- 1b ffffe509`fd17b440 00007ffb`b7b6d784 nt!KiSystemServiceCopyEnd+0x25
- 1c 0000002e`abe7eb08 00000000`00000000 0x00007ffb`b7b6d784
- π½ cpu4: nothing sus (graphics adapter is waking up); we'll π recheck it in a bit anyway
- 4 ffffd30119c8e180 ffffb005f3cbe040 (13) ffffd30119c99240 ................
- # Child-SP RetAddr Call Site
- 00 ffffe50a`0320fef0 fffff801`310a4cda igdkmdn64+0x315447
- 01 ffffe50a`0320ff00 fffff801`310a0765 igdkmdn64+0x314cda
- 02 ffffe50a`0320ffe0 fffff801`310652ac igdkmdn64+0x310765
- 03 ffffe50a`03210050 fffff801`30dd6a93 igdkmdn64+0x2d52ac
- 04 ffffe50a`03210080 fffff801`30dd9db9 igdkmdn64+0x46a93
- 05 ffffe50a`032100f0 fffff801`30dfb250 igdkmdn64+0x49db9
- 06 ffffe50a`03210120 fffff801`30dfa268 igdkmdn64+0x6b250
- 07 ffffe50a`032101f0 fffff801`30de661c igdkmdn64+0x6a268
- 08 ffffe50a`032102a0 fffff801`30f45618 igdkmdn64+0x5661c
- 09 ffffe50a`032102d0 fffff801`30f453a8 igdkmdn64+0x1b5618
- 0a ffffe50a`03210370 fffff801`30f3cc37 igdkmdn64+0x1b53a8
- 0b ffffe50a`03210620 fffff801`30f3844f igdkmdn64+0x1acc37
- 0c ffffe50a`03210650 fffff801`30f312c8 igdkmdn64+0x1a844f
- 0d ffffe50a`032106a0 fffff801`30f0a7f8 igdkmdn64+0x1a12c8
- 0e ffffe50a`032106d0 fffff801`30ee0787 igdkmdn64+0x17a7f8
- 0f ffffe50a`03210720 fffff801`30ef7578 igdkmdn64+0x150787
- 10 ffffe50a`03210960 fffff801`30dcaf1c igdkmdn64+0x167578
- 11 ffffe50a`03210e10 fffff801`30da0e60 igdkmdn64+0x3af1c
- 12 ffffe50a`03210e40 fffff801`30da1172 igdkmdn64+0x10e60
- 13 ffffe50a`03210e70 fffff801`30d99221 igdkmdn64+0x11172
- 14 ffffe50a`032110c0 fffff801`2d973b6e igdkmdn64+0x9221
- 15 ffffe50a`032111a0 fffff801`2d9730bf dxgkrnl!DpiDxgkDdiSetPowerState+0x5a
- 16 ffffe50a`03211200 fffff801`2d973fee dxgkrnl!DpiFdoSetAdapterPowerState+0x15f
- 17 ffffe50a`032112c0 fffff801`2d973441 dxgkrnl!DpiFdoHandleDevicePower+0x2ee
- 18 ffffe50a`03211360 fffff801`2d974991 dxgkrnl!DpiFdoDispatchPower+0x21
- 19 ffffe50a`03211390 fffff801`1459ce49 dxgkrnl!DpiDispatchPower+0xe1
- 1a ffffe50a`032114b0 fffff801`144f53b5 nt!PopIrpWorker+0x1d9
- 1b ffffe50a`03211550 fffff801`145fe278 nt!PspSystemThreadStartup+0x55
- 1c ffffe50a`032115a0 00000000`00000000 nt!KiStartSystemThread+0x28
- π½ cpu5: π£π£π£ ntfs read error?
- 5 ffffd30119d48180 ffffb005f7fb8080 ( 9) ffffd30119d53240 ................
- # Child-SP RetAddr Call Site
- 00 ffffe509`f7a772c8 fffff801`18f9b252 CLASSPNP!ClasspGetDeviceIdData+0x5
- 01 ffffe509`f7a772d0 fffff801`18f9b04a CLASSPNP!ClasspWriteScsiSrbErrorResultEvent+0x1f2
- 02 ffffe509`f7a77400 fffff801`18f9614f CLASSPNP!ClasspWriteSrbErrorResultEvent+0x22
- 03 ffffe509`f7a77440 fffff801`18f954eb CLASSPNP!ClasspWriteIOResultEvent+0x13f
- 04 ffffe509`f7a77520 fffff801`1450dede CLASSPNP!TransferPktComplete+0x28b
- 05 ffffe509`f7a77730 fffff801`1450dda7 nt!IopfCompleteRequest+0x11e
- 06 ffffe509`f7a77820 fffff801`17df99e1 nt!IofCompleteRequest+0x17
- 07 ffffe509`f7a77850 fffff801`17dfbf8d storport!RaidCompleteRequestEx+0x91
- 08 ffffe509`f7a77920 fffff801`17df9398 storport!RaUnitAsyncError+0x145
- 09 ffffe509`f7a77990 fffff801`17e08f1c storport!RaidUnitCompleteRequest+0xfa8
- 0a ffffe509`f7a77b10 fffff801`145230ce storport!RaidpAdapterRedirectDpcRoutine+0x8c
- 0b ffffe509`f7a77bb0 fffff801`145223b4 nt!KiExecuteAllDpcs+0x30e
- 0c ffffe509`f7a77d20 fffff801`145fdc65 nt!KiRetireDpcList+0x1f4
- 0d ffffe509`f7a77fb0 fffff801`145fda50 nt!KxRetireDpcList+0x5
- 0e ffffe509`fc6ab6a0 fffff801`145fd11e nt!KiDispatchInterruptContinue
- 0f ffffe509`fc6ab6d0 fffff801`180fc56a nt!KiDpcInterrupt+0x2ee π½ (async DPC arrived, error fix "suspended")
- 10 ffffe509`fc6ab860 fffff801`180dd9fa Ntfs!NtfsFixDataError+0x29f5a π½π£ read failed and ntfs tries to fix it
- 11 ffffe509`fc6ab9f0 fffff801`180dc6ff Ntfs!NtfsNonCachedIo+0xaca
- 12 ffffe509`fc6abcb0 fffff801`180da62c Ntfs!NtfsCommonRead+0x1e9f
- 13 ffffe509`fc6abeb0 fffff801`145185b5 Ntfs!NtfsFsdRead+0x1fc
- 14 ffffe509`fc6abf80 fffff801`167b6ccf nt!IofCallDriver+0x55
- 15 ffffe509`fc6abfc0 fffff801`167b48d3 FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x28f
- 16 ffffe509`fc6ac030 fffff801`145185b5 FLTMGR!FltpDispatch+0xa3
- 17 ffffe509`fc6ac090 fffff801`14427e97 nt!IofCallDriver+0x55
- 18 ffffe509`fc6ac0d0 fffff801`1445e04a nt!IoPageReadEx+0x1d7
- 19 ffffe509`fc6ac140 fffff801`1445bb4d nt!MiIssueHardFaultIo+0xb6
- 1a ffffe509`fc6ac190 fffff801`14528278 nt!MiIssueHardFault+0x29d
- 1b ffffe509`fc6ac2a0 fffff801`14604d5e nt!MmAccessFault+0x468
- 1c ffffe509`fc6ac440 00007ffb`b534b028 nt!KiPageFault+0x35e
- 1d 0000008d`37d7cba8 00000000`00000000 0x00007ffb`b534b028
- π½ cpu6: nothing sus
- 6 ffffd30119e03180 ffffb005c589d040 (15) ffffd30119e0e240 ................
- # Child-SP RetAddr Call Site
- 00 ffffe509`f7c2f390 fffff801`14871e58 nt!KeAbPostRelease+0xe2
- 01 ffffe509`f7c2f3f0 fffff801`14871cfc nt!EtwpGetNextGuidEntry+0xd0
- 02 ffffe509`f7c2f440 fffff801`14871bdb nt!EtwpDisableTraceProviders+0x58
- 03 ffffe509`f7c2f490 fffff801`14874ee6 nt!EtwpStopLoggerInstance+0x4b
- 04 ffffe509`f7c2f4d0 fffff801`144f53b5 nt!EtwpLogger+0x386
- 05 ffffe509`f7c2f550 fffff801`145fe278 nt!PspSystemThreadStartup+0x55
- 06 ffffe509`f7c2f5a0 00000000`00000000 nt!KiStartSystemThread+0x28
- π½ cpu7: nothing sus (appears to be a regular hard pagefault)
- 7 ffffd30119ec0180 ffffb005f2605040 ( 9) ffffd30119ecb240 ................
- # Child-SP RetAddr Call Site
- 00 ffffe509`faa82ab0 fffff801`180dc6ff Ntfs!NtfsNonCachedIo+0x124c
- 01 ffffe509`faa82cb0 fffff801`180da62c Ntfs!NtfsCommonRead+0x1e9f
- 02 ffffe509`faa82eb0 fffff801`145185b5 Ntfs!NtfsFsdRead+0x1fc
- 03 ffffe509`faa82f80 fffff801`167b6ccf nt!IofCallDriver+0x55
- 04 ffffe509`faa82fc0 fffff801`167b48d3 FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x28f
- 05 ffffe509`faa83030 fffff801`145185b5 FLTMGR!FltpDispatch+0xa3
- 06 ffffe509`faa83090 fffff801`14427e97 nt!IofCallDriver+0x55
- 07 ffffe509`faa830d0 fffff801`1445e04a nt!IoPageReadEx+0x1d7
- 08 ffffe509`faa83140 fffff801`1445bb4d nt!MiIssueHardFaultIo+0xb6
- 09 ffffe509`faa83190 fffff801`14528278 nt!MiIssueHardFault+0x29d
- 0a ffffe509`faa832a0 fffff801`14604d5e nt!MmAccessFault+0x468
- 0b ffffe509`faa83440 00007ffb`b7b02c62 nt!KiPageFault+0x35e
- 0c 0000008d`cc27cda0 00000000`00000000 0x00007ffb`b7b02c62
- π½π We've learned that CPU5 was running a thread that encountered π£ ntfs read error, and was attempting to fix it.
- But DPC has arrived, so error fix attempt was "paused" for the duration of the DPC.
- Now let's check callstacks of threads which are ready to execute.
- β¨β¨β¨β¨β¨β¨β¨β¨
- 2: kd> !ready 6 π½ using flags "6" to show callstacks
- KSHARED_READY_QUEUE fffff8010f53ba00: (00) ****------------------------------------------------------------
- SharedReadyQueue fffff8010f53ba00: Ready Threads at priority 9
- THREAD ffffb005fa34f040 Cid 077c.80bc Teb: 0000006395787000 Win32Thread: 0000000000000000 READY on processor 80000002
- Impersonation token: ffff9c895df760a0 (Level Impersonation)
- DeviceMap ffff9c89494c6b60
- Owning Process ffffb005e64e60c0 Image: svchost.exe
- Attached Process ffffb005e961a080 Image: taskhostw.exe
- Wait Start TickCount 37292195 Ticks: 0
- Context Switch Count 301 IdealProcessor: 1
- UserTime 00:00:00.000
- KernelTime 00:00:00.031
- Win32 Start Address 0x00007ffbb7b22ad0
- Stack Init ffffe50a011aa5d0 Current ffffe50a011a9090
- Base ffffe50a011ab000 Limit ffffe50a011a4000 Call 0000000000000000
- Priority 9 BasePriority 8 IoPriority 2 PagePriority 5
- Child-SP RetAddr : Call Site
- ffffe50a`011a90d0 fffff801`145fd11e : nt!KxDispatchInterrupt+0x144
- ffffe50a`011a9210 fffff801`14514f2a : nt!KiDpcInterrupt+0x2ee (TrapFrame @ ffffe50a`011a9210)
- ffffe50a`011a93a0 fffff801`14459aaa : nt!RtlRbInsertNodeEx+0xba
- ffffe50a`011a93b0 fffff801`145124c2 : nt!RtlpHpSegPageRangeShrink+0x1ba
- ffffe50a`011a9420 fffff801`14bb3149 : nt!ExFreeHeapPool+0x6b2
- ffffe50a`011a9500 fffff801`148c98fc : nt!ExFreePool+0x9
- ffffe50a`011a9530 fffff801`148c98c9 : nt!ExpFreeTablePagedPool+0x20
- ffffe50a`011a9560 fffff801`148c97b1 : nt!ExpFreeLowLevelTable+0x2d
- ffffe50a`011a9590 fffff801`148cb4ac : nt!ExpFreeHandleTable+0x3d
- ffffe50a`011a95e0 fffff801`148c9380 : nt!ObKillProcess+0x54
- ffffe50a`011a9610 fffff801`1481146e : nt!PspRundownSingleProcess+0x204
- ffffe50a`011a96a0 fffff801`14814fb7 : nt!PspAllocateProcess+0x101e
- ffffe50a`011a9c10 fffff801`146085b5 : nt!NtCreateUserProcess+0xa17
- ffffe50a`011aa3d0 00007ffb`b7b6e714 : nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffffe50a`011aa440)
- 00000063`958fcb08 00000000`00000000 : 0x00007ffb`b7b6e714
- THREAD ffffb005ebe70080 Cid 1454.27b4 Teb: 0000005693c67000 Win32Thread: ffffb005eb62fca0 READY on processor 80000002
- IRP List:
- ffffb005f1160250: (0006,0478) Flags: 00060043 Mdl: ffffb005fffa9d70
- Not impersonating
- DeviceMap ffff9c8947636600
- Owning Process ffffb005e9d230c0 Image: svchost.exe
- Attached Process N/A Image: N/A
- Wait Start TickCount 37292195 Ticks: 0
- Context Switch Count 19953 IdealProcessor: 2
- UserTime 00:00:00.765
- KernelTime 00:00:00.843
- Win32 Start Address 0x00007ffbb741ae80
- Stack Init ffffe509fa0575d0 Current ffffe509fa056630
- Base ffffe509fa058000 Limit ffffe509fa051000 Call 0000000000000000
- Priority 9 BasePriority 8 IoPriority 2 PagePriority 5
- Child-SP RetAddr : Call Site
- ffffe509`fa056670 fffff801`1440c970 : nt!KiSwapContext+0x76
- ffffe509`fa0567b0 fffff801`1440be9f : nt!KiSwapThread+0x500
- ffffe509`fa056860 fffff801`1440b743 : nt!KiCommitThreadWait+0x14f
- ffffe509`fa056900 fffff801`180dd41a : nt!KeWaitForSingleObject+0x233
- ffffe509`fa0569f0 fffff801`180dc6ff : Ntfs!NtfsNonCachedIo+0x4ea
- ffffe509`fa056cb0 fffff801`180da62c : Ntfs!NtfsCommonRead+0x1e9f
- ffffe509`fa056eb0 fffff801`145185b5 : Ntfs!NtfsFsdRead+0x1fc
- ffffe509`fa056f80 fffff801`167b6ccf : nt!IofCallDriver+0x55
- ffffe509`fa056fc0 fffff801`167b48d3 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x28f
- ffffe509`fa057030 fffff801`145185b5 : FLTMGR!FltpDispatch+0xa3
- ffffe509`fa057090 fffff801`14427e97 : nt!IofCallDriver+0x55
- ffffe509`fa0570d0 fffff801`1445e04a : nt!IoPageReadEx+0x1d7
- ffffe509`fa057140 fffff801`1445bb4d : nt!MiIssueHardFaultIo+0xb6
- ffffe509`fa057190 fffff801`14528278 : nt!MiIssueHardFault+0x29d
- ffffe509`fa0572a0 fffff801`14604d5e : nt!MmAccessFault+0x468 π½ pagefault, by now it should be resolved
- ffffe509`fa057440 00007ffb`7ea6d5c0 : nt!KiPageFault+0x35e (TrapFrame @ ffffe509`fa057440)
- 00000056`9437f6a8 00000000`00000000 : 0x00007ffb`7ea6d5c0
- THREAD ffffb005f7c08080 Cid 0754.5688 Teb: 000000fd079e6000 Win32Thread: 0000000000000000 READY on processor 80000003
- IRP List:
- ffffb005f6994a20: (0006,0478) Flags: 00060043 Mdl: ffffb005ee2ebb00
- Not impersonating
- DeviceMap ffff9c894c921810
- Owning Process ffffb005e64ca080 Image: svchost.exe
- Attached Process N/A Image: N/A
- Wait Start TickCount 37292195 Ticks: 0
- Context Switch Count 4541 IdealProcessor: 3
- UserTime 00:00:00.531
- KernelTime 00:00:00.140
- Win32 Start Address 0x00007ffbac7cae30
- Stack Init ffffe50a015645d0 Current ffffe50a01563630
- Base ffffe50a01565000 Limit ffffe50a0155e000 Call 0000000000000000
- Priority 9 BasePriority 8 IoPriority 2 PagePriority 5
- Child-SP RetAddr : Call Site
- ffffe50a`01563670 fffff801`1440c970 : nt!KiSwapContext+0x76
- ffffe50a`015637b0 fffff801`1440be9f : nt!KiSwapThread+0x500
- ffffe50a`01563860 fffff801`1440b743 : nt!KiCommitThreadWait+0x14f
- ffffe50a`01563900 fffff801`180dd41a : nt!KeWaitForSingleObject+0x233
- ffffe50a`015639f0 fffff801`180dc6ff : Ntfs!NtfsNonCachedIo+0x4ea
- ffffe50a`01563cb0 fffff801`180da62c : Ntfs!NtfsCommonRead+0x1e9f
- ffffe50a`01563eb0 fffff801`145185b5 : Ntfs!NtfsFsdRead+0x1fc
- ffffe50a`01563f80 fffff801`167b6ccf : nt!IofCallDriver+0x55
- ffffe50a`01563fc0 fffff801`167b48d3 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x28f
- ffffe50a`01564030 fffff801`145185b5 : FLTMGR!FltpDispatch+0xa3
- ffffe50a`01564090 fffff801`14427e97 : nt!IofCallDriver+0x55
- ffffe50a`015640d0 fffff801`1445e04a : nt!IoPageReadEx+0x1d7
- ffffe50a`01564140 fffff801`1445bb4d : nt!MiIssueHardFaultIo+0xb6
- ffffe50a`01564190 fffff801`14528278 : nt!MiIssueHardFault+0x29d
- ffffe50a`015642a0 fffff801`14604d5e : nt!MmAccessFault+0x468 π½ another pagefault
- ffffe50a`01564440 00007ffb`b5818b5e : nt!KiPageFault+0x35e (TrapFrame @ ffffe50a`01564440)
- 000000fd`07b7f018 00000000`00000000 : 0x00007ffb`b5818b5e
- THREAD ffffb005e637b080 Cid 0408.05d0 Teb: 0000008d3650c000 Win32Thread: 0000000000000000 READY on processor 80000002
- Not impersonating
- DeviceMap ffff9c8947636600
- Owning Process ffffb005e60d6080 Image: svchost.exe
- Attached Process N/A Image: N/A
- Wait Start TickCount 37292195 Ticks: 0
- Context Switch Count 1873 IdealProcessor: 2
- UserTime 00:00:00.078
- KernelTime 00:00:00.000
- Win32 Start Address 0x00007ffbaf489a90
- Stack Init ffffe509f88805d0 Current ffffe509f887fce0
- Base ffffe509f8881000 Limit ffffe509f887a000 Call 0000000000000000
- Priority 9 BasePriority 8 IoPriority 2 PagePriority 5
- Child-SP RetAddr : Call Site
- ffffe509`f887fd20 fffff801`1440c970 : nt!KiSwapContext+0x76
- ffffe509`f887fe60 fffff801`1440be9f : nt!KiSwapThread+0x500
- ffffe509`f887ff10 fffff801`1440b743 : nt!KiCommitThreadWait+0x14f
- ffffe509`f887ffb0 fffff801`1445d988 : nt!KeWaitForSingleObject+0x233
- ffffe509`f88800a0 fffff801`1445bc75 : nt!MiWaitForInPageComplete+0x1f8
- ffffe509`f8880190 fffff801`14528278 : nt!MiIssueHardFault+0x3c5
- ffffe509`f88802a0 fffff801`14604d5e : nt!MmAccessFault+0x468 π½ and another
- ffffe509`f8880440 00007ffb`b7afca51 : nt!KiPageFault+0x35e (TrapFrame @ ffffe509`f8880440)
- 0000008d`36eff430 00000000`00000000 : 0x00007ffb`b7afca51
- THREAD ffffb005f36e3080 Cid 0408.6fbc Teb: 0000008d36574000 Win32Thread: 0000000000000000 READY on processor 80000003
- Not impersonating
- DeviceMap ffff9c8947636600
- Owning Process ffffb005e60d6080 Image: svchost.exe
- Attached Process N/A Image: N/A
- Wait Start TickCount 37292195 Ticks: 0
- Context Switch Count 1 IdealProcessor: 3
- UserTime 00:00:00.000
- KernelTime 00:00:00.000
- Win32 Start Address 0x00007ffbb7b22ad0
- Stack Init ffffe509fe60d5d0 Current ffffe509fe60cce0
- Base ffffe509fe60e000 Limit ffffe509fe607000 Call 0000000000000000
- Priority 9 BasePriority 8 Priority Floor 9 IoPriority 2 PagePriority 5
- Child-SP RetAddr : Call Site
- ffffe509`fe60cd20 fffff801`1440c970 : nt!KiSwapContext+0x76
- ffffe509`fe60ce60 fffff801`1440be9f : nt!KiSwapThread+0x500
- ffffe509`fe60cf10 fffff801`1440b743 : nt!KiCommitThreadWait+0x14f
- ffffe509`fe60cfb0 fffff801`1445d988 : nt!KeWaitForSingleObject+0x233
- ffffe509`fe60d0a0 fffff801`1445bc75 : nt!MiWaitForInPageComplete+0x1f8
- ffffe509`fe60d190 fffff801`14528278 : nt!MiIssueHardFault+0x3c5
- ffffe509`fe60d2a0 fffff801`14604d5e : nt!MmAccessFault+0x468 π½ fourth page fault
- ffffe509`fe60d440 00007ffb`b7b1836e : nt!KiPageFault+0x35e (TrapFrame @ ffffe509`fe60d440)
- 0000008d`39cff680 00000000`00000000 : 0x00007ffb`b7b1836e
- SharedReadyQueue fffff8010f53ba00: Ready Threads at priority 8
- THREAD ffffb005ea032080 Cid 1368.158c Teb: 0000009371b65000 Win32Thread: 0000000000000000 READY on processor 80000003
- Not impersonating
- DeviceMap ffff9c8947636600
- Owning Process ffffb005e9ce2080 Image: ICEsoundService64.exe
- Attached Process N/A Image: N/A
- Wait Start TickCount 37292195 Ticks: 0
- Context Switch Count 794952 IdealProcessor: 3
- UserTime 00:00:01.265
- KernelTime 00:00:09.031
- Win32 Start Address 0x00007ff7c4ccfd40
- Stack Init ffffe509fa8c75d0 Current ffffe509fa8c7200
- Base ffffe509fa8c8000 Limit ffffe509fa8c1000 Call 0000000000000000
- Priority 8 BasePriority 8 IoPriority 2 PagePriority 5
- Child-SP RetAddr : Call Site
- ffffe509`fa8c7240 fffff801`145451db : nt!KiSwapContext+0x76
- ffffe509`fa8c7380 fffff801`1490408f : nt!KeDelayExecutionThread+0x37b
- ffffe509`fa8c7410 fffff801`146085b5 : nt!NtDelayExecution+0x5f
- ffffe509`fa8c7440 00007ffb`b7b6d4a4 : nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffffe509`fa8c7440)
- 00000093`71ff74a8 00000000`00000000 : 0x00007ffb`b7b6d4a4
- Processor 0: No threads in READY state
- Processor 1: No threads in READY state
- Processor 2: No threads in READY state
- Processor 3: No threads in READY state
- KSHARED_READY_QUEUE ffffd30119c96a00: (00) ----****--------------------------------------------------------
- SharedReadyQueue ffffd30119c96a00: Ready Threads at priority 7
- THREAD ffffb005f4ea80c0 Cid 0a9c.6114 Teb: 0000007e2165e000 Win32Thread: 0000000000000000 READY on processor 80000005
- Not impersonating
- DeviceMap ffff9c8947636600
- Owning Process ffffb005e6710080 Image: taskhostw.exe
- Attached Process N/A Image: N/A
- Wait Start TickCount 37292195 Ticks: 0
- Context Switch Count 23 IdealProcessor: 0
- UserTime 00:00:00.000
- KernelTime 00:00:00.000
- Win32 Start Address 0x00007ffbb7b22ad0
- Stack Init ffffe509fafaf5d0 Current ffffe509fafaf2c0
- Base ffffe509fafb0000 Limit ffffe509fafa9000 Call 0000000000000000
- Priority 7 BasePriority 6 IoPriority 2 PagePriority 5
- Child-SP RetAddr : Call Site
- ffffe509`fafaf300 fffff801`145fd11e : nt!KxDispatchInterrupt+0x144
- ffffe509`fafaf440 00007ffb`b7ae2cb9 : nt!KiDpcInterrupt+0x2ee (TrapFrame @ ffffe509`fafaf440)
- 0000007e`21c7f458 00000000`00000000 : 0x00007ffb`b7ae2cb9
- Processor 4: Ready Threads at priority 12
- THREAD ffffb005f6dcf040 Cid 0004.63b4 Teb: 0000000000000000 Win32Thread: 0000000000000000 READY on processor 4
- Not impersonating
- DeviceMap ffff9c8947636600
- Owning Process ffffb005c509f100 Image: System
- Attached Process N/A Image: N/A
- Wait Start TickCount 37292192 Ticks: 3 (0:00:00:00.046)
- Context Switch Count 174 IdealProcessor: 4 NoStackSwap
- UserTime 00:00:00.000
- KernelTime 00:00:00.000
- Win32 Start Address nt!ExpWorkerThread (0xfffff80114541120)
- Stack Init ffffe50a035495d0 Current ffffe50a03548a50
- Base ffffe50a0354a000 Limit ffffe50a03543000 Call 0000000000000000
- Priority 12 BasePriority 12 IoPriority 2 PagePriority 5
- Child-SP RetAddr : Call Site
- ffffe50a`03548a90 fffff801`14414232 : nt!KiSwapContext+0x76
- ffffe50a`03548bd0 fffff801`1449240a : nt!KiProcessDeferredReadyList+0x112
- ffffe50a`03548c10 fffff801`145753b3 : nt!KeSetSystemGroupAffinityThread+0x13a
- ffffe50a`03548c80 fffff801`1457527c : nt!KiAcquireInterruptConnectLock+0x43
- ffffe50a`03548cc0 fffff801`145750d9 : nt!KiConnectInterrupt+0x90
- ffffe50a`03548d30 fffff801`1494ea8c : nt!KeConnectInterrupt+0x5d
- ffffe50a`03548d90 fffff801`1494e341 : nt!IopConnectInterrupt+0x330
- ffffe50a`03548ee0 fffff801`16ac7691 : nt!IoConnectInterruptEx+0x1e1
- ffffe50a`03548fd0 fffff801`16ac7520 : Wdf01000!FxInterrupt::ConnectInternal+0xd5 [minkernel\wdf\framework\shared\irphandlers\pnp\km\interruptobjectkm.cpp @ 174]
- ffffe50a`03549050 fffff801`16ac74af : Wdf01000!FxInterrupt::Connect+0x5c [minkernel\wdf\framework\shared\irphandlers\pnp\interruptobject.cpp @ 1187]
- ffffe50a`035490e0 fffff801`16ac7403 : Wdf01000!FxPkgPnp::NotifyResourceObjectsD0+0x5b [minkernel\wdf\framework\shared\irphandlers\pnp\fxpkgpnp.cpp @ 6437]
- ffffe50a`03549140 fffff801`16ac25f6 : Wdf01000!FxPkgPnp::PowerWakingConnectInterrupt+0x13 [minkernel\wdf\framework\shared\irphandlers\pnp\powerstatemachine.cpp @ 3653]
- ffffe50a`035491a0 fffff801`16ac23aa : Wdf01000!FxPkgPnp::PowerEnterNewState+0x156 [minkernel\wdf\framework\shared\irphandlers\pnp\powerstatemachine.cpp @ 1699]
- ffffe50a`03549300 fffff801`16ac1ad8 : Wdf01000!FxPkgPnp::PowerProcessEventInner+0xea [minkernel\wdf\framework\shared\irphandlers\pnp\powerstatemachine.cpp @ 1615]
- ffffe50a`03549380 fffff801`16ac6793 : Wdf01000!FxPkgPnp::_PowerProcessEventInner+0x68 [minkernel\wdf\framework\shared\irphandlers\pnp\powerstatemachine.cpp @ 1447]
- ffffe50a`035493c0 fffff801`16ac66ec : Wdf01000!FxEventQueue::EventQueueWorker+0x9b [minkernel\wdf\framework\shared\irphandlers\pnp\eventqueue.cpp @ 279]
- ffffe50a`03549410 fffff801`144748e5 : Wdf01000!FxThreadedEventQueue::_WorkItemCallback+0xc [minkernel\wdf\framework\shared\irphandlers\pnp\eventqueue.cpp @ 437]
- ffffe50a`03549440 fffff801`14541225 : nt!IopProcessWorkItem+0x135
- ffffe50a`035494b0 fffff801`144f53b5 : nt!ExpWorkerThread+0x105
- ffffe50a`03549550 fffff801`145fe278 : nt!PspSystemThreadStartup+0x55
- ffffe50a`035495a0 00000000`00000000 : nt!KiStartSystemThread+0x28
- Processor 5: No threads in READY state
- Processor 6: No threads in READY state
- Processor 7: No threads in READY state
- π½ I can't say ready-threads look sus. Four pagefaults are fine.
- But let's go back CPU4 and π recheck what it was doing. In the original analysis it was stated that this thread is
- closely related to the BSOD - and that made me really, really angry πΉ.
- β¨β¨β¨β¨β¨β¨β¨β¨
- 2: kd> ~s4 π½ switch to CPU4
- 4: kd> !thread -1 π½ display current thread info with callstack (notice "4:" instead of "2:")
- THREAD ffffb005f3cbe040 Cid 0004.8114 Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 4
- Not impersonating
- DeviceMap ffff9c8947636600
- Owning Process ffffb005c509f100 Image: System
- Attached Process N/A Image: N/A
- Wait Start TickCount 37292189 Ticks: 6 (0:00:00:00.093)
- Context Switch Count 171 IdealProcessor: 6 π½ ctx switches count is a bit more than expected
- UserTime 00:00:00.000
- KernelTime 00:00:00.312 π½ thread total runtime is only 312 ms (really, 0x14 osticks)
- Win32 Start Address nt!PopIrpWorker (0xfffff8011459cc70)
- Stack Init ffffe50a032115d0 Current ffffe50a0320fbe0
- Base ffffe50a03212000 Limit ffffe50a0320b000 Call 0000000000000000
- Priority 13 BasePriority 13 IoPriority 2 PagePriority 5
- 4: kd> ?? @$thread->CreateTime π½ check thread creation time
- union _LARGE_INTEGER π½ (was really silly to use SystemTime here, should have been InterruptTime)
- 0x01d7686b`8d8cc02a
- +0x000 LowPart : 0x8d8cc02a
- +0x004 HighPart : 0n30894187
- +0x000 u : <anonymous-tag>
- +0x000 QuadPart : 0n132689525176320042 π½ use this...
- 4: kd> .formats 0n132689525176320042 π½ ...here
- Evaluate expression:
- Hex: 01d7686b`8d8cc02a
- Decimal: 132689525176320042
- Decimal (unsigned) : 132689525176320042
- Octal: 0007273206561543140052
- Binary: 00000001 11010111 01101000 01101011 10001101 10001100 11000000 00101010
- Chars: ..hk...*
- Time: Wed Jun 23 20:08:37.632 2021 (UTC + 0:00) π½ ok, got thread creation time
- Float: low -8.67443e-031 high 7.91284e-038
- Double: 8.73829e-300
- 4: kd> !time
- CURRENT TIME:
- System: 01d768b3`64a7f260 (2021 Jun 24 04:42:52.788) π½ ...so thread was created long ago
- Interrupt: 0000054c`aea24ca6 (6 days, 17:51:30.552)
- Unbiased Interrupt: 000001ba`87a64e35 (2 days, 04:47:45.136)
- 4: kd> kv π½ dump callstack, with "Args to Child"
- # Child-SP RetAddr : Args to Child : Call Site
- 00 ffffe50a`0320fef0 fffff801`310a4cda : 00000000`000c7200 00000000`00000000 ffffb005`df8c7224 00000000`00000000 : igdkmdn64+0x315447
- 01 ffffe50a`0320ff00 fffff801`310a0765 : 00000000`000c7200 00000000`00000000 ffff3b03`42fdcfb2 ffffb005`df872000 : igdkmdn64+0x314cda
- 02 ffffe50a`0320ffe0 fffff801`310652ac : 00000000`00000000 ffffe50a`03210189 ffffb005`dfc5add0 00000000`00000000 : igdkmdn64+0x310765
- 03 ffffe50a`03210050 fffff801`30dd6a93 : 00000000`00000000 ffffe50a`03210189 ffffb005`00000000 ffffb005`df872000 : igdkmdn64+0x2d52ac
- 04 ffffe50a`03210080 fffff801`30dd9db9 : ffffe50a`03210190 fffff801`1441f670 00000000`00064040 fffff801`310a08ec : igdkmdn64+0x46a93
- 05 ffffe50a`032100f0 fffff801`30dfb250 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : igdkmdn64+0x49db9
- 06 ffffe50a`03210120 fffff801`30dfa268 : 00000000`00040300 00000000`00000000 00000000`00000001 fffff801`30dd9db9 : igdkmdn64+0x6b250
- 07 ffffe50a`032101f0 fffff801`30de661c : ffffe50a`032102f0 00000000`00000000 00000000`00000000 ffffe50a`032102f0 : igdkmdn64+0x6a268
- 08 ffffe50a`032102a0 fffff801`30f45618 : 00000000`00000000 ffffb005`c9e0b350 ffffe50a`03210420 fffff801`30dd77e8 : igdkmdn64+0x5661c
- 09 ffffe50a`032102d0 fffff801`30f453a8 : ffffb005`e4dfcc00 ffffe50a`03210470 ffffb005`c9e0b210 ffffb005`e4f85b20 : igdkmdn64+0x1b5618
- 0a ffffe50a`03210370 fffff801`30f3cc37 : 00000000`00000000 00000000`00000000 00000000`00000000 ffffb005`e4f85b20 : igdkmdn64+0x1b53a8
- 0b ffffe50a`03210620 fffff801`30f3844f : 00000000`00000000 ffffb005`df7c0410 ffffb005`df7c0410 ffffb005`e4f85b20 : igdkmdn64+0x1acc37
- 0c ffffe50a`03210650 fffff801`30f312c8 : 00000000`00000000 ffffb005`df7c0410 ffffb005`c9e0b200 fffff801`14e51b70 : igdkmdn64+0x1a844f
- 0d ffffe50a`032106a0 fffff801`30f0a7f8 : ffffb005`c9e0b200 ffffb005`c9e0b200 ffffb005`c9d80000 00000000`00000000 : igdkmdn64+0x1a12c8
- 0e ffffe50a`032106d0 fffff801`30ee0787 : ffffe50a`03210820 ffffb005`c9d80000 00000000`00000008 fffff801`14e50b00 : igdkmdn64+0x17a7f8
- 0f ffffe50a`03210720 fffff801`30ef7578 : ffffb005`e4ef9cb0 ffffb005`e4ef9cb0 ffffb005`dfc5add0 ffffb005`e4f37090 : igdkmdn64+0x150787
- 10 ffffe50a`03210960 fffff801`30dcaf1c : ffffe50a`03210e70 000002ee`00000003 ffffe50a`03210e70 fffff801`30dbeaf9 : igdkmdn64+0x167578
- 11 ffffe50a`03210e10 fffff801`30da0e60 π : 00000003`00000001 00000000`c0000001 fffff801`311f56c0 00000000`00000000 : igdkmdn64+0x3af1c
- 12 ffffe50a`03210e40 fffff801`30da1172 : 00000003`00000001 ffffb005`df872000 00000000`00000000 fffff801`311f5830 : igdkmdn64+0x10e60
- 13 ffffe50a`03210e70 fffff801`30d99221 : ffffb005`df870407 00000000`00000002 ffffb005`df872000 ffffb005`df872000 : igdkmdn64+0x11172
- 14 ffffe50a`032110c0 fffff801`2d973b6e : 464c3635`314d4c00 11000a34`ffffffff ffffb005`df5cc030 00000001`00000780 : igdkmdn64+0x9221
- 15 ffffe50a`032111a0 fffff801`2d9730bf : 00000000`00000005 ffffe50a`03211261 00000000`00000000 ffffb005`df5cc180 : dxgkrnl!DpiDxgkDdiSetPowerState+0x5a
- 16 ffffe50a`03211200 fffff801`2d973fee : 00000000`00000000 ffffb005`e41b2360 00000000`00000001 00000000`00000001 : dxgkrnl!DpiFdoSetAdapterPowerState+0x15f
- 17 ffffe50a`032112c0 fffff801`2d973441 : 00000000`40190000 00000000`00000000 fffff801`19452000 ffffb005`e41b2550 : dxgkrnl!DpiFdoHandleDevicePower+0x2ee
- 18 ffffe50a`03211360 fffff801`2d974991 : ffffb005`e41b2360 ffffb005`df5cc180 ffffb005`df5cc030 ffffe50a`03211480 : dxgkrnl!DpiFdoDispatchPower+0x21
- 19 ffffe50a`03211390 fffff801`1459ce49 : ffffb005`f3cbe040 ffffb005`00000000 ffffb005`f3cbe040 ffffb005`00000001 : dxgkrnl!DpiDispatchPower+0xe1
- 1a ffffe50a`032114b0 fffff801`144f53b5 : ffffffff`fa0a1f00 fffff801`1459cc70 ffffb005`f49f9430 00000000`00000092 : nt!PopIrpWorker+0x1d9
- 1b ffffe50a`03211550 fffff801`145fe278 : fffff801`0f533180 ffffb005`f3cbe040 fffff801`144f5360 7e7e7e7e`7f7f7f7f : nt!PspSystemThreadStartup+0x55
- 1c ffffe50a`032115a0 00000000`00000000 : ffffe50a`03212000 ffffe50a`0320b000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x28
- β¨β¨β¨β¨β¨β¨β¨β¨
- π½ Now, the rant about homeparams (args to child) and 0xC0000001 in the frame 0x11 π in the original analysis. It was
- claimed that the thread runs deep inside igdkmdn64, does some setup, and returns an error, which is shown in frame 0x11:
- 0xC0000001, STATUS_UNSUCCESSFUL. I believe that claim is incorrect.
- π½ First, the thread is still running. It's running some igdkmdn64 code right now.
- And it has only run (in total) for about 312 ms, which is not that much - considering the thread was created even
- before the wakeup from hibernation, and the wakeup itself happened 649 ms ago. Since Intel igdkmdn64 routines are still
- executing, it is premature to say anything about returned values!
- π½ Second, the value 0xC0000001 is situated in HOMEPARAMS. It's the 0x20-byte space right next to the return address,
- required by the x64 ABI. Unless the program was compiled with `/homeparams` (rare), there can be any trash in there.
- Most often compiler uses this space to save some unrelated non-volatile registers, or just leaves the space (or part of
- it) non-initialized. It's especially non-deterministic in kernel mode, where interrupts can use the same stack as
- currently running thread - thus any random ISR may put any random value on stack (while that space is still free ofc).
- π½ So without examining disasm and determining where the value came from, in almost all cases it's absolutely useless
- to examine the "Args to Child" block on x64. May as well run `dps @rsp L6000/8` and pick any "error" value from there.
- <end of rant>
- π Verdict: nothing sus about igdkmdn64 in this case.
- β¨β¨β¨β¨β¨β¨β¨β¨
- I think we're almost done. But since I'm planning to fingerpoint at storage driver issues, let's check interesting set
- of storage-related commands.
- 4: kd> !storagekd.storhelp π½ like the power-related commands, `storagekd` is really well-made extension
- Storage Debugger Extension
- ===============================================
- General Commands
- ----------------
- !storhelp - Displays complete help of the commands provided in this KD extension
- !storclass - Dumps all class devices managed by classpnp
- !storadapter - Dumps all adapters managed by Storport
- !storunit - Dumps all disks managed by Storport
- STORPORT specific commands
- --------------------------
- !storlogirp <args> - displays internal log entries that reference the specified IRP.
- See '!storhelp storlogirp' for details.
- !storloglist <args> - displays internal log entries. See '!storhelp storloglist' for details.
- !storlogsrb <args> - displays internal log entries that reference the specified SRB.
- See '!storhelp storlogsrb' for details.
- !storsrb <address> - display details for the specified SCSI or STORAGE request block
- STORPORT commands for NVMeoF functionality
- ------------------------------------------
- !nvmeofhg <host gateway address> - displays information about a NVMeoF Initiator Host Gateway
- !nvmeofsp <subsystem port address> - displays information about a NVMeoF Initiator Subsystem Port
- !nvmeofct <nvme controller address> - displays information about a NVMe Controllers
- STORPORT commands for NVMe functionality
- ----------------------------------------
- !stornamespace <nvme namespace address> - displays information about a NVMe Namespace
- !stornvmequeueslots <nvme queue address> - displays information about non-empty slots in a NVMe queue
- !stornvmequeuerequests <nvme queue address> - displays information about outstanding requests in a NVMe queue
- β¨β¨β¨
- π½ Since we've run `!storagekd.storhelp`, the `storagekd` built-in extension is now loaded, and its commands became
- available without `!storagekd.` prefix. So I'll be skipping the prefix.
- 4: kd> !storclass
- Storage Class Devices
- Usage Legend: B = Boot, P = Paging, D = Dump, H = Hiber, R = Removable
- FDO # Device ID Usage UP DN FL π½π "FL" is for FaiLures
- -------------------------------------------------------------------------------
- ffffb005df271170 [1,2] 0 WDC WD10SPZX-80Z10T2 ? ? 0
- ffffb005df273060 [1,2] 1 WDC PC SN530 SDBPNPZ-256G-1002 BPDH ? ? 16 π½ππΏ 16 fails for our drive!
- Usage: !storclass <class device> <level [0-2]>
- !storclass 0 <level [1-2]> to display summary with upper-level and down-level IRP counts
- Optical devices, such as DVD drives, can be listed with !wdfkd.wdfdriverinfo cdrom, and further explored
- using the "!wdfkd.wdfdevice <device_handle>" and "!wdfkd.wdfdevicequeues <device_handle>" commands.
- β¨β¨β¨
- 4: kd> !storagekd.storclass ffffb005df273060 π½ππΏ explore our device
- Storage class device ffffb005df273060 with extension at ffffb005df2731b0
- Classpnp Internal Information at ffffb005df299040
- Failed Requests: π½π here's the 16 failed requests
- Srb Scsi
- Opcode Status Status Sense Code Sector/ListId Time Stamp
- ------ ------ ------ ---------- --------------- ------------
- 1b 06 02 05 24 00 11:56:05.366
- 1b 06 02 05 24 00 16:53:23.397
- 1b 06 02 05 24 00 20:08:40.475
- 1b 07 00 00 00 00 04:42:52.788 π½π°οΈ failure time
- 2a 07 00 00 00 00 08856c00 04:42:52.788
- 28 07 00 00 00 00 026d6f38 04:42:52.788
- 28 07 00 00 00 00 00ffc744 04:42:52.788
- 2a 07 00 00 00 00 087e7398 04:42:52.788
- 28 07 00 00 00 00 01a654a8 04:42:52.788
- 28 07 00 00 00 00 026ed412 04:42:52.788
- 28 07 00 00 00 00 07560d60 04:42:52.788
- 28 07 00 00 00 00 02dfd615 04:42:52.788
- 28 07 00 00 00 00 07657810 04:42:52.788
- 28 07 00 00 00 00 0a0f2e58 04:42:52.788
- 28 07 00 00 00 00 00690f28 04:42:52.788
- 28 07 00 00 00 00 0a0f3000 04:42:52.788
- Classpnp External Information at ffffb005df2731b0
- WDC PC SN530 SDBPNPZ-256G-1002 21106000 E823_8FA6_BF53_0001_001B_448B_4630_F5CA.
- Minidriver information at ffffb005df273670
- Attached device object at ffffb005c5106b00 π½π±οΈ1
- Physical device object at ffffb005cc218050 π½π±οΈ2
- Media Geometry:
- Bytes in a Sector = 512
- Sectors per Track = 63
- Tracks / Cylinder = 255
- Media Length = 256060514304 bytes = ~238 GB
- dt classpnp!_FUNCTIONAL_DEVICE_EXTENSION ffffb005df2731b0
- To get port level details, please use !storunit ffffb005cc218050 π½π±οΈ3
- β¨β¨β¨
- 4: kd> !time
- CURRENT TIME:
- System: 01d768b3`64a7f260 (2021 Jun 24 04:42:52.788) π½π°οΈ now: same as the failure time ^^
- Interrupt: 0000054c`aea24ca6 (6 days, 17:51:30.552)
- Unbiased Interrupt: 000001ba`87a64e35 (2 days, 04:47:45.136)
- β¨β¨β¨
- 4: kd> !devobj ffffb005c5106b00 π½π±οΈ1 Attached Device Object
- Device object (ffffb005c5106b00) is for:
- \Driver\ACPI DriverObject ffffb005c50d65f0
- Current Irp 00000000 RefCount 0 Type 00000032 Flags 00000010
- SecurityDescriptor ffff9c8949435e60 DevExt ffffb005c80d5be0 DevObjExt ffffb005c5106c50
- ExtensionFlags (0000000000)
- Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
- AttachedDevice (Upper) ffffb005df273060 \Driver\disk
- AttachedTo (Lower) ffffb005cc218050 \Driver\iaStorAC
- Device queue is not busy.
- β¨β¨β¨
- 4: kd> !devobj ffffb005cc218050 π½π±οΈ2 Physical Device Object...
- Device object (ffffb005cc218050) is for:
- 0000003e \Driver\iaStorAC DriverObject ffffb005c81d0c60 π½β£οΈ ...owned by iaStorAC
- Current Irp 00000000 RefCount 0 Type 00000007 Flags 00001050
- SecurityDescriptor ffff9c8949279860 DevExt ffffb005cc2181a0 DevObjExt ffffb005cc219120 DevNode ffffb005c50db010
- ExtensionFlags (0000000000)
- Characteristics (0x00000180) FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
- AttachedDevice (Upper) ffffb005c5106b00 \Driver\ACPI
- Device queue is not busy.
- 4: kd> !storunit ffffb005cc218050 π½π±οΈ3
- DO: ffffb005cc218050 Ext: ffffb005cc2181a0 Adapter: ffffb005c81d21a0 Working
- ERROR: Unable to retrieve InquiryData offset
- Vendor: Product: SCSI ID: (3, 0, 0)
- Claimed Enumerated
- SlowLock: Free RemLock: 268435456 PageCount: 3
- QueueTagList: ffffb005cc2183a0 Outstanding: Head: 0000000000000000 Tail: 0000000000000000 Timeout: 0 (Ticking Down)
- DeviceQueue: ffffb005cc218430 Depth: 254 Status: Not Frozen PauseCount: 0 BusyCount: 0
- IO Gateway: Busy Count: 0 Pause Count: 0
- Requests: Outstanding: 2 Device: 61 ByPass: 0 π½ # of requests is somewhat large?
- [Device-Queued Requests]
- IRP SRB Type SRB XRB Command MDL SGList Timeout
- -----------------------------------------------------------------------------------------------------------------------------------
- ffffb005eb70da50 [SCSI] ffffb005f5d44e50 n/a SCSI/WRITE (10) ffffb005edb42a90 n/a 60s
- ffffb005f5faca20 [SCSI] ffffb005f5d45630 n/a SCSI/WRITE (10) ffffb005edb41c20 n/a 60s
- ffffb005f5115010 [SCSI] ffffb005f5d44de0 n/a SCSI/READ (10) ffffb005fc3031f0 n/a 60s
- ffffb005e67144c0 [SCSI] ffffb005f5d45470 n/a SCSI/READ (10) ffffb005fe8b0390 n/a 60s
- ffffb005f24f0a20 [SCSI] ffffb005f6fc5a30 n/a SCSI/READ (10) ffffb005fe8a84b0 n/a 60s
- ffffb005ee879250 [SCSI] ffffb005f0369470 n/a SCSI/READ (10) ffffb005c504a110 n/a 60s
- ffffb005e62c04c0 [SCSI] ffffb005fa24b3a0 n/a SCSI/WRITE (10) ffffb005ec204d50 n/a 60s
- ffffb005ece77a20 [SCSI] ffffb005f0113590 n/a SCSI/READ (10) ffffb005c504bb50 n/a 60s
- ffffb005f9f14ac0 [SCSI] ffffb005f5d44210 n/a SCSI/READ (10) ffffb005c504b610 n/a 60s
- ffffb005f62f1a20 [SCSI] ffffb005f5d441a0 n/a SCSI/READ (10) ffffb005c504af10 n/a 60s
- ffffb005f37eeb20 [SCSI] ffffb005f5d43f70 n/a SCSI/READ (10) ffffb005c504ad50 n/a 60s
- ffffb005efff2a20 [SCSI] ffffb005f5d449f0 n/a SCSI/READ (10) ffffb005c504b450 n/a 60s
- ffffb005edb74010 [SCSI] ffffb005f0368f30 n/a SCSI/READ (10) ffffb005c504a2d0 n/a 60s
- ffffb005f7164a60 [SCSI] ffffb005fa2a7ee0 n/a SCSI/READ (10) ffffb005c504a650 n/a 60s
- ffffb005f4ee7730 [SCSI] ffffb005fa2a8340 n/a SCSI/READ (10) ffffb005c504b290 n/a 60s
- ffffb005ece74b20 [SCSI] ffffb005fa2a8420 n/a SCSI/READ (10) ffffb005c504a9d0 n/a 60s
- ffffb005ed786a70 [SCSI] ffffb005f6dac980 n/a SCSI/READ (10) ffffb005e93792e0 n/a 60s
- ffffb005fbe65820 [SCSI] ffffb005f7f13db0 n/a SCSI/READ (10) ffffb005c504b990 n/a 60s
- ffffb005eed73010 [SCSI] ffffb005f5d440c0 n/a SCSI/READ (10) ffffb00600545ba0 n/a 60s
- ffffb005f9305a20 [SCSI] ffffb005f0368b40 n/a SCSI/READ (10) ffffb005fc3021a0 n/a 60s
- ffffb005ef4f97e0 [SCSI] ffffb005eb3a0250 n/a SCSI/READ (10) ffffb005fef369d0 n/a 60s
- ffffb005f57d3010 [SCSI] ffffb005f6dacd70 n/a SCSI/WRITE (10) ffffb005ef67a390 n/a 60s
- ffffb005fbc49a20 [SCSI] ffffb005f5d43f00 n/a SCSI/READ (10) ffffb005fac03ef0 n/a 60s
- ffffb005ea6224b0 [SCSI] ffffb005f0368670 n/a SCSI/READ (10) ffffb00600544b50 n/a 60s
- ffffb005f9b46a20 [SCSI] ffffb005f5d44980 n/a SCSI/READ (10) ffffb00600543cd0 n/a 60s
- ffffb005ea627010 [SCSI] ffffb005f0368a60 n/a SCSI/READ (10) ffffb00600544980 n/a 60s
- ffffb005fc1c7a20 [SCSI] ffffb005f5d44c90 n/a SCSI/READ (10) ffffb006005462e0 n/a 60s
- ffffb005ee084a20 [SCSI] ffffb005f5d44910 n/a SCSI/READ (10) ffffb00600543760 n/a 60s
- ffffb005f547ea20 [SCSI] ffffb005f5d44670 n/a SCSI/READ (10) ffffb005fc3028e0 n/a 60s
- ffffb005f930ba20 [SCSI] ffffb005f5d44c20 n/a SCSI/WRITE (10) ffffb005f6248dd0 n/a 60s
- ffffb005f9babb20 [SCSI] ffffb005f5d44830 n/a SCSI/WRITE (10) ffffb005fce65330 n/a 60s
- ffffb005f5cf3a20 [SCSI] ffffb005f5d44600 n/a SCSI/WRITE (10) ffffe509fc8219a0 n/a 60s
- ffffb005ed8f2010 [SCSI] ffffb005f5d43a30 n/a SCSI/READ (10) ffffb005fce636c0 n/a 60s
- ffffb005e9feea20 [SCSI] ffffb005f5d43410 n/a SCSI/READ (10) ffffb005fc3047b0 n/a 60s
- ffffb005f6904010 [SCSI] ffffb005f5d439c0 n/a SCSI/READ (10) ffffb00600545290 n/a 60s
- ffffb005eafbca20 [SCSI] ffffb005f36eb8f0 n/a SCSI/READ (10) ffffb00600544d20 n/a 60s
- ffffb005f5355b20 [SCSI] ffffb005f5d457f0 n/a SCSI/READ (10) ffffb005fc4462e0 n/a 60s
- ffffb005ece05af0 [SCSI] ffffb005f5d431e0 n/a SCSI/READ (10) ffffb005fc302e50 n/a 60s
- ffffb005f27f0760 [SCSI] ffffb005f5d43100 n/a SCSI/READ (10) ffffb005fac052e0 n/a 60s
- ffffb005f7fb5a20 [SCSI] ffffb005f5d436b0 n/a SCSI/READ (10) ffffb005ebfb79d0 n/a 60s
- ffffb005f5160a20 [SCSI] ffffb005f5d44f30 n/a SCSI/READ (10) ffffb005fc443ea0 n/a 60s
- ffffb005f2ce8b20 [SCSI] ffffb005f5d43b80 n/a SCSI/READ (10) ffffb005e9371900 n/a 60s
- ffffb005f19eab20 [SCSI] ffffb005fa2a7f50 n/a SCSI/READ (10) ffffb00600545f40 n/a 60s
- ffffb005eeddcb00 [SCSI] ffffb005f6dac280 n/a SCSI/READ (10) ffffb00600546680 n/a 60s
- ffffb005ec091a20 [SCSI] ffffb005f5d443d0 n/a SCSI/READ (10) ffffb006005459d0 n/a 60s
- ffffb005ea696b10 [SCSI] ffffb005f5d43800 n/a SCSI/READ (10) ffffb005f01c7d20 n/a 60s
- ffffb005f6d10010 [SCSI] ffffb005f5d43720 n/a SCSI/READ (10) ffffb00600543590 n/a 60s
- ffffb005f5ceea20 [SCSI] ffffb005f5d44520 n/a SCSI/READ (10) ffffb00600546850 n/a 60s
- ffffb005fbc34a20 [SCSI] ffffb005f5d44280 n/a SCSI/READ (10) ffffb006007bb850 n/a 60s
- ffffb005ee628a20 [SCSI] ffffb005f5d43cd0 n/a SCSI/READ (10) ffffb00600545d70 n/a 60s
- ffffb005e9e0aa40 [SCSI] ffffb005f5d43c60 n/a SCSI/READ (10) ffffb006005464b0 n/a 60s
- ffffb005f2037010 [SCSI] ffffb005f5d43bf0 n/a SCSI/READ (10) ffffb006005447b0 n/a 60s
- ffffb005eec18250 [SCSI] ffffb005f5d435d0 n/a SCSI/READ (10) ffffb006005431f0 n/a 60s
- ffffb005f9b51010 [SCSI] ffffb005edd65d40 n/a SCSI/READ (10) ffffb006005433c0 n/a 60s
- ffffb005ec2db010 [SCSI] ffffb005f36edf00 n/a SCSI/READ (10) ffffb005ff112350 n/a 60s
- ffffb005f6d78a20 [SCSI] ffffb005f5d44bb0 n/a SCSI/READ (10) ffffb00600547c40 n/a 60s
- ffffb005f3ca8a20 [SCSI] ffffb005f4aa98e0 n/a SCSI/READ (10) ffffb00600547a70 n/a 60s
- ffffb005f7fb8a20 [SCSI] ffffb005f36f13f0 n/a SCSI/READ (10) ffffb006005495a0 n/a 60s
- ffffb005f24f1a20 [SCSI] ffffb005f36f1d20 n/a SCSI/READ (10) ffffb00600546dc0 n/a 60s
- ffffb005f0edfa20 [SCSI] ffffb005f36f2030 n/a SCSI/READ (10) ffffb00600548e60 n/a 60s
- ffffb005f5544a20 [SCSI] ffffb005f36f1770 n/a SCSI/WRITE (10) ffffb005fe35de30 n/a 60s
- [Bypass-Queued Requests]
- IRP SRB Type SRB XRB Command MDL SGList Timeout
- -----------------------------------------------------------------------------------------------------------------------------------
- [Outstanding Requests]
- IRP SRB Type SRB XRB Command MDL SGList Timeout
- -----------------------------------------------------------------------------------------------------------------------------------
- [Completed Requests]
- IRP SRB Type SRB XRB Command MDL SGList Timeout
- -----------------------------------------------------------------------------------------------------------------------------------
- ffffb005f3cbba20 [SCSI] ffffb005f5d45780 ffffd3011a80a020 SCSI/READ (10) ffffb005fa6a02a0 ffffd3011a80a108 60s
- NOTE: 1 request(s) not found on the completed or outstanding list. The
- requests are probably being transferred from one list to another. On an
- MP machine this could be happening on a separate processor.
- β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨
- β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨β¨
- And I guess it's time to conclude this dump analysis.
- We conducted an extensive analysis of the code flow for the thread that invoked KeBugCheckEx, including SEH exception
- filter code recovery, the use of compressed memory, and PTE and PFN analysis. We identified that the thread was
- deleting a segment (a section object) and had manually invoked MmAccessFault to page-in the prototype PTE before
- locking it. We identified the PFN and displayed the original PTE, which indicated that PageFile #2 was needed,
- corresponding to the fake pagefile used by the Store Manager (with compressed memory). To decompress memory,
- the thread attached to the MemCompression process; yet the decompression attempt incurred a real page fault - because
- the compressed data itself had been paged out.
- The attempt to read compressed data from the pagefile failed: MmAccessFault, invoked from the nt!KiPageFault #PF
- handler, returned STATUS_NO_SUCH_DEVICE (0xC000000E).
- We then identified system pagefiles, and learned that there was only one relevant real pagefile: C:\pagefile.sys.
- While looking for what could have caused the STATUS_NO_SUCH_DEVICE failure, we checked volume and filesystem device
- stacks. During this process, we identified McAfee mfehidk.sys filesystem minifilter, but deemed it an unlikely cause.
- We then identified the disk device and its stack. This revealed that a storage device using the Intel iaStorAC.sys
- driver was deeply involved. That driver is related to Intel Rapid Storage Technology and is a known cause of BSODs.
- Using `!fxdevice` command and the name of the HDD device found earlier, we dumped the device power requests log and
- learned that a request for the D0 state was issued to the storage device only 618 ms ago - before that, the device was
- in the D3 low-power state. We also learned that the storage device changed to the D0 state just 258 ms ago, yet the
- related power IRP completed only now, 0 ms ago. We then used `!powertriage` command to validate the system power state,
- and learned that the system started to wake up from hibernation only about 649 ms ago.
- In search of more clues, we dumped the call stacks of all currently running and all ready threads, and found that a
- thread running on CPU5 was in the process of attempting recovery from an NTFS error, in `ntfs!NtfsFixDataError`.
- After that, we used the built-in Windbg extension storagekd. It revealed that there were 16 storage errors on the
- relevant device stack, including 13 errors timed to the current moment with millisecond precision. The device stack
- directly involved the Intel iaStorAC.sys driver. We then used the `!storunit` command and learned that there were 61
- device-queued requests (mostly read requests) and one outstanding request missing.
- β¨β¨β¨
- So the most likely culprit is the Intel iaStorAC.sys driver, possibly in combination with its related hardware
- controller, if any. The failure is likely related to mishandling device read requests during early power state
- transitions. Alternatively, the driver may have been overwhelmed by the inrush of I/O requests during the system wakeup,
- or it might have been a combination of both factors.
- β¨β¨β¨
- The recommendation for the affected user is to disable Intel Rapid Storage Technology in the BIOS. This may involve
- either explicitly turning off such option, or changing the storage mode from RAID to AHCI. Most likely that'll solve the
- problem.
- A secondary recommendation is to check the disk device for any SMART warnings, e.g. using the free CrystalDiskInfo tool,
- and replace the disk if serious issues are found.
- A tertiary recommendation - in case it's impossible to disable Intel Rapid Storage for some reason - is to update
- drivers via Windows Update.
- A quaternary recommendation: while the final part of our analysis shows the McAfee mfehidk.sys driver is unrelated to
- the crash, removing this piece of product can be a good measure for system stability.
Add Comment
Please, Sign In to add comment