Describe the bug
sp_Blitz can abort partway through with:
Msg 568, Level 16, State 23, Procedure dbo.sp_Blitz, Line 9729
Encountered an error or an unexpected end of trace file '/var/opt/mssql/log/log.trc'.
The procedure stops there and returns nothing further. It is intermittent — the same server, same parameters, minutes apart, will succeed.
Root cause
CheckID 106 ("Default Trace Contents") reads the default trace with fn_trace_gettable. The default trace is a live, rolling file the engine is actively writing. Reading it while the engine is mid-write — or while it rolls over to a new file — raises Msg 568, and because nothing catches it, the error kills the whole sp_Blitz run rather than just that check.
The exposure scales with how busy the server is: the more DDL and configuration activity, the more the trace churns, the likelier a read lands on a torn file.
Steps to reproduce
Not reliably reproducible on demand — it is a race. It shows up on servers doing steady DDL. In the CI matrix from #4047 it appeared on 1 of roughly 6 sp_Blitz invocations in a run, on SQL Server 2017 Linux, while the SQL Server 2025 job in the same run was unaffected.
Expected behavior
A transient failure to read the default trace should skip CheckID 106, not abort sp_Blitz. Users lose every finding after that point, including higher-priority ones, because of an optional informational check.
Suggested fix
Wrap the CheckID 106 read in BEGIN TRY ... BEGIN CATCH, and on failure either skip the check or emit a finding saying the trace could not be read. Other checks that read the default trace (@base_tracefilename consumers) likely deserve the same treatment.
Impact
Low frequency, high blast radius when it fires: sp_Blitz returns partial results with an error rather than a health check, and the checks it drops are the ones after CheckID 106.
Note for #4047
That PR's CI skips CheckID 106 so this race does not produce red builds on unrelated pull requests, with a comment pointing here. That skip should come out once this is fixed.
Describe the bug
sp_Blitzcan abort partway through with:The procedure stops there and returns nothing further. It is intermittent — the same server, same parameters, minutes apart, will succeed.
Root cause
CheckID 106 ("Default Trace Contents") reads the default trace with
fn_trace_gettable. The default trace is a live, rolling file the engine is actively writing. Reading it while the engine is mid-write — or while it rolls over to a new file — raises Msg 568, and because nothing catches it, the error kills the wholesp_Blitzrun rather than just that check.The exposure scales with how busy the server is: the more DDL and configuration activity, the more the trace churns, the likelier a read lands on a torn file.
Steps to reproduce
Not reliably reproducible on demand — it is a race. It shows up on servers doing steady DDL. In the CI matrix from #4047 it appeared on 1 of roughly 6
sp_Blitzinvocations in a run, on SQL Server 2017 Linux, while the SQL Server 2025 job in the same run was unaffected.Expected behavior
A transient failure to read the default trace should skip CheckID 106, not abort
sp_Blitz. Users lose every finding after that point, including higher-priority ones, because of an optional informational check.Suggested fix
Wrap the CheckID 106 read in
BEGIN TRY ... BEGIN CATCH, and on failure either skip the check or emit a finding saying the trace could not be read. Other checks that read the default trace (@base_tracefilenameconsumers) likely deserve the same treatment.Impact
Low frequency, high blast radius when it fires:
sp_Blitzreturns partial results with an error rather than a health check, and the checks it drops are the ones after CheckID 106.Note for #4047
That PR's CI skips CheckID 106 so this race does not produce red builds on unrelated pull requests, with a comment pointing here. That skip should come out once this is fixed.