Search

Non-yielding IOCP Listener by bankielewicz

Closed
as Won't Fix Help for as Won't Fix

11
0
Sign in
 to vote
Type: Bug
ID: 503727
Opened: 10/26/2009 8:48:49 AM
Access Restriction: Public
0
Workaround(s)
5
User(s) can reproduce this bug
2009-10-20 05:01:11.23 Server     Using 'dbghelp.dll' version '4.0.5'
2009-10-20 05:01:11.28 Server     **Dump thread - spid = 0, PSS = 0x00000000, EC = 0x00000000
2009-10-20 05:01:11.28 Server     ***Stack Dump being sent to D:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\LOG\SQLDump0001.txt
2009-10-20 05:01:11.28 Server     * *******************************************************************************
2009-10-20 05:01:11.28 Server     *
2009-10-20 05:01:11.28 Server     * BEGIN STACK DUMP:
2009-10-20 05:01:11.28 Server     * 10/20/09 05:01:11 spid 0
2009-10-20 05:01:11.28 Server     *
2009-10-20 05:01:11.28 Server     * Non-yielding IOCP Listener
2009-10-20 05:01:11.28 Server     *
2009-10-20 05:01:11.28 Server     * *******************************************************************************
2009-10-20 05:01:11.28 Server     * -------------------------------------------------------------------------------
2009-10-20 05:01:11.28 Server     * Short Stack Dump
2009-10-20 05:01:11.35 Server     Stack Signature for the dump is 0x0000015D
Details (expand)
Product Language
English

Version

SQL Server 2005 SP3

Category

SQL Engine

Operating System

Windows 2003 Enterprise
Operating System Language
US English
Steps to Reproduce
On 10/20/09, SQL server generated a minidump whose error should've been resolved with Cumulative update package 4 for SQL Server 2005 Service Pack 2.

My server is running version 9.0.4230. I suspect that this bug has been reintroduced in a later update.

http://support.microsoft.com/kb/941689
Actual Results
2009-10-20 05:01:11.23 Server Using 'dbghelp.dll' version '4.0.5'
2009-10-20 05:01:11.28 Server **Dump thread - spid = 0, PSS = 0x00000000, EC = 0x00000000
2009-10-20 05:01:11.28 Server ***Stack Dump being sent to D:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\LOG\SQLDump0001.txt
2009-10-20 05:01:11.28 Server * *******************************************************************************
2009-10-20 05:01:11.28 Server *
2009-10-20 05:01:11.28 Server * BEGIN STACK DUMP:
2009-10-20 05:01:11.28 Server * 10/20/09 05:01:11 spid 0
2009-10-20 05:01:11.28 Server *
2009-10-20 05:01:11.28 Server * Non-yielding IOCP Listener
2009-10-20 05:01:11.28 Server *
2009-10-20 05:01:11.28 Server * *******************************************************************************
2009-10-20 05:01:11.28 Server * -------------------------------------------------------------------------------
2009-10-20 05:01:11.28 Server * Short Stack Dump
2009-10-20 05:01:11.35 Server Stack Signature for the dump is 0x0000015D
Expected Results
Will this be resolved in a future update?

Platform

X64
File Attachments
0 attachments
Sign in to post a comment.
Posted by danwrockstar on 9/26/2011 at 11:56 AM
I'm seeing this error on 2008 R2 CU6. We just opened a support case and have uploaded our minidump. What are the additional diagnostic details that are available?
Posted by Microsoft on 1/28/2011 at 9:06 AM
Hello,

It has not been possible to determine the underlying cause of the non-yielding problem you encountered. In SQL Server 2008 this area of the code has been redesigned to provide better diagnostic information and make non-yield issues easier to resolve. So you should not encounter the same problem again in SQL Server 2008 and beyond.

Guy Bowerman - SQLOS Team
Posted by Microsoft on 10/4/2010 at 8:12 AM
This error message indicates a symptom of a problem. The root cause could be many issues including IO problems, high CPU utilization, or potentially a bug. In order to determine which one of these problems is contributing to a specific occurrence a user dump would be required. The best way to for that information to be collected and analyzed is to open a support case with CSS.

Thanks
Jerome Halmans
SQLOS
Posted by brucef on 10/4/2010 at 7:37 AM
No update on this item??
Posted by sporoy on 8/9/2010 at 4:00 AM
We had the similar issue same as gtsdba, when we switched from EMC to IBM disk subsystem, can it be a disk I/O problem?
Posted by gtsdba on 6/16/2010 at 3:34 AM
we started hitting these error messages when we switched from EMC to IBM disks. Happens only on one server at version 9.00.4262 (SP3 + CU5). High IO jobs such as backups, optimisations, integrity checks prone to failure. Any news on this, is it seen as a SQL bug or a disk IO subsystem problem?
Posted by Agent DBA on 2/8/2010 at 6:19 AM
We are regularly experiancing this issue we were on SP2CU11 and updated to SP3CU4 after reading the following article http://support.microsoft.com/default.aspx/kb/918483

Posted by Ivan Arjentinski on 2/3/2010 at 2:51 PM
Hi all,

I have used customer support and they found that the problem is with a DLL called IMON.DLL. This DLL is part of NOD32 2.7 antivirus.

I had other problems on other servers with the same IMON.DLL from NOD32 2.7, so that concluded the case.

They also pointed me to this article:
http://support.microsoft.com/kb/309422/en-us
Guidelines for choosing antivirus software
Posted by bankielewicz on 1/26/2010 at 11:26 AM
Are you suggesting that this is not a SQL bug and works as designed?
Posted by Microsoft on 1/19/2010 at 3:05 PM
Hi,
Thanks for additional information. I would suggest getting in contact with Customer Support for this as well so that additional information can be gathered.

Thanks,
Jerome Halmans
SQLOS
Posted by Ivan Arjentinski on 1/19/2010 at 1:42 PM
10.0.2746

I experienced this just now.

After the same dump, there were a lot (thousands) of messages similar to this:

IO Completion Listener (0xa3c) Worker 0x0000000005A541A0 appears to be non-yielding on Node 0. Approx CPU Used: kernel 15 ms, user 15 ms, Interval: 12875833.

Only Interval increases
Posted by Microsoft on 1/18/2010 at 10:11 AM
Hi,
This is not the same issue as in http://support.microsoft.com/kb/941689 although the message is the same. The issue at the root of the fix for that article is a delay in destroying connection context at logout that slows new connections. This issue is a delay in allocating memory for a new connection. This could be caused by memory pressure on the machine or by a high CPU condition. The best course of action here would be to open a case with SQL CSS so that additional diagnostics can be gathered from the machine when this issue is encountered.
Thanks,
Jerome Halmans
SQLOS
Posted by bankielewicz on 12/28/2009 at 6:07 AM
Hello,

Have you made your determination yet?

Regards,

Bryan
Posted by aaronbertrand on 12/6/2009 at 5:51 PM
I also saw this tonight on 9.00.4266 (SP3 + CU6).
Posted by Microsoft on 11/20/2009 at 8:52 AM
Dear Customer,
thank you for reporting this issue. we are currently taking a look at this issue to see if it was infact an issue we fixed in Yukon Sp2 that got reintroduced in Yukon SP3. we will get back to you on what we find out shortly.
thanks for your patience,
Madhan
Sign in to post a workaround.
© 2012 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement