Recently worked on an issue where sqlbrowser was getting bunch of errors:
07/31/2009 12:20:58 PM SQLBrowser Error None 14 N/A NTMTVSQL24 The SQLBrowser processing of requests against a particular IP address has encountered a critical error. Processing of requests on this address has been halted.
07/31/2009 12:20:58 PM SQLBrowser Error None 8 N/A NTMTVSQL24 The SQLBrowser service was unable to process a client request.
in their Application event log from SQL Browser.
Once these messages were thrown, No applications could connect to SQL Server after this error.
When the issue happened, the only way to resolve it is by restarting the browser service.
- We tried to collect dumps using SQLDumper and ADPLUS crash but could not do that. The reason for that was that the SSRP thread inside browser was not aborting with any exception. Had there been an exception, we should have got a dump.
- Direct action plan was to apply Service Pack 2 on OS since they were on Windows Server 2003 Service Pack 1.
- But we found that after the storage team rolled back the upgrade of the TSM client to the previous version (188.8.131.52), SQL Browser did not report any errors in the event log.
It is suspected that upgrade of the TSM client to version 184.108.40.206 that caused the problem however we could not test it in development environment for confirmation.
This is unverified from a proper reproduction test. Please test it in your development environment.
What you can do if you face similar issue:
> Start SQLBrowser from command prompt with verbose mode "SQLBrowser.exe -c" and check if you get any more detailed messages when the issue occurs
> Collect BIDTrace since browser everywhere has provisions to throwing more messages in the BIDTrace (follow http://msdn2.microsoft.com/en-us/library/aa964124.aspx)
> Confirm that you are on latest OS and SQL Service Packs
> Check if they have any Side by Side installation of SQL Server 2000 with SQL 2005/2008. If yes, follow http://support.microsoft.com/default.aspx?scid=kb;EN-US;922131
> Confirm from "netstat -aon" that SQLBrowser was the one holding 0.0.0.0:1434 UDP port when the error messages are thrown.
> Check if you can make SQL Server work on 1433 as a temporary workaround (since server running on 1433 will not require UDP broadcast)
> Test uninstalling (not just disabling) third party softwares from the box for. ex. the one mentioned above.