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.

  • Can the affected users connect to ordinary file shares on the server in question? Aug 17, 2012 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, 2012 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.) Aug 18, 2012 at 3:32
  • Thanks for your support. This was a hard one and I will document the solution here.
    – user152700
    Aug 24, 2012 at 9:03

1 Answer 1


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


  • 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


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.

  • 3
    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. Aug 24, 2012 at 9:22
  • 3
    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. Aug 24, 2012 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. Aug 24, 2012 at 9:27
  • @HarryJohnston What type of authentication could it be blocked? Like ServiceHost.Authentication as described here ? Jan 11, 2013 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. Jan 12, 2013 at 10:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .