> 1: Return Address 78002244
> cs=1b ss=23 ds=23 es=23 fs=3b gs=0
> ebp=07313000 efl=00010293
> esi=073141d8 edi=00000008 eip=78002244 esp=07313000
> eax=073141c8 ebx=073141c8 ecx=07313030 edx=00000000
> Address=78002244 Exception Code = c00000fd
> 05/27/03 14:04:58 Stack Overflow Dump not possible -
> Exception c00000fd E at 0x78002244
> And NT Error Log:
> The MSSQLSERVER service terminated unexpectedly. It has
> done this 1 time(s). The following corrective action will
> be taken in 0 milliseconds: No action.
Q. I am getting a message 'dbprocess dead' or 'language exec' from SQL
I am seeing an 'Exception Access Violation' message in the SQL errorlog.
I am getting an error SqlDumpExceptionHandler: Process <x> generated fatal
I am getting *.DMP files in the <sql>\log directory.
I am getting "symptom dump" messages.
What is going on?
A. Basically SQL is internally gpf'ing/AV'ing (same thing). You should see
one or more of the above messages in the SQL errorlog.
There are only three reasons for this to happen (in order of ascending
1. A database corruption - you should rule this out by running dbcc checkdb,
newalloc and checkcatalog commands.
2. A hardware problem - usually a faulty SIMM/DIMM memory chip. Run vendor
supplied diagnostic routines and/or sqlhdtst/sql7iostress utilities to check
out the hardware. See Q231619 "INF: SQL70IO Stress Utility to Stress Disk
Subsystem", Q135582 "INF: SQL Server Utility Files Available"
3. Bugs in the SQL Server code (this is the most likely cause - a database
corruption rarely cause gpf's, and hardware errors normally show up in other
ways). This is the Microsoft C code that makes up SQLSERVR.EXE and associated
dll's, NOT your TSQL code. If you have SQL code that causes an AV it is
Microsoft's bug, not yours. There is nothing anyone outside of Microsoft
support can do to help you.
Assuming it's not a database corruption/hardware fault, then follow the
following diagnostic process :-
1. Check the Microsoft Kb on TechNet (if you don't have TechNet then order it
now!). Also check the on-line website at http://support.microsoft.com which is
more up to date than TechNet. Search on: kbbug* AND AV AND "SQL Server" to
find all documented AV bugs - note AV's are a generic symptom of lots of bugs.
Many articles contain workarounds but it is usually difficult to match up the
stack traces listed to see if it is relevant to your particular problem.
2. Are you on the latest version of SQL Server and the latest service pack?
Microsoft fix a lot of AV errors in every service pack, so it is definitely
worth getting current. If you're not on the latest service pack then that is
the first thing Microsoft are going to ask you to do if you contact them
anyway. If you can't apply it to the production system immediately then apply
the latest SP on a test system and see if it fixes the problem.
3. Check the SQL errorlog and save away all the messages - especially anything
telling you what SQL was being executed at the time.
4. Check the \<sql>\LOG directory for SQLxxxx.DMP files that may have been
created. These contain information on what SQL Server was doing at the time,
module stack traces etc. Save these away for Microsoft support as necessary.
(Though there is a PRINTDMP.EXE utility supplied the output of this is still of
limited use without the SQL Server C source code, although you can sometimes
see the SQL command being run and who was running it)
5. Can you re-create the problem at will? If the SQL being run is not shown
in the errorlog, then find out what the user/developer was doing at the time.
Use SQL Trace/Profiler to capture the actual SQL code being run if you can. If
you can't recreate it, it's still worth reporting as long as you have the
errorlog(s) and dump file(s).
6. If you can re-create the problem, then see if you can create a reproduction
script to show the problem. This needs to be capable of running on a brand-new
install of SQL Server on a new database. Therefore it needs to contain all
tables, user defined data types, triggers, views etc. needed to show the
problem. If it needs data then try and keep this to a minimum. (If the
script/data is reasonably short then post to one of the
newsgroups and one of MVP's can report it to Microsoft for you). Alternatively
re-write your query (if possible) to run against the pubs or Northwind (v7
only) database as these are always installed with SQL Server and come complete
with a variety of tables, foreign keys, indices and data.
7. Can you work around the problem by re-writing the SQL? Even with a
reproduction script Microsoft are unlikely to turn a fix around quickly -
unless you are a multi-million dollar customer. And even then you wouldn't
just be applying one small fix, it would be a latest build with lots of other
fixes too - it won't have been regression tested, so it could cause more
problems than it fixed anyway.
8. If SQL Server terminates from the Access Violation and there is no dump
file produced then a possible cause of the problem is the use of SQL Trace.
There is a bug in this (fixed in 6.5 SP5 and above) that can terminate the SQL
Server being monitored. Another cause of this is heavy deadlocking - also
fixed in SP5a.
9. Report the problem to Microsoft PSS. PLEASE do this even if you can
workaround it. Unless Microsoft get these bug reports then they can't fix
them. See mspss FAQ entry for more details.
Microsoft will need you to supply :-
NT event log(s) - if any NT errors were occuring at the time
TSQL code running at the time
Details of hardware, version of NT, servicepacks etc. WINMSD output is good
With SQL 7 there is a new utility that will garner most of this information for
you automatically. It is called sqldiag -
sqldiag -U login -P password [-O output_file]
Applies to SQL Server versions : All
FAQ Categories : Troubleshooting
Related FAQ articles : reproscript, bugreport, mspss
Related Microsoft Kb articles : see references above
Other related information : n/a
Authors : Neil Pike
Neil Pike MVP/MCSE. Protech Computing Ltd
Reply here - no email
SQL FAQ (484 entries) see
(faqxxx.zip in lib 7)