Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
    
Can the affected users connect to ordinary file shares on the server in question? –  Harry Johnston Aug 17 '12 at 2:20
    
There are no problems with shares currently. This is not a server/client problem. Both processes are on the same computer. –  user152700 Aug 17 '12 at 7:09
    
When you reproduce the problem, logged into an affected computer as Administrator, with READPIPE and MAKEPIPE, what are the exact commands you're using? (Please edit your post to include them rather than putting them in a comment.) –  Harry Johnston Aug 18 '12 at 3:32
    
Thanks for your support. This was a hard one and I will document the solution here. –  user152700 Aug 24 '12 at 9:03

1 Answer 1

up vote 3 down vote accepted

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.

share|improve this answer
1  
Cause 1) The pipes firewall only affects remote access to named pipes. Note, however, that connecting to a named pipe using \\machinename\pipename probably counts as remote access even if machinename is the local machine. –  Harry Johnston Aug 24 '12 at 9:22
1  
Cause 2) Similarly, file and printer sharing is only required for remote access to named pipes. Again, \\machinename\pipename probably counts as remote access for this purpose. –  Harry Johnston Aug 24 '12 at 9:23
    
Cause 3) Windows Firewall shouldn't be able to block local connections, even if using \\machinename\pipename. However, if you're in a domain and Windows Firewall is badly misconfigured, you might have been experiencing more widespread problems, perhaps related to authentication. –  Harry Johnston Aug 24 '12 at 9:27
    
@HarryJohnston What type of authentication could it be blocked? Like ServiceHost.Authentication as described here ? –  Souvlaki Jan 11 '13 at 8:11
    
If you're in a domain, and your network access to the domain controllers is blocked by Windows Firewall (or for some other reason) you may not be able to authenticate. That shouldn't really affect local pipe access, but YMMV. –  Harry Johnston Jan 12 '13 at 10:49

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.