My Lenovo ThinkPad Yoga (20LF000KUS) has been crashing randomly with several different blue-screen errors, including MEMORY_MANAGEMENT (0x1A, with corrupted PTE/PFN structures), DPC_WATCHDOG_VIOLATION (0x133), SYSTEM_SERVICE_EXCEPTION (0x3B), KERNEL_THREAD_PRIORITY_FLOOR_VIOLATION (0x157), and PFN_LIST_CORRUPT (0x4E). The crashes happen during both light use and heavier workloads, and one occurred while Windows was installing updates and drivers through drvinst.exe. WinDbg could not identify a specific driver and reported Unknown_Module or ANALYSIS_INCONCLUSIVE.
I initially suspected virtualization because some crashes happened while using BlueStacks and the dumps showed Hyper-V enabled. However, disabling Windows virtualization features and Intel VT-x/VT-d in the firmware only helped temporarily; another crash eventually occurred.
I then performed a clean Windows installation, but the system crashed again while installing updates. I ran MemTest86 from a bootable USB for four passes and it found no errors. Given the repeated memory and kernel-structure corruption, could this still be faulty RAM, a damaged memory slot, the motherboard or memory controller, storage, firmware, or a driver? What would you investigate next without replacing parts blindly?
3 Answers
The pattern still makes faulty memory hardware one of the strongest suspects. A bad RAM module, marginal slot, or memory controller can corrupt different kernel structures and produce many unrelated stop codes. Passing four MemTest86 passes is encouraging, but it does not completely rule out intermittent failures that only appear with a particular temperature, workload, or memory pattern. If the memory is removable, test one module at a time in each slot and compare results. Also load BIOS defaults and make sure the firmware is current.
Collect several complete or kernel memory dumps rather than relying on one minidump. They can show whether the same driver, address range, or hardware error keeps appearing. Run the system with virtualization disabled while troubleshooting, but since the crashes continued afterward, Hyper-V is probably not the root cause. Driver Verifier can sometimes expose a bad driver, but use it cautiously and only with a recovery plan because it can deliberately trigger crashes; avoid enabling every verification option at once.
Do not focus too heavily on the process named in the dump. drvinst.exe was probably active when the corruption became visible, not necessarily the thing that caused it. With several unrelated bug checks, a clean Windows reinstall, and no consistent third-party driver identified, hardware or firmware is more likely than one ordinary application. Check the SSD's health and firmware, update the laptop BIOS and chipset/storage drivers from the manufacturer's support page, and inspect the Windows and firmware event logs for WHEA hardware errors.
That was my concern too. I was surprised that MemTest86 was clean, but I understand that it may not catch every intermittent or slot-related problem.