The purpose of the final 'no_output' parameter value is to tell SQL Server to not send raiserror or print status messages to registered listeners (e.g., to the SSMS Messages output window or to the SqlConnection.InfoMessage event). It has nothing to do with the @path output parameter.

For example, if the NumErrorLogs value doesn't exist in the registry, then the following code to read its value will produce an output message:

declare @NumErrorLogs int;
exec xp_instance_regread
  N'HKEY_LOCAL_MACHINE',
  N'Software\Microsoft\MSSQLServer\MSSQLServer',
  N'NumErrorLogs',
  @NumErrorLogs output

That will print this low severity output (e.g., in the Messages tab in SSMS):

RegQueryValueEx() returned error 2, 'The system cannot find the file specified.'
Msg 22001, Level 1, State 1

However, if we add the magic 'no_output' literal value as the last parameter, then the behavior is different.

declare @NumErrorLogs int;
exec xp_instance_regread
  N'HKEY_LOCAL_MACHINE',
  N'Software\Microsoft\MSSQLServer\MSSQLServer',
  N'NumErrorLogs',
  @NumErrorLogs output,
  'no_output'

When using 'no_output' as the last parameter, then no output status message is sent to any listener.

You can use exec xp_instance_regdeletevalue N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'NumErrorLogs' to delete the value and try this yourself. Or you can use SSMS > SqlInstance > Management > right-click SQL Server Logs > Configure, uncheck the box for "Limit the number of error log files before they are recycled", then click OK.

FWIW, I stumbled across this question and a related thread while searching for how to suppress the RegQueryValueEx message I was seeing in my Messages output.

Regarding the parameter name and ordering, the xp_instance_regread extended stored procedure is undocumented , and its parameters are positionally bound. You can name the last parameter anything you want (e.g., @x or @no_output ), and it will still work. The parameter binding mechanism for extended stored procedures is different from normal Transact-SQL stored procedures. An extended stored procedure essentially just wraps a call into a function exported from a DLL. For more information, see here and here .