After bringing our databases to new servers with new hardware and new os (2012 server) and new SQL Server version (2016 sp1) we face the following issue:

During nightly reporting database update runs, the SQL Server service suddenly gets into trouble. Those report DB updates are performed using merge statements that collect, update and insert delta within multiple steps. The first step of the job started at 01:00 AM and caused around 500 Mio IO READS, but it succeeded. The second step started at 01:31 am but failed. It's all not highly efficient, I know and I also know there are still lots of indexes that have to be created to make those queries and the whole process more efficient. But this is not the point. Nobody cares if it would take some hours.

The point is that so far on the old SQL Server systems, those same procedures took long, but they never made the SQL Server stumble.

Now, we observe the following: The jobs start and run for a while, around 30 minutes and complete some job steps. During 01:35 and 01:55 AM the CPU load gets close to or to 100%. Between 01:55 AM and 02:11 AM the load varies btw 70% an 95%.

In the SQL logs we see those entries btw 01.35 and 01:53.:

**Unable to get thread context for spid 0 BEGIN STACK DUMP:

05/18/17 01:35:02 spid 5416

Non-yielding Scheduler

Stack Signature for the dump is 0x0000000000000266

External dump process return code 0x20000001.

External dump process returned no errors.

Process 62:0:7 (0x3ab4) Worker 0x00000066A0FD8160 appears to be non-yielding on Scheduler 0. Thread creation time: 13139533134164. Approx Thread CPU Used: kernel 0 ms, user 50156 ms. Process Utilization 97%. System Idle 1%. Interval: 73484 ms.

Process 62:0:6 (0x3b64) Worker 0x00000066A0FBC160 appears to be non-yielding on Scheduler 1. Thread creation time: 13139503419122. Approx Thread CPU Used: kernel 0 ms, user 57343 ms. Process Utilization 95%. System Idle 3%. Interval: 78640 ms.

Process 0:0:0 (0x2464) Worker 0x00000066A0E42160 appears to be non-yielding on Scheduler 2. Thread creation time: 13139456436014. Approx Thread CPU Used: kernel 15 ms, user 62515 ms. Process Utilization 94%. System Idle 4%. Interval: 71437 ms.

Process 62:0:5 (0x1688) Worker 0x00000066A0E46160 appears to be non-yielding on Scheduler 3. Thread creation time: 13139225220768. Approx Thread CPU Used: kernel 0 ms, user 53156 ms. Process Utilization 95%. System Idle 3%. Interval: 73437 ms.

SQL Trace ID 2 was started by login "mydomain\mySentryOneServiceUser".

I/O is frozen on database SDB. No user action is required. However, if I/O is not resumed promptly, you could cancel the backup.

A time-out occurred while waiting for buffer latch -- type 3, bp 000000751B746240, page 4:218376, stat 0x10f, database id: 2, allocation unit Id: 6488064, task 0x00000066A0FEE8C8 : 5, waittime 300 seconds, flags 0x1000000019, owning task 0x00000066A0DF5848. Not continuing to wait.

At 01:53 the netapp SnapManager tasks start to fail taking snapshots:

Error: 3041, Severity: 16, State: 1. BACKUP failed to complete the command BACKUP DATABASE DB1. Check the backup application log for detailed messages.

Between the same timeslots, Job Agent log shows this:
01:36 AM - 02:08 AM

[298] SQLServer Error: 65535, SQL Server Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF]. [SQLSTATE 08001]

[165] ODBC Error: 0, Login timeout expired [SQLSTATE HYT00]

[298] SQLServer Error: 65535, A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online. [SQLSTATE 08001]

[382] Logon to server 'xxx\xxx' failed (ConnUpdateStartExecutionDate)

Most of them repeat multiple times per minute.

This is the CPU spec: INTEL XEON E5-3690 v3 30M 4x 2,6GHz 4 virtual CPUs Software: Microsoft SQL Server Enterprise (64-bit) 13.0.4001.0 Instance Settings: All settings are default, MAXDOP = 4, CTFP = 50, system memory=64 GB, SQL MAX_MEMORY = 58982


Current time is 01:35:02 05/18/17.                                                                               

BugCheck Dump                                                                                             

This file is generated by Microsoft SQL Server                                                                   
version 13.0.4001.0                                                                                              
upon detection of fatal unexpected error. Please return this file,                                               
the query or program that produced the bugcheck, the database and                                                
the error log, and any other pertinent information with a Service Request.                                       

Computer type is Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz.                                                      
Bios Version is INTEL  - 6040000                                                                                 
PhoenixBIOS 4.0 Release 6.0                                                                                      
4 X64 level 8664, 2 Mhz processor (s).                                                                           
Windows NT 6.2 Build 9200 CSD .                                                                                  

MemoryLoad = 94%                     
Total Physical = 65535 MB            
Available Physical = 3317 MB         
Total Page File = 73535 MB           
Available Page File = 10601 MB       
Total Virtual = 134217727 MB         
Available Virtual = 134041378 MB     
***Unable to get thread context for spid 0                                                                       
* *******************************************************************************                                
* BEGIN STACK DUMP:                                                                                              
*   05/18/17 01:35:02 spid 5416                                                                                  
* Non-yielding Scheduler                                                                                         
* *******************************************************************************                                

What can I do to prevent the system from running into trouble and getting all those error log entries? Is there configuration to check?

  • Make sure you're patched up and open a ticket with Microsoft. Non-yielding schedulers typically aren't problems you can fix. May 18, 2017 at 10:07
  • What trace flags are being used ?
    – Kin Shah
    May 18, 2017 at 11:37
  • @Kin on the affected instances no traceflags are enabled.
    – Magier
    May 18, 2017 at 17:54
  • your best bet is to open a support ticket with Microsoft. Are you willing to share the dump file? (Disclaimer, I work for Microsoft) May 19, 2017 at 20:37
  • Sean we thought about it, but we expect them to tell us to install latest Updates first. So we installed latest CU yesterday and since that it didn't happen again. Although there is no fix included I expected to help us here. So I hope it is this. However I would share the dump in case someone is interested.
    – Magier
    May 19, 2017 at 21:12

1 Answer 1


I know this is an old post, but just in case somebody searches for this issue.... Check if a DBCC check is running at the same time. If so, then I'd suspect that the DBCC snapshot files are not excluded from a virus scan. Our CISCO AMP scanning the alternate data stream prevented database connections and generated non-yielding scheduler errors. Excluding the mdf files is not enough.

Microsoft recommended exclusions

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.