FIX: Access violation and "No exceptions should be raised by this code" error occur when you use SQL Server 2012 or SQL Server 2014

Applies to: SQL Server 2012 DeveloperSQL Server 2012 EnterpriseSQL Server 2012 Standard More

Symptoms


Assume that you use Microsoft SQL Server 2012 or SQL Server 2014. When a deadlock occurs in SQL Server, you receive the following access violation that is caused by the deadlock monitor:
sqldk!CSlotGroup::PshRelease
sqldk!CSlotPageMgr::Release
sqllang!commondelete
sqllang!delete[]
sqllang!CTraceDataSTVF::InternalReleaseResources
sqllang!TTableBase<CTraceDataSTVFInfo>::ReleaseResources
sqllang!CTraceDataSTVF::{dtor}
sqllang!CTraceDataSTVF::`scalar deleting destructor'
sqlmin!CSTVFInternal::Release
sqlmin!CQueryExecContext::~CQueryExecContext
sqlmin!CQueryInstance::ShutdownQueryExecContext
sqlmin!CQueryScan::ShutdownQueryExecContext
sqlmin!CQueryScan::DestroyQueryOnException
sqllang!CXStmtQuery::ShutdownOnException
sqllang!CXStmtQuery::FinishOnExceptionImp
sqllang!GetInterruptTicks
sqllang!InterruptTicks<unsigned __int64>::LoadTicks
sqllang!SOS_Ticks<InterruptTicks<unsigned __int64>,-3>::LoadTicks
sqllang!`CMsqlExecContext::FExecute'::`1'::catch$3
msvcr100!_CallSettingFrame
msvcr100!__CxxCallCatchBlock
ntdll!RcFrameConsolidation
sqllang!CMsqlExecContext::FExecute
sqllang!CSQLSource::Execute
sqllang!CStmtExecProc::XretLocalExec
sqllang!CStmtExecProc::XretExecExecute
sqllang!CXStmtExecProc::XretExecute
sqllang!CExecStmtLoopVars::ExecuteXStmtAndSetXretReturn
sqllang!CMsqlExecContext::ExecuteStmts<1,0>
sqllang!CMsqlExecContext::FExecute
sqllang!CSQLSource::Execute
sqllang!ExecuteSql
sqllang!CSpecProc::ExecuteSpecial
sqllang!CSpecProc::Execute
sqllang!process_request
sqllang!process_commands
sqldk!SOS_Task::Param::Execute
sqldk!SOS_Scheduler::RunTask
sqldk!SOS_Scheduler::ProcessTasks
sqldk!SchedulerManager::WorkerEntryPoint
sqldk!SystemThread::RunWorker
sqldk!SystemThreadDispatcher::ProcessWorker
sqldk!SchedulerManager::ThreadEntryPoint
kernel32!BaseThreadInitThunk
ntdll!RtlUserThreadStart
After the access violation, you receive the following error message from the SQL Server error log:
<Date> <Time> spid<ID> Using 'dbghelp.dll' version '4.0.5'
<Date> <Time> spid<ID> **Dump thread - spid = <ID>, EC = 0x0000007F8608E160
<Date> <Time> spid<ID> ***Stack Dump being sent to <File Path>\<Dump FileName>.txt
<Date> <Time> spid<ID> * *******************************************************************************
<Date> <Time> spid<ID> *
<Date> <Time> spid<ID> * BEGIN STACK DUMP:
<Date> <Time> spid<ID> * <Date> <Time> spid <ID>
<Date> <Time> spid<ID> *
<Date> <Time> spid<ID> * Location: qxcntxt.cpp:1143
<Date> <Time> spid<ID> * Expression: !"No exceptions should be raised by this code"
<Date> <Time> spid<ID> * SPID: <ID>
<Date> <Time> spid<ID> * Process ID: 3556
<Date> <Time> spid<ID> *
<Date> <Time> spid<ID> * Input Buffer 37 bytes -
<Date> <Time> spid<ID> * 16 00 00 00 12 00 00 00 02 00 00 00 00 00 00 00 00 00
<Date> <Time> spid<ID> * ÿÿ & 01 00 00 00 ff ff 0c 00 00 00 00 00 26 04 04 05 00 00
<Date> <Time> spid<ID> * 00
<Date> <Time> spid<ID> *
<Date> <Time> spid<ID> *
...
<Date> <Time> spid<ID> Stack Signature for the dump is 0x000000014202549F
<Date> <Time> spid<ID> [INFO] Identity Begin End | State Result Error Speculate Prepared LazyCommit ReadOnly | Transaction Database ThreadId | ReadSet WriteSet ScanSet Savepoint LogSizeRq | CommitDep TotalComm Dependent 0 Dependent 1 Dependent 2 Dependent 3 Dependent 4 Dependent 5 Dependent 6 Dependent 7 | Area Location |
<Date> <Time> spid<ID> Timeout waiting for external dump process 11800.

<Date> <Time> spid<ID> Error: 17066, Severity: 16, State: 1.
<Date> <Time> spid<ID> SQL Server Assertion: File: <qxcntxt.cpp>, line=1143 Failed Assertion = '!"No exceptions should be raised by this code"'. This error may be timing-related. If the error persists after rerunning the statement, use DBCC CHECKDB to check the database for structural integrity, or restart the server to ensure in-memory data structures are not corrupted.

Resolution


Cumulative Update information

The issue was first fixed in the following cumulative update of SQL Server.

Status


Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.