Behavior of case sensitivity of RAISERROR when run remotely

Question

I have a remote SQL Server that I can connect to using a local instance of SSMS.

When raising errors, we use

RAISERROR( 'This works', 16, -1 )

Remotely, this works fine if it's all uppercase, or even if any one letter is uppercase.

raiserRor( 'Still works', 16, -1 )

If I try to run it using all lowercase though, it does not work

raiserror( 'Error', 16, -1 )

It returns the error message

Msg 121, Level 20, State 0, Line 3
A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)

Even if I comment out the lowercase raiserror statement it still fails with the same error message.

If I log on to the server and execute these statements, they all work. It only seems to be when I connect remotely that this is an issue.

Why can't RAISERROR be completely lowercase? Even if commented?

---

The server is an install of SQL Server 2012 Developer edition on Windows Server 2012.

Microsoft SQL Server 2012 - 11.0.5058.0 (X64)
May 14 2014 18:34:29
Copyright (c) Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.2 (Build 9200: ) (Hypervisor)

I've used local installs of SQL Server Management Studio 2012 and 2014 and tested against databases with 2005 and 2012 compatibility levels and the same behavior occurs.

I tested on other machines and the same results occurred. I don't currently have a machine to test outside of our companies network though.

Answer 1

This issue may actually be related to a very old bug with SQL Server, but not directly caused by SQL Server itself.

I found this MSDN thread which describes the exact same behavior

Please note the strangeness of this: RAISERROR won't compile (connection time out), even if it is in a comment!

This was the accepted answer

It turns out that the network that our SQL Server is on has an intrusion prevention system. In that system there is a filter with the following description:

This filter detects access to the raiserror procedure on port 1433. The raiserror procedure in a Microsoft SQL Server contains a buffer overflow vulnerability, which can be remotely exploited to execute arbitrary computer code on the affected system, thus allowing an attacker to gain complete control of the server. The procedures known to be vulnerable are: xp_sprintf, raiseerror() and formatmessage(). If the overruns are exploited, the code runs in the context of a local administrator account.

There is an old MS Security Bulletin for this bug and a more recent TechNet thread describing the same issue.

It's possible there is something on our network that I am not aware of that is filtering out anything with the text raiserror in it (but doing a poor job of it since the check is case sensitive). Not that it matters since the bug was fixed.

Since this isn't recognized behavior of SQL Server then it could likely be a network configuration issue.