Windows 10 Freezing

Dalphelus

Member
Joined
Feb 19, 2018
Posts
19
For a few months now, my system running Windows 10 has been experiencing occasional hard freezes. What happens precisely is that my computer will be running just fine, when suddenly the program I am using stops responding. Everything, from the start menu to the task manager, will be unresponsive when this occurs. Not long after, the mouse cursor will freeze too and the entire system will deadlock. At this point, the only solution seems to be to hard-reboot the system. I've tried just about everything under the sun to resolve this issue, from updating my drivers, to running intensive stress-testing software like Prime95 and Furmark, to testing each stick of RAM/memory slot individually using MemTest, to removing my AV software, to straight up reinstalling Windows - nothing can get the issue to reliably reproduce, yet nothing I've tried seems to fix it for good.

Previously, this issue would only occur when playing certain VR games (Notably Rise of the Tomb Raider, which always caused a freeze within ten minutes), but since reinstalling Windows I've only seen it occur when using Discord on my web browser (Firefox). I should stress that these freezes are *very* intermittent - I'll see maybe one per week. The last three, however, have all occurred while typing out messages on Discord. Since nobody else seemed capable of helping me resolve this issue, I was about ready to give up trying to solve the problem, but then I noticed today that Windows *has* in fact been saving dump files around the time that the freezes occurred (Not the minidumps that it usually records on a proper BSOD). They've been located in the Windows\LiveKernelReports folder, and are a whopping 3GB in size each. Thing is, I don't know how to open these files properly (And I doubt I'd know what to look for even if I could), so I was hoping someone here might be able to help. I'm currently uploading the most recent dump file to Dropbox, hopefully someone here will know what to do with it.

I did try opening the files using bluescreenview, but it wasn't particularly revealing: https://i.imgur.com/C3upEzt.png

Thanks!

Intel i7-6800K @3.4GHz
MSI X99A SLI Plus
Corsair 32GB DDR4 RAM @2666MHz
Samsung 960 EVO
Seagate 4TB HDD
Corsair RM750X
 
This is one of the dump files in question. I should probably also note that the system is about a year old now, and these problems started manifesting seemingly out of the blue a few months ago. Prior to that, the system ran just perfectly.

According to Windbg, the other two errors were probably caused by win32kbase.sys, while this was caused by pdc.sys.

Here is the complete dump file for the latest crash:

Dropbox - PdcLockWatchdog-20180212-2353.zip

And here is the detailed report the second most recent crash generated by WinDbg:

Dropbox - log.txt
 
It sounds like it is hardware related. Please download and run Speccy.


  • Please download Speccy System Information Tool and save it to somewhere convenient such as your desktop.
  • Close any programs that may be running including your browser and double click Speccy.exe to run the tool.
  • Watch out for any offers to install other programs such as google chrome and untick the box(es) if you don't want them.
  • Speccy will very quickly scan your pc and create a report.
  • Top left of screen click file and select Publish Snapshot...
  • Click Yes to proceed.
  • Copy the URL to your clipboard and paste it into your next reply.
 
Everything pertaining to my system's installed hardware should already have been provided by the Sysinternal collection app, shouldn't it?
 
Everything pertaining to my system's installed hardware should already have been provided by the Sysinternal collection app, shouldn't it?
Indeed, with a small exception for cooling, PSU and case :smile9:

A quick look at the raw stack of the thread holding the lock shows the NVME controller driver.
Code:
********************************************************************************                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************


PDC_LOCK_WATCHDOG_LIVEDUMP (17c)
A thread has been holding the PDC lock for too long
(This code can never be used for a real bugcheck.)
Arguments:
Arg1: ffffd40426c58040, The thread holding the PDC lock.
Arg2: 0000000000002710, pdc!PdcLockWatchdogTimeout [seconds].
Arg3: 0000000000000000, Reserved.
Arg4: 0000000000000000, Reserved.


0: kd> !thread ffffd40426c58040
THREAD ffffd40426c58040  Cid 0004.35d4  Teb: 0000000000000000 Win32Thread: 0000000000000000 WAIT: (WrResource) KernelMode Non-Alertable
    ffffe50e0166f340  SynchronizationEvent
Not impersonating
DeviceMap                 ffff9f8fe1e17c70
Owning Process            ffffd4041c8dd440       Image:         System
Attached Process          ffffd404236c9580       Image:         csrss.exe
Wait Start TickCount      2909686        Ticks: 165 (0:00:00:02.578)
Context Switch Count      11707          IdealProcessor: 0             
UserTime                  00:00:00.000
KernelTime                00:00:00.390
Win32 Start Address nt!ExpWorkerThread (0xfffff800142ac050)
Stack Init ffffe50e0166fc90 Current ffffe50e0166ee90
Base ffffe50e01670000 Limit ffffe50e0166a000 Call 0000000000000000
Priority 12 BasePriority 12 PriorityDecrement 0 IoPriority 2 PagePriority 5


Child-SP          RetAddr           : Args to Child                                                           : Call Site
ffffe50e`0166eed0 fffff800`1432def0 : 00000000`00000000 ffffd404`26c58100 00000000`00000000 00000000`00000000 : nt!KiSwapContext+0x76
ffffe50e`0166f010 fffff800`1432d86e : ffffd404`26c58040 ffffd404`26c58140 ffffd404`26c58100 00000000`00000000 : nt!KiSwapThread+0x190
ffffe50e`0166f0d0 fffff800`1432d049 : 00000000`0000003d 00000000`00000000 00000000`00000000 ffffe50e`0166f340 : nt!KiCommitThreadWait+0x10e
ffffe50e`0166f170 fffff800`1432b08d : ffffe50e`0166f340 00000000`0000001b 00000000`00000000 00000000`00000000 : nt!KeWaitForSingleObject+0x1c9
ffffe50e`0166f250 fffff800`142bf99f : ffffd404`23735b70 ffffe50e`0166f330 00000000`00010224 fffff800`143ad470 : nt!ExpWaitForResource+0x6d
ffffe50e`0166f2d0 fffff800`142bf69f : 00000000`00000002 00000000`00000001 00000000`00000000 ffffd404`1cdec09c : nt!ExpAcquireResourceExclusiveLite+0x27f
ffffe50e`0166f3a0 ffff8140`a40bf6a2 : ffffe50e`0166f7a0 00000000`00000001 ffffe50e`0166f428 ffffe50e`0166f638 : nt!ExEnterCriticalRegionAndAcquireResourceExclusive+0x3f
ffffe50e`0166f3e0 ffff8140`a408b34d : 00000000`00000000 00000000`00000000 fffff80d`00000000 ffffd404`1d21af78 : win32kbase!EnterCritAvoidingDitHitTestHazard+0x22
ffffe50e`0166f420 ffff8140`a408c068 : 00000000`00000282 00000000`00000000 ffffe50e`0166f7c8 ffffd404`1cdec098 : win32kbase!UserSessionSwitchBlock_Start+0x49
ffffe50e`0166f450 ffff8140`a40bf304 : 00000000`00000000 ffffd404`2164fe80 ffffe50e`0166f7c8 00000000`c000000d : win32kbase!UserPowerStateCallout+0x1cc
ffffe50e`0166f4a0 ffff8140`a307103a : 00000000`00000000 fffff800`14611140 00000000`00000000 00000000`00000000 : win32kbase!W32CalloutDispatch+0x594
ffffe50e`0166f500 fffff800`1481dbf1 : 00000000`00000004 00000000`00000000 ffffd404`236c9580 00000000`c000000d : win32k!W32CalloutDispatchThunk+0xa
ffffe50e`0166f530 fffff800`1472d41b : 00000000`00000010 00000000`00000082 ffffe50e`0166f618 ffffd404`1da4f280 : nt!ExCallSessionCallBack+0x91
ffffe50e`0166f5f0 fffff800`147b02ca : ffffd404`20ad3580 ffffe50e`0166f699 ffff9b45`c8d7d9ee 00000000`00000001 : nt!PsInvokeWin32Callout+0xcb
ffffe50e`0166f620 fffff800`14982e01 : fffff80d`00000004 ffffe50e`0166f7c8 ffffe50e`0166f7c8 ffffe50e`0166f919 : nt!PopInvokeWin32Callout+0x11e
ffffe50e`0166f700 fffff800`14982ab5 : fffff80d`a7c6bc2c fffff80d`a7c61130 ffffe50e`0166f7c8 00000000`00000001 : nt!PopDispatchStateCallout+0xa1
ffffe50e`0166f770 fffff800`149857c5 : 00000000`00000001 ffffffff`fffe7960 ffffe50e`0166f810 fffff800`14327401 : nt!PoBlockConsoleSwitch+0x31
ffffe50e`0166f7a0 fffff80d`a7c77a57 : ffffd404`26c58040 fffff80d`a7c67860 ffffc385`1c3cdd7c 00000000`00000092 : nt!PopBlockSessionSwitch+0x45
ffffe50e`0166f800 fffff80d`a7c628e3 : ffffd404`ffffffff ffffd404`1da542d0 00000000`00000000 ffffd404`26c583b0 : pdc!PdcMonitorControl+0x27
ffffe50e`0166f830 fffff80d`a7c7aaca : 00000000`00000001 ffffd404`00000000 00000000`00000000 ffffd404`1da542d0 : pdc!PdcpTriggerActionByCaps+0x1a3
ffffe50e`0166f970 fffff80d`a7c7a5cf : 00000000`00000001 ffffd404`1da542d0 ffffd404`1da3e540 ffffd404`1f8ad870 : pdc!PdcpHandleSwitch+0x346
ffffe50e`0166fae0 fffff80d`a7c7af6b : 00000000`00000000 00000000`00000000 00000000`00000001 fffff800`146a3200 : pdc!PdcSystemButtonHandler+0xcf
ffffe50e`0166fb20 fffff80d`a7c62cd0 : 00000000`00000800 fffff800`145e67c0 ffffd404`1c8bec80 fffff800`1436de10 : pdc!PdcpPolicyWorkerMain+0x2b
ffffe50e`0166fb50 fffff800`142ac145 : ffffd404`26c58040 ffffd404`1c8bec80 fffff800`1460ef00 fffff80d`a8054150 : pdc!PdcpPolicyWorkerThread+0x70
ffffe50e`0166fb80 fffff800`143a26e7 : ffffd404`26c58040 00000000`00000080 ffffd404`1c8dd440 ffffd404`26c58040 : nt!ExpWorkerThread+0xf5
ffffe50e`0166fc10 fffff800`14408036 : fffff800`13084180 ffffd404`26c58040 fffff800`143a26a0 33333333`33333333 : nt!PspSystemThreadStartup+0x47
ffffe50e`0166fc60 00000000`00000000 : ffffe50e`01670000 ffffe50e`0166a000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

0: kd> dps ffffe50e0166a000 ffffe50e01670000
...
ffffe50e`0166d880  ffffd404`2002a430
ffffe50e`0166d888  ffffe50e`0166da28
ffffe50e`0166d890  00000000`00000286
ffffe50e`0166d898  fffff80d`a7ed354c*** ERROR: Module load completed but symbols could not be loaded for secnvme.sys
 secnvme+0x354c
ffffe50e`0166d8a0  00000000`00000000
ffffe50e`0166d8a8  ffffe50e`0166d938
ffffe50e`0166d8b0  00000000`00000005
...

0: kd> lmvm secnvme
Browse full module list
start             end                 module name
fffff80d`a7ed0000 fffff80d`a7ef2000   secnvme    (no symbols)           
    Loaded symbol image file: secnvme.sys
    Image path: \SystemRoot\System32\drivers\secnvme.sys
    Image name: secnvme.sys
    Browse all global symbols  functions  data
    Timestamp:        Thu Oct 12 11:28:59 2017 (59DF35DB)
    CheckSum:         0002935A
    ImageSize:        00022000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4


But, I am more curious about this.
Code:
[Memory Device (Type 17) - Length 40 - Handle 005ah]
  Physical Memory Array Handle  0058h
  Memory Error Info Handle      [Not Provided]
  Total Width                   72 bits
  Data Width                    72 bits
  Size                          8192MB
  Form Factor                   09h - DIMM
  Device Set                    [None]
  Device Locator                DIMM_A1
  Bank Locator                  NODE 1
  Memory Type                   1ah - Specification Reserved
  Type Detail                   0080h - Synchronous
[COLOR="#FF0000"]  Speed                         2800MHz[/COLOR]
  Manufacturer                  Undefined
  Serial Number                         
  Asset Tag Number                              
  Part Number                   CMK32GX4M4A2666C16
According to the specs of the model, the tested speed is 2666MHz so I am wondering if you're aware of this speed.
 
That is unusual. It should be at 2666MHz. Though honestly, even the BIOS doesn't seem to report the frequency correctly - It claims its running at 2133Mhz when XMP is enabled. CPU-Z reports the correct frequency though:
https://i.imgur.com/Wx0BF1O.png

It used to report correctly, but since installing my Samsung 960 SSD and enabling the WINDOWS 8/10 WHQL SUPPORT setting (As I was evidently supposed to when installing an M.2 drive) it hasn't always. Could this possibly be behind this? Should I upload the other DMP files as well for comparison?

Also, my cooling system is the Corsair H100i v2, my PSU is the Corsair RM750X, and my case is a CoolerMaster Trooper.
 
Could you revert it back to the SPD speed
 
To be sure, I've cleared my CMOS and only enabled WHQL/XMP Profile 1. I don't manually overclock my hardware, so it should be running at SPD.

However, I believe that it may be a limitation in the data collection software that's getting it to report a frequency of 2800MHz. Opening up Task Manager, it too reports 2800MHz. Apparently, this is simply an error as Task Manager is not designed to actually read the BIOS settings, it just reports what the manufacturer claims it can run at. (So was said here, anyways: Wrong RAM speed in Windows Task Manager - Windows 10 Forums). According to my SPD Timings Table, the default XMP Profile 2 will actually set the frequency to 2800MHz at 1.35V, which is probably why Task Manager thinks it's running at that frequency - it's just reporting what Corsair claimed it can safely run at. Since the same information is probably what's being written to the DMP file, that would explain the discrepancy.

CPU-Z vs Task Manager:
https://i.imgur.com/fRPvIWB.png

Here are my SPD timings:
https://i.imgur.com/Z1qY2Kc.png
 
The RAM data is from the PdcLockWatchdog dump you uploaded, the file with the RAM data from the tool is empty.

I don't want to argue with you, but if this would be true then I wonder why task manager shows 2133MHz for my RAM instead of 2400MHz for which it was designed to run at.
Apparently, this is simply an error as Task Manager is not designed to actually read the BIOS settings, it just reports what the manufacturer claims it can run at.

CPU-z shows for me 2400/1200 with XMP2.0 which is not entirely true, the motherboard I use lists my RAM at 2400 with a downgrade to 2133MHz.
 
I certainly could be mistaken, I'm just going off the information I'm finding on other threads. From what I can gather, there are many accounts where Windows' Task Manager tends to get that particular bit of information wrong, reporting frequencies that are either too high or too low. It might logically follow that Windows' Watchdog dumps would also make the same mistake since it probably gets that information the same way as the Task Manager.

In either case, my BIOS is now correctly reporting the current frequency as being at 2666MHz, (which seems to be backed up CPU-Z), and I'm more inclined to trust what the mainboard is reporting rather than the OS.
 
If possible, please configure the BIOS to use the SPD speed.
 
I've now done so. Had another freeze this morning and upon rebooting though, and I got an error stating that "The previous overclock settings have failed, system has been restored to its default settings". I've seen this a few times now when booting, though usually only after changing anything hardware-related. No crash dumps were saved this time that I can see. Even with XMP off, Windows still thinks I'm running at 2800MHz. https://i.imgur.com/SvZfBhf.png

I'm really at a loss on this one. Does nothing in those logs indicate what the problem may be? Is there something confusing about what they're reporting? At this point I just wonder if the motherboard is simply failing. Or maybe the power supply?
 
If you would upload a Speccy report I can take a look. It shows things the Sysnative doesn't show.


  • Please download Speccy System Information Tool and save it to somewhere convenient such as your desktop.
  • Close any programs that may be running including your browser and double click Speccy.exe to run the tool.
  • Watch out for any offers to install other programs such as google chrome and untick the box(es) if you don't want them.
  • Speccy will very quickly scan your pc and create a report.
  • Top left of screen click file and select Publish Snapshot...
  • Click Yes to proceed.
  • Copy the URL to your clipboard and paste it into your next reply.
 
I found this in the SMART Values on your HDD. The normal G-Sense Rate is 58. This indicates that the head mechanism may be failing.

Attribute name:
G-sense error rate

Real value: 2,435

Current: 99

Worst: 99


Threshold: 0


Raw Value: 0000000983
 
I can't find any information pertaining to the current or worst where the G-Sense is related - do you have a source on the "normal" G-Sense Rating? It is really unusual that the real value is so high, though. It seems to increment by 1 every half hour even when the HDD (And the rest of the computer) is idle. Dunno what could be causing that, given it's supposed to detect external movement. The computer's resting on a hardwood floor and I'm not banging it around or anything. I did note a few months back that it does seem to perform slightly worse than expected, only delivering around R160MB/s W130MB/s on sequential benchmarks. Otherwise however, it hasn't given me any trouble...

I've also unplugged an HDMI>DP cable that I've previously been using to connect my monitor to my GPU for the sake of the Vive - apparently it's not unheard of for a dodgy cable to cause BSODs and the like under certain circumstances, and that's the only other thing that has "changed" since these freezes began occurring. Will see if that helps, I suppose.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top