SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Error 25602 When Creating an Extended Events Session: a Security Risk

 Error 25602 When Creating an Extended Events Session: a Security Risk

I came across an interesting issue recently when helping someone troubleshoot error 25602 that he was receiving when starting an Extended Events session. I found the cause of the error to be quite alarming. To make matters worse, the way some people are working around the problem is even more troubling. In short, if you output the session to a file, but you only provide a filename with no path for the parameter, SQL Server defaults to writing the output to a protected Windows system directory!!


Code to Reproduce the Error:



      ADD EVENT [sqlserver].[deprecation_final_support]

      ADD TARGET [package0].[asynchronous_file_target] (

            SET filename = 'testfile.log'





      STATE = start






The Error:


Msg 25602, Level 17, State 21, Line 1

The target, "CE79811F-1A80-40E1-8F5D-7445A3F375E7.package0.asynchronous_file_target", encountered a configuration error during initialization.  Object cannot be added to the event session.


Why is this Bad?


If you do not specify a path, SQL Server defaults the path to C:\Windows\System32. If the SQL Server service account is a privileged account (such as Local System or a local admin), it will use this path and output the data here. This opens up the possibility of accidentally overwriting system files. The error above is generated when the SQL Server service account does not have permissions to write to this folder. Users are working around this problem by elevating the permissions of the SQL Server service account.


Simply elevating the service account’s permissions is a bad practice. You should instead choose a location that SQL Server already has write permissions such as the SQL Log directory or the directory used by the default trace. Another good option might be the backup drive. If you want an alternate location, simply make sure you provide the path in the XE session definition and make sure the SQL Server service account has read/write permissions to that folder.


Best Practices for Outputting an XE Session to a File


1.       When outputting to a file, always provide the full path to the file.

2.       Follow the rule of least privileges. Make sure the SQL Server service account has read/write permissions to the directory for the output. Do not elevate permissions or provide more permissions than are required.


Please Vote


I filed a bug for this on connect.microsoft.com, as I see this as a high priority security risk. Please vote for this bug so that the SQL Team will know that we see this bug as a high priority.


Bug #: 569986

Bug Title: Extended Events output to file defaults to C:\Windows\System32

Bug Link: https://connect.microsoft.com/SQLServer/feedback/details/569986#details



Posted by mikewa on 28 June 2010

Hi Robert,

The default path of the System32 directory does not create the possibility of overwritting system files. Extended Events will not overwrite any file, regardless of of the file path.

We do plan on changing the default path for file creation to the Log folder in the next major version of SQL Server since that folder is generally accessible to the SQL service account without any changes. Even after that change it will still be a best practice to always specify the full path for the output file.

This information is documented in the Connect item you filed.


Mike Wachal

SQL Server

Posted by Robert L Davis on 29 June 2010

Thanks for the update Mike!! I see your point about not being able to overwrite system files.

Hopefully if people read this, they will add the full path rather than elevating SQL permissions.

Leave a Comment

Please register or log in to leave a comment.