What are reasons for local Windows named-pipes to fail?

Question

I've been working hard on this one all day and I'm stuck. This morning our asian collegues called me because a SolidWorks addin for our product data management system could not communicate with the local main application. The problem affects end user computers in a Windows domain. We used the READPIPE and MAKEPIPE utils from SQL server toolbox to figure out that the underlying problem was the Windows pipe feature.

• The MAKEPIPE util creates a pipe and is waiting for a client. The READPIPE util returns: "Failed to Open Pipe. Status 53." According to http://support.microsoft.com/kb/110905 it means that the network name was not found. On my local computer the pipes sents a "hello" from READPIPE to MAKEPIPE without problems.
• The server process which enables named-pipes is running.
• The settings under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanserver\Parameters look okay. No pipes firewall setting.
• The problem affects some users but not all. We did not make changes to the domain groups except for some network share groups.
• I logged on as administrator and still the pipes won't work.

Any help is appreciated! Thank you.

Answer 1

Needed 1,5 days to figure it out for every case. Here for documentation.

Symptoms

• Drag&Drop into applications does not work.
• Interprocess communication e.g. between main app and addins does not work.

Causes / background

Interprocess communication is implemented for some apps via Windows named pipes (not to be confused with UNIX style pipes). See MSDN documentation: http://msdn.microsoft.com/en-us/library/aa365590.aspx

There may be different causes for the Windows name pipes not to work. To verify that the pipes are the cause of the issue the tools MAKEPIPE and READPIPE can be used. This KB article describes the testing procedure: http://support.microsoft.com/kb/68941 The Sysinternals tool process explorer might also be useful to look up which pipes are currently opened. Use the "Find -> Find Handle or DLL..." option and enter the pattern "\Device\NamedPipe\". It will show you which processes have which pipes open. http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Troubleshoot

Cause 1: Application is blocked by Pipes firewall

Windows can block applications from using named pipes. This firewall is normally not enabled and is configured via the registry. See the MS support article here: http://support.microsoft.com/kb/925890 . Check that the pipes firewall is not enabled or add Keytech and all addins to the list of allowed applications.

Cause 2: File and Printer sharing service is not enabled.

Named pipes are enabled by the process that also controls file and printer sharing. Check that this process is running using the Windows Services tool. The service name is shown as “Server” in the services list. The service name is LanmanServer and the EXE is C:\Windows\system32\svchost.exe -k netsvcs

Cause 3: Windows firewall is blocking LanmanServer

The windows firewall can block named pipes even when they are only used for inter-process communication on the same machine. Especially domain and local firewall rules can cause a conflict. Two entries in the “Windows Firewall Allowed Programs” list indicate a conflict. In most cases this issue can be solved by using the “Check firewall status” window. If this window shows an option for setting recommended firewall rules the pipes can often be unblocked using this option. In combination with domain firewall rules it is sometimes necessary to unjoin the PC first from the domain and then allow the file and printer sharing service.