Windows 10: BugCheck PDC_WATCHDOG_TIMEOUT 14f

Hello,I've had a problem with my ROG Zephyrus M15 running Windows 10 where it restarts while it is supposed to be sleeping. I am fairly certain that it only happens while the lid is closed. I will regularly come back and find that my laptop has restarted with no indication that it should have.I've done my best to figure out why this is and how to fix it, but I haven't found much to try. I've included 3 dmp files, my MSinfo32 information, and a sleep study in response to one of the potential solutions that I found. Any help would be greatly appreciated.Thanks!https://1drv.ms/u/s!AgFcCRW-cQloh0U

:)

 

BugCheck PDC_WATCHDOG_TIMEOUT (14f) - PdcpMonitorOnWatchdogWorker

I'm having this issue as well with Surface Pro 4. I was hoping the April 2016 software and firmware updates would rectify the problem but it did not.

After getting three or four crashes in a matter of hours one day, I've disabled the sleep while plugged in and have not encountered the problem since.

*********************************************************

* *

* Bugcheck Analysis *

* *

*********************************************************

PDC_WATCHDOG_TIMEOUT (14f)

A system component failed to respond within the allocated time period,

preventing the system from exiting connected standby.

Arguments:

Arg1: 0000000000000000, Client ID of the hung component.

Arg2: 0000000000000100, Win32k did not complete a monitor-on request in a timely manner.

Arg3: 0000000000000000, The most recent POWER_MONITOR_REQUEST_REASON value for this request.

Arg4: 000000004f4d524d, A value indicating the internal path taken to initiate the request.

 

BugCheck PDC_WATCHDOG_TIMEOUT (14f) - PdcpMonitorOnWatchdogWorker

Has anyone found a solution to this problem?

I am also just encountering the exact same problem on my Surface Pro 2017 and Surface Book 2 (both on 1709) and not on docks. When the devices are on idle/sleep mode, the device will restart or blue screen with pdc.sys as the faulting driver, and 0x14F_DAM_IMAGE_dam.sys
as the faulting bucket id. This is occurring multiple times a day.

I have gone through updating all drivers/firmware, and re-imaging with same results.

Bugcheck Analysis

============

PDC_WATCHDOG_TIMEOUT (14f)

A system component failed to respond within the allocated time period,

preventing the system from exiting connected standby.

Arguments:

Arg1: 0000000000000004, Client ID of the hung component.

Arg2: 0000000000000002, A resiliency client failed to respond.

Arg3: fffff8021bffbe78, Pointer to the resiliency client (pdc!_PDC_RESILIENCY_CLIENT).

Arg4: ffffc60b2ec3fa60, Pointer to a pdc!PDC_14F_TRIAGE structure.

 

BugCheck PDC_WATCHDOG_TIMEOUT (14f) - PdcpMonitorOnWatchdogWorker

I have the exact same problem - same SP4 configuration as you. Two Dell P2414H DP monitors connected to the Surface Dock via mDP to DP cables (v1.2). No daisy chaining.

The minidmp is located
here.

What I commonly see is the monitors not coming on at all and I have to reconnect the SP4 dock several times a day to get the monitors to work, but every so often I come back to my SP4 and it has already rebooted. Pretty much the same story as everyone else.
All of the SP4s at our company have this behavior. It's the one reason I'm glad we stayed at pilot phase instead of rollout, as it stands (considering my setup is identical to the other two employees in the pilot) this would have resulted in a massive loss
in productivity.

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

PDC_WATCHDOG_TIMEOUT (14f)

A system component failed to respond within the allocated time period,

preventing the system from exiting connected standby.

Arguments:

Arg1: 0000000000000000, Client ID of the hung component.

Arg2: 0000000000000100, Win32k did not complete a monitor-on request in a timely manner.

Arg3: 0000000000000000, The most recent POWER_MONITOR_REQUEST_REASON value for this request.

Arg4: 0000000050434c45, A value indicating the internal path taken to initiate the request.