Sqlserver.exe has stopped working

Question

Since installing Visual Studio 2015 Update 3 I have been getting the below error. It happens only when Visual Studio 2015 is open and happens whether I am running as a local

Answer 1

There is an ongoing thread about this crash on Microsoft's MSDN forum:

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/0c486ed7-9fdb-45f0-9fcd-342eadbb0476/sqlserverexe-crashing

Apparently, this crash occurs after upgrading to the most recent version of SSDT (14.0.60525.0).

A Microsoft employee suggested this as a fix:

We've investigated and believe that this happens when the query store feature is enabled in any database in the localdb server. You can work around this problem by disabling the query store feature in all localdb database instances. To find the names of databases that have query store enabled, run this query:

select [name] from sys.databases where is_query_store_on=1

Then for each database, disable query store by executing a query like so:

alter database DBNAME set query_store=off

Some reported this did not fix the issue for them, others that it did, so your success may vary.

See Microsoft employee Kevin Cunnane's comment below:

The fixed LocalDB.msi is included in the August release - available from msdn.microsoft.com/en-us/library/mt204009.aspx with update via the Visual Studio Extensions and Updates channel due in the next few weeks.

Answer 2

On your localDb run following script

DECLARE @name VARCHAR(50) 
DECLARE @query VARCHAR(max)   


DECLARE db_cursor CURSOR FOR  
SELECT name 
FROM  sys.databases 
WHERE is_query_store_on=1 and name NOT IN ('master','model','msdb','tempdb')  

OPEN db_cursor   
FETCH NEXT FROM db_cursor INTO @name   

WHILE @@FETCH_STATUS = 0   
BEGIN   

set @query = 'alter database  ['+ @name+']    set query_store=off'
      EXECUTE(  @query)

       FETCH NEXT FROM db_cursor INTO @name   
END   

CLOSE db_cursor   
DEALLOCATE db_cursor

this will fix problem for all databases

Answer 3

I know this is an old'ish post, but the issue is rearing up again since VS 2017 it seems... at least with my (SSDT) SQL database project... so in the hopes that this might help someone else...

The accepted answer works perfectly but is quite manual. The script provided by Mahdi makes it a little bit more automated. In both cases, however, you might (depending on your build/deploy setup) need to run the script on both of the master databases on (localdb)\mssqllocaldb and (localdb)\projectsv1, respectively.

In addition, the problem is that the property keeps getting restored every time you build and run with F5. As it turns out, though, there is a setting on the Debug tab of the project properties page, called Deploy database properties... clear (uncheck) this setting to ensure that the issue doesn't come back.

Note that: a) this is only for Debug mode; and b) it is only applicable to databases under (localdb).