Tablet BSOD while sleeping

Page 4 of 6 FirstFirst ... 23456 LastLast

  1. Posts : 194
    Windows 10
    Thread Starter
       #31

    Is the Default AHCI MS driver to be known to be slow compared to Intel driver? It is from 2006 actually, not sure if thats any good "sign".
      My Computer


  2. Posts : 5,170
    64bit Win 10 Pro ver 21H2
       #32

    The 2006 is not real - MS uses that date for all its drivers. See here
      My Computers


  3. Posts : 194
    Windows 10
    Thread Starter
       #33

    philc43 said:
    The 2006 is not real - MS uses that date for all its drivers. See here
    I actually think it is more logic, that it is the other way around. The driver is indeed from 2006, but the version is "fake" and just the same build number as the Windows build number. I guess both date and version dont really tell you anything about, if or what and when was a last "major" change in those drivers. I will give it a try and hope for the best.
      My Computer


  4. Posts : 5,170
    64bit Win 10 Pro ver 21H2
       #34

    gorgor said:
    I actually think it is more logic, that it is the other way around. The driver is indeed from 2006, but the version is "fake" and just the same build number as the Windows build number. I guess both date and version dont really tell you anything about, if or what and when was a last "major" change in those drivers. I will give it a try and hope for the best.
    Perhaps this link will help: https://blogs.msdn.microsoft.com/old...08-00/?p=95395

    I'm not sure it is the best way to do this but that's what it is!
      My Computers


  5. Posts : 14,904
    Windows 10 Pro
       #35

    Let's connect the dots to each other.

    Each BSOD occured due to an in-page I/O error, as can seen each time it begins with decompressing a buffer likely set by the Intel chipset.

    Code:
    2: kd> .exr 0xffffd8016d033fa8
    ExceptionAddress: fffff80086557700 (nt!RtlDecompressBufferXpressLz+0x0000000000000060)
       ExceptionCode: c0000006 (In-page I/O error)
      ExceptionFlags: 00000000
    NumberParameters: 3
       Parameter[0]: 0000000000000000
       Parameter[1]: 0000000006ce0270
       Parameter[2]: 00000000c000000e
    Inpage operation failed at 0000000006ce0270, due to I/O error 00000000c000000e
    
    
    2: kd> knL
     # Child-SP          RetAddr           Call Site
    00 ffffbc00`bb969fb8 fffff802`6604ffd2 nt!KeBugCheckEx
    01 ffffbc00`bb969fc0 fffff802`65f82b6d nt!SMKM_STORE<SM_TRAITS>::SmStUnhandledExceptionFilter+0x22
    02 ffffbc00`bb96a000 fffff802`65f5f42f nt!`SMKM_STORE<SM_TRAITS>::SmStDirectReadIssue'::`1'::filt$0+0x1f
    03 ffffbc00`bb96a030 fffff802`65f7ba2d nt!_C_specific_handler+0x9f
    04 ffffbc00`bb96a0a0 fffff802`65e34d94 nt!RtlpExecuteHandlerForException+0xd
    05 ffffbc00`bb96a0d0 fffff802`65e33b36 nt!RtlDispatchException+0x404
    06 ffffbc00`bb96a7c0 fffff802`65f8098e nt!KiDispatchException+0x1f6
    07 ffffbc00`bb96ae70 fffff802`65f7ee57 nt!KiExceptionDispatch+0xce
    08 ffffbc00`bb96b050 fffff802`65ee3700 nt!KiPageFault+0x217
    09 ffffbc00`bb96b1e0 fffff802`65ee2d00 nt!RtlDecompressBufferXpressLz+0x60
    0a ffffbc00`bb96b210 fffff802`65ee29dd nt!RtlDecompressBufferEx+0x60
    0b ffffbc00`bb96b260 fffff802`65ee284f nt!ST_STORE<SM_TRAITS>::StDmSinglePageCopy+0x159
    0c ffffbc00`bb96b340 fffff802`65ee223b nt!ST_STORE<SM_TRAITS>::StDmSinglePageTransfer+0x7b
    0d ffffbc00`bb96b390 fffff802`65ee200c nt!ST_STORE<SM_TRAITS>::StDmpSinglePageRetrieve+0x183
    0e ffffbc00`bb96b430 fffff802`65ee3c7f nt!ST_STORE<SM_TRAITS>::StDmPageRetrieve+0x98
    0f ffffbc00`bb96b4f0 fffff802`65f32f81 nt!SMKM_STORE<SM_TRAITS>::SmStDirectReadIssue+0x6f
    10 ffffbc00`bb96b540 fffff802`65e1f20b nt!SMKM_STORE<SM_TRAITS>::SmStDirectReadCallout+0x21
    11 ffffbc00`bb96b570 fffff802`65eda625 nt!KeExpandKernelStackAndCalloutInternal+0x8b
    12 ffffbc00`bb96b5c0 fffff802`65ed0cc2 nt!SMKM_STORE<SM_TRAITS>::SmStDirectRead+0xad
    13 ffffbc00`bb96b690 fffff802`65ed0522 nt!SMKM_STORE<SM_TRAITS>::SmStWorkItemQueue+0x1ae
    14 ffffbc00`bb96b6e0 fffff802`65ee4afa nt!SMKM_STORE_MGR<SM_TRAITS>::SmIoCtxQueueWork+0xce
    15 ffffbc00`bb96b760 fffff802`65f216ea nt!SMKM_STORE_MGR<SM_TRAITS>::SmPageRead+0x16a
    16 ffffbc00`bb96b7d0 fffff802`65eaafa9 nt!SmPageRead+0x2e
    17 ffffbc00`bb96b820 fffff802`65eaa970 nt!MiIssueHardFaultIo+0x11d
    18 ffffbc00`bb96b870 fffff802`65e96486 nt!MiIssueHardFault+0x190
    19 ffffbc00`bb96b910 fffff802`65f7ed72 nt!MmAccessFault+0xc96
    1a ffffbc00`bb96bb00 00007ffb`1ff9cb7f nt!KiPageFault+0x132
    1b 000000f7`173ff440 00000000`00000000 0x00007ffb`1ff9cb7f
    The issue starts with moving data from the RIP registry entry to the R10 entry which was attempted from an invalid page.
    Good chance the invalid page is from reading from the pagefile where instructions were saved to perform this operation which was corrupted due to an issue with the SSD.
    Code:
    2: kd> .cxr 0xffffd8016d0337f0
    rax=fffff800865576a0 rbx=ffffd80168f09ea0 rcx=ffffd80168f09000
    rdx=ffffd80168f09000 rsi=ffffd80168f09000 rdi=0000000000000000
    rip=fffff80086557700 rsp=ffffd8016d0341e0 rbp=0000000000000000
     r8=0000000006ce0270  r9=00000000000001f2 r10=0000000006ce0270
    r11=0000000000000000 r12=ffffd80168f0a000 r13=0000000006ce0462
    r14=ffffd80168f09000 r15=0000000006ce040c
    iopl=0         nv up ei pl zr na po nc
    cs=0010  ss=0000  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
    nt!RtlDecompressBufferXpressLz+0x60:
    fffff800`86557700 418b02          mov     eax,dword ptr [r10] ds:002b:00000000`06ce0270=????????
    
    
    2: kd> !pool fffff80086557700
    Pool page fffff80086557700 region is Unknown
    fffff80086557000 is not a valid large pool allocation, checking large session pool...
    Unable to read large session pool table (Session data is not present in mini and kernel-only dumps)
    fffff80086557000 is not valid pool. Checking for freed (or corrupt) pool
    Bad previous allocation size @FfFff80086557000, last size was 0
    2: kd> !poolval fffff80086557700
    Pool page fffff80086557700 region is Unknown
    
    Validating Pool headers for pool page: fffff80086557700
    
    Pool page [ fffff80086557000 ] is __inVALID.
    
    Analyzing linked list...
    [ fffff80086557000 ]: invalid previous size [ 0x20 ] should be [ 0x0 ]
    [ fffff80086557830 --> fffff80086557960 (size = 0x130 bytes)]: Corrupt region
    
    
    Scanning for single bit errors...
    [ fffff80086557000 ]: previous size [ 0x20 ] should be [ 0x0 ]

    Gorgor, I recommend to perform a chkdsk and run HDTune on your SSD.
    See Tablet BSOD while sleeping - Windows 10 Forums for HDTune instructions.
    Run chkdsk /r in an admin command prompt, press Y when requested to schedule the task on reboot.
    If you already run this command, I missed it so please excuse me. I missed a few pages.
      My Computers


  6. Posts : 194
    Windows 10
    Thread Starter
       #36

    Scanning disk gave zero file system errors.

    I just did a fresh clean Windows 10 install today and just about 30 minutes afterwards again a bluescreen, after the tablet was charging and in sleep. It is another error code this time 1001 I think though, maybe this dump shows something else

    https://mega.nz/#!a8VjyCia!xvBNBT0RnVlu4s8kMUSgFTWuIq-EORE1NuhuLc9Hz-0
      My Computer


  7. Posts : 14,904
    Windows 10 Pro
       #37

    What are the HDTune scan results?
    Any chance you saved the chkdsk log before the clean install??
      My Computers


  8. Posts : 194
    Windows 10
    Thread Starter
       #38

    No I dont have a chkdsk log. It took actually a long time to scan it stuck about 5-10 minutes or more at 18% or so. I went into log event tool and looked for an entry, and there was just a notification something like finished with no file system errors or file system on c: is error free. I still think this is some bug in Windows and connected with the Event 129: Reset to device, \Device\RaidPort0, was issued.

    When googling about it you can find people who had this issue just after a Windows 10 update in the last 6-12 months, mostly after anniversary or creators update.

    I read in another thread somewhere, a workaround "could be" to set DisablePagingExecutive to 1 in the registry, forcing Windows to keep all kernel and drivers in memory, instead of paging them on disk. Maybe this is related? Windows driver crashes because it wants to read paged drivers from the disk (Which is not present at the right time).

    Another workaround is people saying to completely disable AHCI Link Power Management. But when I do this for example via the Intel rapid store tool, the tablet gets warm and stays warm all the time in sleep. Powercfg shows a large drain then of about 2400mWh.
      My Computer


  9. Posts : 14,904
    Windows 10 Pro
       #39

    It is usual for chkdsk to be stuck at around 12-20%, the rest can take hours to finish.

    If this is a bug in Windows, you would've seen thousands of more users complain about this kind of issues in a short time.
    Reset to a device merely means the device didn't respond, a reset was triggered attempting to let the device respond again.

    I wouldn't recommend to disable paging, it'll let programs consume a lot of memory which in result displays messages that you need to close apps to free memory.

    Why the last crash occured I can't yet say. I noticed a loop in the call stack where, if I interpret it correct, the system tries to identify what function caused an exception. This call likely returns null (nothing) as a result of the loop.
    I looked up the exception code and it means "{No Paging File Specified} No paging file was specified in the system configuration."
    I can't look into the instructions that were executed to figure out why the system crashed, because we're dealing with instructions that used temporary register entries which aren't saved.
      My Computers


  10. Posts : 194
    Windows 10
    Thread Starter
       #40

    axe0 said:
    If this is a bug in Windows, you would've seen thousands of more users complain about this kind of issues in a short time.
    Not really. My understanding is, this just includes a small range of hardware in combination of connected standby devices. So all laptops and desktops PCs are out of this. Meaning it is just happening for tablets, which have a SSD, also, just M2 SSDs, not PCIe nvme. This also seems just to happen in connected standby, so scanning the disk wont show any errors. Also, if the SSD goes sleep in normal mode, Windows seems to be able to wake it up in time, and wont stuck. This seems to be different when Windows is in connected standby, and crashes.

    DisablePagingExecutive

    This says, DisablePagingExecutive is just for keeping drivers and kernel modules in memory, this is not for user space apps, so why should it grow over time?

    It seems to me the problem is related to Windows 10's memory compression feature, in combination with it storing drivers on disk, then in combination of this power saving of the SSD in connected standby. Windows somhow cant reach the SSD or wake it up, wants to load something from disk, and crashes.
      My Computer


 

  Related Discussions
Our Sites
Site Links
About Us
Windows 10 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 10" and related materials are trademarks of Microsoft Corp.

© Designer Media Ltd
All times are GMT -5. The time now is 01:51.
Find Us




Windows 10 Forums