c# - update - Sqlserver.exe ha dejado de funcionar
visual studio 2015 update 1 download (4)
En su localDb ejecute el siguiente 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
esto solucionará el problema para todas las bases de datos
Desde que instalé la Actualización 3 de Visual Studio 2015 recibí el siguiente error. Sucede solo cuando Visual Studio 2015 está abierto y sucede tanto si me estoy ejecutando como administrador local o no. Es frecuente y es irritante, pero no parece afectar ningún trabajo que estoy haciendo. Código, Server Explorer, VS todo funciona bien, los mensajes de error aparecen y los informes de errores de Microsoft toman largos períodos de uso del 50% de mi CPU en el proceso.
¿Alguien sabe cómo arreglar esto? No quiero pasar horas tratando de resolverlo.
Mensaje de error:
En mi registro de eventos de la aplicación veo lo siguiente:
Contenedor de fallas 126419871336, tipo 5 Nombre del evento: SQLException64 Respuesta: No disponible ID de cabina: 0
Firma del problema: P1: sqlservr.exe P2: 0.0.0.0 P3: 0000000000000000 P4: sqlmin.dll P5: 2015.130.1601.5 P6: 000000005724AE98 P7: -1073741819 P8: 0000000000064BB2 P9: 00000001D8D946AB P10:
Archivos adjuntos: /? / C: / Users / m_f / AppData / Local / Microsoft / Microsoft SQL Server Local DB / Instances / ProjectsV13 / SQLDump0100.mdmp /? / C: / Users / m_f / AppData / Local / Microsoft / Microsoft SQL Servidor Local DB / Instances / ProjectsV13 / SQLDump0100.txt /? / C: / Users / m_f / AppData / Local / Microsoft / Microsoft SQL Server DB local / Instances / ProjectsV13 / SQLDump0100.log /? / C: / ProgramData / Microsoft / Windows / WER / Temp / WERE021.tmp.WERInternalMetadata.xml
Estos archivos pueden estar disponibles aquí: C: / ProgramData / Microsoft / Windows / WER / ReportArchive / Critical_sqlservr.exe_7113a987f49ac660cb71f97cb4183ea19827ef0_00000000_0bd7e949
Símbolo del análisis: volver a verificar la solución: 0 ID del informe: 3e38065a-5d62-11e6-89a7-97ade4354400 Estado del informe: 1 hash cubo: ff995718a61d049a3664662b84518798
Y en el registro de SQL:
El proceso 49 generó la excepción fatal c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server está finalizando este proceso.
También parece haber sido un problema conocido: consulte este artículo de Microsoft KB que dice que se ha corregido.
Mi sistema está lo más actualizado posible en términos de SO, parches, actualizaciones de seguridad, actualizaciones de Visual Studio, etc., pero todavía veo el problema. ¡Afortunadamente alguien ha resuelto esto antes y puede ahorrarme un poco de frustración tratando de resolverlo!
Gracias
Hay un hilo en curso sobre este accidente en el foro de MSDN de Microsoft:
Aparentemente, este bloqueo se produce después de actualizar a la versión más reciente de SSDT (14.0.60525.0).
Un empleado de Microsoft sugirió esto como una solución:
Hemos investigado y creemos que esto sucede cuando la función de consulta del almacén está habilitada en cualquier base de datos del servidor localdb. Puede solucionar este problema deshabilitando la función de consulta del almacén en todas las instancias de base de datos localdb. Para buscar los nombres de las bases de datos que tienen el almacén de consultas habilitado, ejecute esta consulta:
select [name] from sys.databases where is_query_store_on=1Luego, para cada base de datos, deshabilite el almacén de consultas ejecutando una consulta como esta:
alter database DBNAME set query_store=off
Algunos informaron que esto no solucionó el problema para ellos, otros lo hicieron, por lo que su éxito puede variar.
Vea el comentario de los empleados de Microsoft Kevin Cunnane a continuación:
El LocalDB.msi fijo se incluye en la versión de agosto, disponible en msdn.microsoft.com/en-us/library/mt204009.aspx con la actualización a través del canal Extensiones y actualizaciones de Visual Studio que vence en las próximas semanas.
Sé que esta es una publicación antigua, pero el problema está aumentando nuevamente desde VS 2017 parece ... al menos con mi proyecto de base de datos SQL (SSDT) ... así que con la esperanza de que esto pueda ayudar a alguien más ... .
La respuesta aceptada funciona perfectamente pero es bastante manual. El script proporcionado por Mahdi lo hace un poco más automatizado. En ambos casos, sin embargo, es posible que deba (en función de su configuración de compilación / implementación) ejecutar el script en ambas bases de datos master en (localdb)/mssqllocaldb y (localdb)/projectsv1 , respectivamente.
Además, el problema es que la propiedad sigue siendo restaurada cada vez que compila y ejecuta con F5 . Sin embargo, resulta que hay una configuración en la pestaña Depuración de la página de propiedades del proyecto, llamada Desplegar propiedades de la base de datos ... borre (desmarque) esta configuración para asegurarse de que el problema no vuelva.
Tenga en cuenta que: a) esto es solo para el modo de depuración ; y b) solo se aplica a bases de datos bajo (localdb).
Simplemente ejecute Visual Studio como administrador (simplemente haga clic derecho en el acceso directo de Visual Studio y seleccione ejecutar como administrador).