Chris SerenoCase of the Named Pipes
Problem
I have come to expect vague error messages that seemingly blame the network. This one is no different.
Server Error in ‘/’ Application.
The network path was not found
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.ComponentModel.Win32Exception: The network path was not found
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
(The stack trace is long and doesn’t actually provide root cause either, so I omitted it to keep this post brief.)
In this case, a web server was providing the error above after receiving a user request and attempting to connect to a backend database. Unless there are other dependencies, the problem is between the web server and database. Both ping tests and telnet tests to the database and port were successful. Nothing was in network logs or monitoring tools showing problems with the devices in the path. Moreover, another server in the same subnet with the same configuration was working fine. [Now is when I come to my confession. The small tests up to this point were done for the sake of doing something and providing evidence if required. In my mind, I had already jumped to conclusions, made assumptions, and ruled out the network as a cause.] This rules out the database and network. Microsoft Network Monitor was already on the Windows web server, so cue a quick packet capture to see what is actually being attempted, provide the data to the right person, and move on to the next thing.
Packet Capture
[
]2
There are two things any packet guru should notice immediately.
- There are no responses to the initial SYN packets meaning there is no return traffic from the database.
- There are 2 different TCP ports being used.
Someone with knowledge of TCP ports or protocols will also notice that neither of these ports are 1433 which is used for SQL. Port 445 is used for SMB (file sharing) and port 139 is for NetBios. So why is the web server attempting to use these instead of port 1433? That is a good question and one that Google can answer. The very first link has this statement a couple of paragraphs down. I’ve seen this before, so I knew what I was looking for in this example.
“This error usually means that the SQL Server computer can’t be found or that the TCP port number is either not known, or is not the correct port number, or is blocked by a firewall.” – Source
Obviously, we aren’t using the correct port numbers so the firewall is blocking the random ports. This data was sent to the application owner with a request to see the connection string. It looked something like this:
That might look correct at first glance, but there is one important detail omitted: the port number. The connection string was corrected to the following:
Resolution
The first connection string was using “named pipes” which relies on SMB. The old NetBios version used port 139. Named pipes are useful for local connections, but not necessarily across a network. I believe standard practice in this area is to use direct connections. As soon as the port was added to the connection string, service was restored.
Further Reading:
https://support.microsoft.com/en-us/help/204279/direct-hosting-of-smb-over-tcp-ip