Surface Pro 4 BSOD - Windows 10 x64

[cluberti]

There have been issues with the SP4 devices and power states since release, and while the vast majority of devices were fixed with the firmware update/driver package released last month, there is likely a small subset of poor folks who have hardware that isn't fixed with the update. First, make sure you've got the latest firmware and drivers (at least the release from February), as this fixes most sleep/power issues (these are the symptoms, btw - that and a device that doesn't shut down properly). If that doesn't work, I'd recommend either taking the device back for an exchange (this seems to work for people that I've known who still had issues after last month's firmware updates), or disable power management and see if the problem goes away. If doing the latter "fixes" the problem, and you're running the February or March firmware, you know your options at that point.

 

[invalid]

I think cluberti has some good advise and is likely the quickest path to resolution for you.

I reviewed the logs one more time after looking at Dev Center and I will share some thoughts below for anyone interested who has not seen these pages.

Since the Bios update from 103.873.768 to 104.1085.768 the bugcheck has been consistently the same.

Type A: 1-16-2016, 1-19-2016, 1-24-2016 (different internal path 4f4d524d and 50434c45)
Type B: 2-02-2016 was different altogether.

Type A

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.

Type B

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: 0000000000000001, A notification client failed to respond.
Arg3: ffffc000b13fa910, Pointer to the notification client (pdc!_PDC_NOTIFICATION_CLIENT).
Arg4: ffffd000529efb60, Pointer to a pdc!PDC_14F_TRIAGE structure.3: kd> dt pdc!_PDC_NOTIFICATION_CLIENT ffffc000b13fa910
   +0x000 Context          : _PDC_COMMON_CONTEXT
   +0x020 ClientId         : 4
   +0x024 ReplyReceived    : 0 ''
   +0x028 Control          : 0xfffff801`b55c7fe0 _PDC_NOTIFICATION_CONTROL
3: kd> dt 0xfffff801`b55c7fe0 _PDC_NOTIFICATION_CONTROL
pdc!_PDC_NOTIFICATION_CONTROL
   +0x000 NotificationType : 2 ( PdcDamNotification )
   +0x008 ClientContext    : (null) 
   +0x010 PdcSequence      : 0xbf3
   +0x018 Callback         : 0xfffff801`b55cea50     long  pdc!PdcpCommonNotificationCompleteCallback+0
   +0x020 Armed            : 0x1 ''
   +0x021 AllClientsResponded : 0 ''
   +0x022 WaitTimerExpired : 0x1 ''
   +0x023 CatchupReplyPending : 0 ''
   +0x024 CatchupRepliesBlockingTransition : 0 ''
   +0x028 PendingActivation : _PDC_ACTIVATE_NOTIFICATION_PARAMETERS
   +0x058 CurrentValue     : 0xb13fa910
   +0x05c ClientStatus     : 0n-16384
   +0x060 ClientList       : _LIST_ENTRY [ 0xffffc000`b1a3eb10 - 0x0000004b`1a6c1a45 ]
   +0x070 WatchdogTimeout  : 3

Since the BIOS update all crashes Mar 1 to present have the same signature
TYPE C

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: fffff80171837a58, Pointer to the resiliency client (pdc!_PDC_RESILIENCY_CLIENT).
Arg4: ffffd0007c4cdb60, Pointer to a pdc!PDC_14F_TRIAGE structure.
0: kd> dt pdc!_PDC_RESILIENCY_CLIENT fffff80171837a58
   +0x000 Context          : _PDC_COMMON_CONTEXT
   +0x020 ResiliencyType   : 3 ( PdcDamResiliency )
   +0x028 ClientReferences : 0
   +0x030 PoResiliencyClient : 0 ''
   +0x034 CurrentTransactionId : 0x90
   +0x038 OneTimeTransaction : 0 ''
   +0x03c CurrentState     : 0 ( ResiliencyClientPassive )
   +0x040 NextState        : 1 ( ResiliencyClientActive )
   +0x044 ClientId         : 4

So my thoughts are maybe there were a few different scenarios that would lead up to your issue and manifest in a slightly different way. Likley the updates may have resolve a few of these since we seeing some consistency now.

So to dig deeper into this one I would probably look to do the following. Keep in mind I've never worked with these systems or this technology so take it with a grain of salt.

1. ETW trace for modern standby and or Connected Standby energy efficiency assessments. Doing these correctly should have the right providers turned on to get good data during the assessment which should test entry and exit through the different phases. Either this will pass and give you a good baseline and knowledge into what you should see or it will fail hopefully give some insight as to where and proceed to step 2.

2. Configure complete or at least full kernel memory dumps and try and find the issue.



The documentation I found was for 8.1 connected standby or 10 modern standby and it does get confusing.

Connected Standby shows 6 Phases

Enter/Exit Connected Standby
This metric represents the total time, in seconds, that the computer spends entering and leaving Connected Standby. Each phase is divided into six sub-phases.
Low-Power Phase
This metric represents the time, in seconds, that the computer spends in the Low-Power phase, during which callback notifications for entering and leaving the low-power state are sent to registered drivers and services that were not suspended during the PLM phase or the DAM phase.
DAM Phase
This metric represents the time, in seconds, that the computer spends in the Desktop Activity Moderator (DAM) phase, during which the DAM suspends or resumes the execution of user-session desktop processes.
PLM Phase
This metric represents the time, in seconds, that the computer spends in the Process Lifetime Manger (PLM) phase, during which the PLM suspends or resumes the execution of Windows Store apps.
Resiliency Notification Phase
This metric represents the time, in seconds, that the computer spends in the Resiliency Notification phase, during which the PDC sends power notification events indicating that it will transition to resiliency next.
Maintenance Phase
This metric represents the time, in seconds, that the computer spends in the Maintenance phase, during which underlying maintenance activities are run.
Connection Phase
This metric represents the time, in seconds, that the computer spends in the Connection phase, during which Windows filters input and handles remote sessions.



Where modern standby shows

Topics	Description	Tasks performed	Exited when...	Typical duration (seconds)
No-CS phase Note This is also the phase where the device waits for the sleep timeout to elapse.	The system is powered on and the screen is turned on. The system is not in standby.	No standby preparation tasks are being performed.	The screen is powered down.	N/A
Connection phase	The system is checking for remote desktop connections.	Determine if remote desktop session(s) exist. Begin tracking outstanding power requests.	There are no remote desktop sessions connected.	Zero seconds if no remote desktop sessions are connected. Phase will last until all remote desktop sessions are disconnected or have timed out.
Presence phase	This phase is currently not used by Windows 8 or Windows 8.1.
Process Lifetime Manager (PLM) phase	The system suspends Windows Store apps that are in the foreground.	Suspend all foreground Windows Store apps. Check for ongoing non-offloaded audio playback or communications app activity.	All foreground Windows Store apps have been suspended and no non-offloaded audio playback is occurring.	Typically, less than five seconds. If non-offloaded audio playback is ongoing, this phase will block until audio playback stops. Audio playback may be part of a music or communications app.
Maintenance phase	The system executes maintenance tasks.	Wait for maintenance tasks to complete if running (most common on AC power).	No system maintenance tasks are running.	Typically, less than one second. The system is most likely to block on maintenance phase on AC power.
Desktop Activity Moderator (DAM) phase	The system pauses desktop applications to reduce their power consumption during standby.	Check for outstanding power requests (PowerRequestExecutionRequired). Wait for outstanding power requests to be dropped by the application, or enforce a maximum time-out on battery power (five minutes).	All outstanding power requests have been cleared by applications or the maximum time-out has been reached.	Typically, zero seconds. If the system is on battery power, outstanding power requests will cause this phase to block for a maximum of five minutes. The applications with power requests can be inspected by running Powercfg.exe with the /requests option. If the system is on AC power, outstanding power requests will cause this phase to block indefinitely or until the power request is cleared by the application.
Low-power phase	The system notifies registered subscribers that the power manager is entering a low-power, long-resume-latency phase. This is used by some devices as a hint to power down.	Notify registered subscribers.	All registered subscribers have been notified.	Typically, five seconds.
Resiliency notification phase	The network subsystem is notified to enter a low-power mode.	Notify the network subsystem. Network adapters that do not support modern connected standby are turned off (D3).	The network subsystem has been notified.	Typically, less than one second.
Resiliency phase	The system is ready for the SoC to enter the lowest power mode and remain idle for up to 30 seconds at a time.	PDC resiliency clients are notified that the system is in resiliency phase. Session-0 services are throttled by the DAM to no more than one second of activity every 30 seconds. Configure the system to wake up every 30 seconds for kernel maintenance. The power manager waits for activators to turn on their reference and cause the system to remain active.	The system exits standby due to user input or a power button press. The system transitions to maintenance phase to run system maintenance.	The majority of time the system is in standby.

As you can see its pretty complex and can take a huge amount of time and a very specific skill set. Its likely way cheaper just to replace hardware if that is likely to resolve the problem.


References:
Connected Standby energy efficiency
Results for the Connected Standby energy efficiency Assessment
Prepare software for modern standby - Windows 1 hardware dev