Windows 10: Tablet BSOD while sleeping

There is no newer version, typically Intel. They dont care much about driver updates. There is just the Default AHCI MS driver. The above finding is just a result of the SSD hanging so Windows identifies it as the installed AHCI Intel driver, no? It would mostly state any driver which would be in its place, doesnt mean the driver is faulty. So I should maybe just switch back to the default MS driver I guess, and remove the Intel AHCI driver. Wonder if that would make things worse or give other bad results (maybe performance wise).

 

Yes but in practice this usually points to the driver being the problem. I would try another driver and see if it helps.

 

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".

 

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.

 

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!

 

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[/quote] 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 ][/quote]
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.

 

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 *Sad

MEGA

 

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

 

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.

 

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.

 

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.

 

I have to correct you on a few things.

Incorrect, hardware errors can be very specific and very 'wild'. I've seen it happen that playing a game for a specific time crashed the system as a result of a disk error which was beyond repair.

Several programs use drivers, both kernel mode and user mode. A tiny bug, which is always there, could hang on to memory even when the program closes or perform a loop of infinite calls consuming memory.

This sounds similar like a firmware bug in the Samsung 800 series from a long time ago. Many systems with a samsung 800 ssd couldn't wake up from sleep, either a firmware update or another SSD solved that problem.

 

I think you should maybe read the whole thread. I am totally sure my thesis is correct. It is related to AHCI LPM. It is related to a Windows 10 only (mostly up from anniversary update). It wont happen in normal use. It didnt happen in Windows 8, mostly because of changes to the connected standby (now modern standby). So you are incorrect of saying I am incorrect. It is not a hardware error.

SDSSDA240G problems with LPM on Windows 10 anniver... - SanDisk Forums

https://answers.microsoft.com/en-us/...73c25ea?page=2

And I find other reports like this, that it began with Windows 10 anniversary update.

Deactivating LPM seems to fix the crashes, but this is not an option for tablet users, because it drains the tablet literally in hours. It wont have no big effect on laptops or desktops having the issue.

disablepagingexecutive seems to be a "fix" (more like a shabby workaround) too for this, because it wont crash Windows when it wants to load something from swap aka disk not ready in time.

 

Alright, I've reread the whole thread and done some reading about compressed memory.

Compressed memory is memory that the Memory Management decides is long enough being untouched to move it to the so-called 'modified list' where it is being compressed to 40% of the original size. After compression and after the memory is moved to the pagefile, it is put on the 'standby list' where it can be reused through an I/O operation. Access is allowed by the process that was the rightful owner of the memory and by another process.
When the rightful owner accesses the compressed memory from the pagefile it is called a 'softfault', if something else accesses the memory and the rightful owner accesses the memory later it is called a 'hardfault'.
See Windows 10 Memory Compression - Windows 10 Forums

After reading this I have a different opinion on what I think might have happened in the earlier BSOD.
Going through the stack of the earlier BSOD, a driver caused a hardfault when trying to access its compressed memory which appeared to have already been called. I believe that the error handling by this driver is simply improper seeing the result of an unhandled exception in the call stack after the driver received its compressed page.

Did you run driver verifier?