{"id":1401,"date":"2017-06-04T22:16:21","date_gmt":"2017-06-04T22:16:21","guid":{"rendered":"http:\/\/www.theSQLReport.com\/?p=1401"},"modified":"2017-06-04T22:21:24","modified_gmt":"2017-06-04T22:21:24","slug":"troubleshooting-error-17189-severity-16-state-1","status":"publish","type":"post","link":"http:\/\/www.theSQLReport.com\/?p=1401","title":{"rendered":"Troubleshooting &#8211; Error: 17189, Severity: 16, State: 1"},"content":{"rendered":"<p>Troubleshooting the following Error:<\/p>\n<pre>2017-06-01 18:00:00.000 Logon\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Error: 17189, Severity: 16, State: 1.\r\n2017-06-01 18:00:00.000 Logon\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 SQL Server failed with error code 0xc0000000 to spawn a thread to process a new login or connection. Check the SQL Server error log and the Windows event logs for information about possible related problems. [CLIENT: xxx.xxx.xxx.xxx]<\/pre>\n<p>What I found that many times experiencing this error in SQL Server&#8217;s Errorlog, that &#8220;Error: 17189&#8221; was only a symptom, and that many times the root cause was the line above in SQL Server&#8217;s Errorlog.<\/p>\n<h5>Case 1:<\/h5>\n<p>In the first case shown below, in SQL Server&#8217;s Errorlog listed right above the &#8220;Error: 17189&#8221;, listed were I\/O stalls occurring.\u00a0 In this case, the Storage Administrator found that an I\/O switch to the SAN was overloaded, which contributed to SQL Server freezing up.\u00a0 Which no logins would occur on the database instance for the next minute.<\/p>\n<p><a href=\"http:\/\/www.theSQLReport.com\/wp-content\/uploads\/2017\/06\/SQLerrorlog_IOerror.jpg\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-1404 size-full\" src=\"http:\/\/www.theSQLReport.com\/wp-content\/uploads\/2017\/06\/SQLerrorlog_IOerror.jpg\" alt=\"SQLerrorlog_IOerror\" width=\"765\" height=\"364\" \/><\/a><\/p>\n<h4>Case 2:<\/h4>\n<p>In this case, the memory was set to high (less of 40% of the memory was used), and the &#8220;lock pages in memory&#8221; option was not set.\u00a0 The following error kept appearing in SQL Server&#8217;s Errorlog :<\/p>\n<pre>A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): xxx, committed (KB): xxx, memory utilization: 39%.<\/pre>\n<p>By correcting the &#8220;max server memory&#8221; setting, and setting in the group policy editor to &#8220;lock pages in memory&#8221;, the &#8220;Error: 17189&#8221; disappeared.<\/p>\n<p><a href=\"http:\/\/www.theSQLReport.com\/wp-content\/uploads\/2017\/06\/SQLerrorlog_PagingError.jpg\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-1403 size-full\" src=\"http:\/\/www.theSQLReport.com\/wp-content\/uploads\/2017\/06\/SQLerrorlog_PagingError.jpg\" alt=\"SQLerrorlog_PagingError\" width=\"1080\" height=\"134\" srcset=\"http:\/\/www.theSQLReport.com\/wp-content\/uploads\/2017\/06\/SQLerrorlog_PagingError.jpg 1080w, http:\/\/www.theSQLReport.com\/wp-content\/uploads\/2017\/06\/SQLerrorlog_PagingError-300x37.jpg 300w, http:\/\/www.theSQLReport.com\/wp-content\/uploads\/2017\/06\/SQLerrorlog_PagingError-768x95.jpg 768w, http:\/\/www.theSQLReport.com\/wp-content\/uploads\/2017\/06\/SQLerrorlog_PagingError-1024x127.jpg 1024w, http:\/\/www.theSQLReport.com\/wp-content\/uploads\/2017\/06\/SQLerrorlog_PagingError-210x26.jpg 210w\" sizes=\"(max-width: 1080px) 100vw, 1080px\" \/><\/a><\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Troubleshooting the following Error: 2017-06-01 18:00:00.000 Logon\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Error: 17189, Severity: 16, State: 1. 2017-06-01 18:00:00.000 Logon\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 SQL Server failed with error code 0xc0000000 to spawn a thread to process a &hellip; <a class=\"readmore\" href=\"http:\/\/www.theSQLReport.com\/?p=1401\">Continue Reading &rarr;<\/a><\/p>\n","protected":false},"author":1,"featured_media":1404,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[99,100],"class_list":["post-1401","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sql-server","tag-99","tag-sql-servers-errorlog"],"_links":{"self":[{"href":"http:\/\/www.theSQLReport.com\/index.php?rest_route=\/wp\/v2\/posts\/1401"}],"collection":[{"href":"http:\/\/www.theSQLReport.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.theSQLReport.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.theSQLReport.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.theSQLReport.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1401"}],"version-history":[{"count":14,"href":"http:\/\/www.theSQLReport.com\/index.php?rest_route=\/wp\/v2\/posts\/1401\/revisions"}],"predecessor-version":[{"id":1417,"href":"http:\/\/www.theSQLReport.com\/index.php?rest_route=\/wp\/v2\/posts\/1401\/revisions\/1417"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/www.theSQLReport.com\/index.php?rest_route=\/wp\/v2\/media\/1404"}],"wp:attachment":[{"href":"http:\/\/www.theSQLReport.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1401"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.theSQLReport.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1401"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.theSQLReport.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1401"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}