Frequent BSOD crashes, by process of elimination likely a driver

Hi, and thanks for being here.

I have been having frequent BSODs and sudden reboots for several weeks on a new laptop that has been in service about 6 weeks. It is a Lenovo E560 running Win7-Pro x64, fully updated. A Lenovo utility updated the BIOS after the problems began occurring. I have also taken the following measures:

1. sfc /scannow reported no problems. I also ran ChkDsk in fix mode; no problems found.
2. Seagate SeaTools and Gibon's SpinRite reported no problems on their in-depth tests.
3. I ran the latest version of MemTest86 for 8 cycles, twice, with no errors reported.
4. I ran Prime95 to stress test the CPU. No errors reported.
5. I ran Lenovo diagnostics with no problems reported.
6. Four days ago I ran DriveBooster, which update 15 drivers that the Lenovo utility had said were current. (Risky perhaps, but up for trying anything at this point of frustration.)

Among faults on the BSOD screens have been: bad_pool_header; bad_pool_caller; PFN_List_Corrupt; PRN_list_corrupt; and others I don't have a record of. Crashes have happened: in several programs, twice when opening the laptop's lid (the OS turns off the screen when the lid is closed - it doesn't sleep or hibernate for that); and once when coming out of hibernation.

I ran DM Log Collector, and its output zip file is attached. When the last crash occurred I had Driver Verifier active.

Here you go. I'm not sure the process completed correctly. It completed in the command window before the "refreshing system information" box completed. On the desktop I got a folder instead of a zip file, and what is attached here is a zip I made of its contents.

I just had three BSOD crashes during bootup. One of them was a Bad_Pool_Caller, but the others did not identify a cause. I booted in safe mode and turned the Verifier off, and then was able to get a normal booup. Here is a minidump with Analyze turned on. It identifies NTFS.SYS as the probable cause.

Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\LTE\Desktop\010918-23025-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available


************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\Windows\symbol_cache*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\Windows\symbol_cache*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.24000.amd64fre.win7sp1_ldr.171231-1547
Machine Name:
Kernel base = 0xfffff800`03612000 PsLoadedModuleList = 0xfffff800`03851a90
Debug session time: Tue Jan 9 14:47:20.424 2018 (UTC - 9:00)
System Uptime: 0 days 0:00:19.579
Loading Kernel Symbols
...............................................................
................................................................
......................
Loading User Symbols
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C2, {b, fffff8a000a80740, a, fffff8a000a81010}

Probably caused by : Ntfs.sys ( Ntfs!NtfsPerformPrefetch+15d )

Followup: MachineOwner
---------

3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

BAD_POOL_CALLER (c2)
The current thread is making a bad pool request. Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 000000000000000b, type of pool violation the caller is guilty of.
Arg2: fffff8a000a80740
Arg3: 000000000000000a
Arg4: fffff8a000a81010

Debugging Details:
------------------


FAULTING_IP:
Ntfs!NtfsPerformPrefetch+15d
fffff880`01e3574d 8bc3 mov eax,ebx

BUGCHECK_STR: 0xc2_b

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP

PROCESS_NAME: System

CURRENT_IRQL: 0

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

LAST_CONTROL_TRANSFER: from fffff800037f4acf to fffff800036b83a0

STACK_TEXT:
fffff880`03dcf308 fffff800`037f4acf : 00000000`000000c2 00000000`0000000b fffff8a0`00a80740 00000000`0000000a : nt!KeBugCheckEx
fffff880`03dcf310 fffff880`01e3574d : 00000000`00000000 00000000`00000100 fffffa80`0e726f30 00000000`000007ff : nt!ExFreePoolWithTag+0x188f
fffff880`03dcf3c0 fffff880`01efe12e : fffffa80`12e87600 fffff8a0`00a81010 fffffa80`13dfe180 ffffffff`ffffff01 : Ntfs!NtfsPerformPrefetch+0x15d
fffff880`03dcf410 fffff880`01f01c40 : fffffa80`126afe40 fffffa80`13dfe180 fffffa80`00000000 00000000`05ff8000 : Ntfs!NtfsScanEntireBitmap+0x1e3
fffff880`03dcf700 fffff880`01f13d42 : fffffa80`126afe40 fffffa80`13dfe180 00000000`00000000 00000000`00000000 : Ntfs!NtfsInitializeClusterAllocation+0x60
fffff880`03dcf730 fffff880`01eaf7c9 : fffffa80`126afe40 fffff980`05bd06c0 fffff880`03dcfa28 fffff880`03dcfa20 : Ntfs!NtfsMountVolume+0x1aaa
fffff880`03dcf9f0 fffff880`01e3626b : fffffa80`126afe40 fffff800`0364d973 00000000`00000000 fffffa80`10b4d410 : Ntfs!NtfsCommonFileSystemControl+0xc9
fffff880`03dcfaa0 fffff800`0366c281 : fffff800`03828500 fffff800`0391e900 fffffa80`0c7ef600 fffff800`03828501 : Ntfs!NtfsFspDispatch+0x29b
fffff880`03dcfb70 fffff800`0395a284 : 00000000`00000000 fffff880`03bee180 00000000`00000080 fffffa80`0c7d3040 : nt!ExpWorkerThread+0x111
fffff880`03dcfc00 fffff800`036be816 : fffff880`03bee180 fffffa80`0c7ef660 fffff880`03bfb140 00000000`00000000 : nt!PspSystemThreadStartup+0x140
fffff880`03dcfc40 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxStartSystemThread+0x16


STACK_COMMAND: kb

FOLLOWUP_IP:
Ntfs!NtfsPerformPrefetch+15d
fffff880`01e3574d 8bc3 mov eax,ebx

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: Ntfs!NtfsPerformPrefetch+15d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5a4991dc

IMAGE_VERSION: 6.1.7601.24000

FAILURE_BUCKET_ID: X64_0xc2_b_VRF_Ntfs!NtfsPerformPrefetch+15d

BUCKET_ID: X64_0xc2_b_VRF_Ntfs!NtfsPerformPrefetch+15d

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:x64_0xc2_b_vrf_ntfs!ntfsperformprefetch+15d

FAILURE_ID_HASH: {663d2c39-c4ca-ad7c-cddc-b7ae60b30679}

Followup: MachineOwner
---------

I have run the tests under HD Tune, and have attached the screen shots from that since they may tell you something while the other tests are in process. I ran the benchmark test 3 times, with somewhat different results (esp. for the first run).

I am presently doing a back up (lots of data on my 2 TB drive, long process), and the SeaTools test will take awhile to run. So it will be awhile before I have more to send.

I am unable to run the SeaTools test because it doesn't recognize my drive (even though it is a Seagate). I need to set the the BIOS to ATA/IDE for that, but my BIOS doesn't have a setting for doing that. ChkDsk finds no problems. As mentioned earlier, I had already run SpinRite (GRC), which does much the same as SeaTools. Like SeaTools it runs from a bootable disk. SpinRite ran for many hours (much longer than HDTune), deep testing one sector at a time. It can correct problems, but found none.

I continue to have BSODs, but haven't seen the NTFS.sys one again.