Turns out this is a debug channel event. If information is sparse about Extended Events in general, the debug channel can be a real wasteland.

The description given in the XE session GUI in SSMS says:

Occurs when SQLExit() routine is invoked

Too bad we have know way of really knowing what SQLExit() is or what it does. However, from the name it certainly seems to be related to shutting down SQL Server. And in fact, if we look at the event fields, there are only two:

exit_code

shutdown_option

There’s a nice empty description box next to each of them. Whatevs.

“Exit Code” is a pretty standard programming trope, where “0” is good, and anything else is some kind of error.

Querying sys.dm_xe_map_values shows there are four values available for the “shutdown_option” field. So my mission was to see how to get each of those four values.

Shut It Down

(Did anyone get that 30 Rock reference? No? Okay)

First of all, I’ll set up an XE session as similar as possible to the one in the system_health session, but with just the sql_exit_invoked event:

There is a 4th option for this field (called “SHUTDOWN_NOT_SET”). I heard from some guy at Microsoft that this is probably just some kind of initial value, and that you wouldn’t see it logged in practice.

How This Helps

While knowing what these shutdown_options mean won’t solve all your problems (I mean, your SQL Server instance is restarting), now you can at least have a direction to look in.

Seeing ORDERLY_SHUTDOWN? Investigate the Windows Event Logs to see who is restarting the server, or what services are sending a net stop command to the SQL Server service

Seeing NICE_SHUTDOWN or FAST_SHUTDOWN? Good news: in the default XE, the hostname, app name, and session username are all logged

Go track down that user or app and ask them “why are you doing this crazy thing?”

Here’s a screenshot from my test where you can see that “jdarnell” (hey, that’s me) is the culprit, and he used SSMS to do it:

It can also be helpful to know the limitations of the tools you’re using. Now I know that the sql_exit_invoked event won’t pick up situations where someone forcefully killed the SQL Server process, or hard-rebooted the machine it’s running on.