New
#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".
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".
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.
The issue starts with moving data from the RIP registry entry to the R10 entry which was attempted from an invalid page.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
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.
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
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.