In SQL server 2025 version dump files are created after reboot, After checking its showing bug in the software

Question

In SQL server 2025 version dump files are created after reboot, After checking its showing bug in the software

Marugalla, Naresh (Ext) 0

***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\LOG\SQLDump0027.txt SqlDumpExceptionHandler: Process 13 generated fatal exception c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process. * *******************************************************************************

This file is generated by Microsoft SQL Server version 17.0.5015.4 upon detection of fatal unexpected error. Please return this file, the query or program that produced the bugcheck, the database and the error log, and any other pertinent information with a Service Request. Computer type is Intel(R) Xeon(R) Gold 6454S. Bios Version is INTEL - 6040000 VMW201.00V.24504846.B64.2501180339 4 X64 level 8664, 10 Mhz processor (s). Windows NT 10.0 Build 26100 CSD . Memory MemoryLoad = 18% Total Physical = 16383 MB Available Physical = 13352 MB Total Page File = 18815 MB Available Page File = 15929 MB Total Virtual = 134217727 MB Available Virtual = 134182274 MB ***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\LOG\SQLDump0027.txt SqlDumpExceptionHandler: Process 13 generated fatal exception c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process. * *******************************************************************************

Marugalla, Naresh (Ext) 0 Reputation points

2026-10-29T07:03:28.89+00:00

Lock pages are not running on any account please find the below snip

3 answers

Your answer

Marugalla, Naresh (Ext) 0 Reputation points

2026-10-29T07:03:28.89+00:00

Lock pages are not running on any account please find the below snip

Answer 1

Update: Erland pointed out that Naresh's ERRORLOG already shows -T4696 as a startup parameter, which I missed. That's the documented workaround for the known issue below, so this probably isn't the cause here. I've left the details in case they help someone on the same build, but the input buffer in SQLDump0027.txt is still the quickest way to see what's actually crashing.

One more thing worth checking. Your build, 17.0.5015.4, is the October security update for CU9 (KB5126967). Microsoft lists a known issue for this build that fits your symptoms closely: a dump on every restart, while SQL Server keeps running.

The known issue

The KB article calls it "Access violation when you query sys.dm_exec_requests during database recovery". If anything queries sys.dm_exec_requests while a database is still recovering, which includes startup recovery right after a restart, SQL Server can raise c0000005 EXCEPTION_ACCESS_VIOLATION and write a dump. A monitoring tool or a SQL Agent job that runs as soon as the service starts is the typical trigger. The issue is still listed as unfixed in CU10 (17.0.5035.5), so updating to CU10 alone won't fix it.

How to confirm it before changing anything

The dump text file names the statement that crashed. Open SQLDump0027.txt in the LOG folder and look for the Input Buffer section near the top. Then check two things.

What the input buffer shows. If it shows a query or procedure that reads sys.dm_exec_requests (or sys.sysprocesses), this known issue is very likely the cause. The program name or procedure name usually tells you which tool sent it.
What the ERRORLOG shows. The dump should appear while databases are still starting up or recovering, before the "Recovery is complete" message.

If the input buffer shows something unrelated, this isn't your issue, and Erland's suggestions plus a support case are the way forward.

If it is the known issue

Microsoft documents three workarounds:

Keep monitoring queries away from recovering databases. Delay the monitoring tool or Agent job until recovery completes after a restart. This is the least intrusive fix.
Trace flag 4696. This opts out of the code change that causes the crash. Because the dump happens at startup, it would need to be a startup parameter (-T4696 in SQL Server Configuration Manager). Its documented side effect is that monitoring queries on availability group secondary replicas can return errors 976 or 978, as they did before this update. As Erland said, don't add trace flags on a guess. Only use this one after the input buffer confirms the issue, and test it outside production first.
Uninstall the update until Microsoft ships a fix.

I drafted this answer with help from Copilot and verified the details myself, in line with the Microsoft Q&A AI usage policy.

Erland Sommarskog 138.6K Reputation points MVP Volunteer Moderator

2026-11-02T14:24:51.1133333+00:00

Paul, you have started to post here recently and your posts have been very insightful. However, I get a little concerned, when I find that your post start over and repeats itself. I may be wrong, but I have learnt to take this as a token of that the poster has been using AI.

I like to point out that there is an AI Usage Policy for Microsoft Q&A. It permits the usage of AI, however it requires that you state that you have used AI, and you are also supposed to verify the AI answer. Now, I don't know if you used AI to research the answer, or if you only used AI to brush up your draft. In the latter case, it can still be useful to say so. And you should definitely be careful to check that your post does not repeat itself.

As for the point is such, calling out the known issue is a good idea, and now I understand why the automatically generated AI answer to one of Naresh's earlier post suggested that trace flag. However, in the error log that Naresh shared, I see that -T 4696 is given as a startup parameter, so Naresh seems to be running into something else.

Still, I think it is a good idea, Naresh, if you investigate what monitoring tools you have in place, and if turning them off resolves the problem.
Paul Thomas 80 Reputation points

2026-11-02T16:29:47.3266667+00:00

@Erland Sommarskog Thank you, that's fair feedback. The repetition was a copy-paste mistake: the answer went in twice. I do use Copilot to help me research and draft, But I check the facts and test locally by running in my machine before posting, I will include it from here on. I've edited this answer to remove the duplicate, add the AI disclosure and sources, and note that -T4696 is already in Naresh's startup parameters, which I missed. Thanks for catching that.

Answer 2

Erland Sommarskog 138.6K MVP Volunteer Moderator

First, please don't post multiple questions about the same issue.

Next, for a situation like this, you do best in ignoring the AI answer. This is not likely to be a known issue that the AI has information about, so it is just guessing wildly. Or hallucinates. I saw that it suggested a trace flag in one of its responses. That is unlikely to be the solution. Rather, it could make matters worse.

So you get this dump every time SQL Server starts? Does SQL Server keeps on running, or is SQL Server entirely unusable?

Stack dumps like this are often tokens of a bug in SQL Server, and the best way to get them resolved is to open a support case with Microsoft. This should in the end be of no cost for you in the end, if the issue is indeed due to a bug. However, your organization would need to have a support contract.

However, if it occurs at startup, this suggests that there is something in your environments that triggers the problem, so you may want to investigate this.

Particularly, you should check if you have any of the following:

Unsafe assemblies.
External stored procedures, home-written or third-party writen.
Any use of the sp_OAxxxx procedures.
Linked servers using OLE DB providers or ODBC drivers from other vendors than Microsoft, and which runs in-process.

These are all things that could clobber SQL Server's own memory and lead to severe accidents.

I guess faulty hardware can also could cause accidents like this.

Marugalla, Naresh (Ext) 0 Reputation points

2026-10-29T12:00:09.95+00:00

there is no linked servers on those servers.

every restart dump files are creating

Ye, Its keep on running.
Erland Sommarskog 138.6K Reputation points MVP Volunteer Moderator

2026-10-29T14:26:47.21+00:00

Would it be possible to share the full errorlog? Please don't paste it into a window, but attach it as a file. You will need to rename it as ERRORLOG.txt for the forum software to accept it. It could be interesting to see if it crashes after some particular operation.
Marugalla, Naresh (Ext) 0 Reputation points

2026-10-29T15:00:08.5433333+00:00

Error log added
Erland Sommarskog 138.6K Reputation points MVP Volunteer Moderator

2026-10-29T16:56:54.82+00:00

Unfortunately, I don't see the errorlog attached. Can you try again?
Marugalla, Naresh (Ext) 0 Reputation points

2026-10-30T05:59:04.78+00:00

ERRORLOG.txt
Marugalla, Naresh (Ext) 0 Reputation points

2026-10-30T05:59:25.2033333+00:00

Attached again
Erland Sommarskog 138.6K Reputation points MVP Volunteer Moderator

2026-10-30T13:57:38.5066667+00:00
Got the file this time. The dump occurs right after these two lines in the errorlog:

2026-10-29 10:09:46.44 Server CLR version v4.0.30319 loaded. 2026-10-29 10:09:46.68 Server Common language runtime (CLR) functionality initialized using CLR version v4.0.30319 from C:\Windows\Microsoft.NET\Framework64\v4.0.30319.

It seems that the dump comes back later and here it says:

FIRST OCCURRENCE: Common Language Runtime escalation on non-critical resource.

As for why, loading the CLR as such would cause a crash, I don't know.

You could run this query to see if you have any unsafe assemblies at all on the server:

DECLARE @sql nvarchar(MAX) SELECT @sql = string_agg(convert(nvarchar(MAX), 'SELECT db = ') || quotename(name, '''') || N', assembly = name COLLATE DATABASE_DEFAULT, permission_set_desc FROM ' || quotename(name) || '.sys.assemblies WHERE is_user_defined = 1', char(13) + char(10) + 'UNION ALL' + char(13) + char(10)) FROM sys.databases PRINT @sql EXEC(@sql)

But even if you have a bad assembly on the server, I fail to see why it would cause a dump immediately when the CLR is loaded.

If you don't want to open a support case, you could try the Call Stack Resolver on https://github.com/microsoft/SQLCallStackResolver. But frankly, I would expect it to make you much wiser. I think a support case is the best to go.

Answer 3

Check the SQL Server startup log for Using locked pages in the memory manager; if it appears and this VM runs Windows Server 2025, disable Lock pages in memory (LPIM) for the SQL Server service account and restart Windows—the combination is a documented SQL Server 2025 access-violation issue.^1^

Apply the documented workaround

Open the current SQL Server ERRORLOG, normally under:

   C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\LOG

Search the startup section for:

   Using locked pages in the memory manager.

If that message is present:
- Open Local Security Policy (secpol.msc).
- Go to Local Policies → User Rights Assignment.
- Open Lock pages in memory.
- Remove the account running the SQL Server Database Engine service.
- If the right is controlled through domain Group Policy, have the domain administrator remove that account from the corresponding policy.
- Restart Windows, then check whether a new SQLDump*.txt is generated.

LPIM is active when the account running sqlservr.exe has that Windows user right. Removing the right disables locked pages for SQL Server.^2^

Disabling LPIM can affect memory paging under pressure, but it is the published workaround for this specific Windows Server 2025 condition.

If the locked-pages message is absent

The displayed c0000005 EXCEPTION_ACCESS_VIOLATION confirms an invalid memory access, but the excerpt alone does not identify which SQL Server component or request caused it.

Your build 17.0.5015.4 is the CU9+GDR servicing branch.^3^ The next available update is SQL Server 2025 CU10, build 17.0.5035.5; install it in a test environment first and then apply it using your normal change process.^4^

Be aware that CU10 documents a separate access violation if monitoring queries access sys.dm_exec_requests while a database is recovering during startup. If the dump’s Input Buffer names a monitoring procedure that queries this DMV, use the documented CU10 mitigations:

Avoid querying sys.dm_exec_requests until startup recovery completes; or
Enable trace flag 4696, accepting that monitoring secondary replicas can then return errors 976 or 978.^4^

Do not apply that trace flag to CU9 merely because the exception code matches; the documented condition is specific to CU10 and database recovery.

Identify the triggering component

Review the dump and ERRORLOG entries immediately before BEGIN STACK DUMP, especially:

Input Buffer or the executing stored procedure.
Exception Address and module name.
Database recovery messages.
SESSION_CONTEXT usage in parallel queries. SQL Server 2025 documents AV dumps under that condition and recommends avoiding parallel execution for those calls.^1^
In-process third-party providers, CLR modules, extended stored procedures, or monitoring agents.

Escalation

If the dump continues after the applicable workaround and current servicing update, collect:

Complete current and archived ERRORLOG files.
SQLDump*.txt, .mdmp, and .log files from the LOG directory.
Windows Application and System event logs.
The query, Agent job, or monitoring process active at startup.
SQL Server configuration and database recovery state.

Microsoft recommends SQL LogScout’s DumpMemory scenario for collecting automatically generated SQL Server dumps.^5^ Open a Microsoft support request with that package because conclusive stack-dump analysis commonly requires SQL Server symbols and source-level investigation.

References