我有一个稍微复杂的设置，当然，在XP中工作正常，但在Windows 7上窒息。这可能看起来很疯狂，但当时有意义！
我有一个WPF应用程序启动，然后启动另一个与外部设备通信的应用程序。启动后，它通过命名管道（net.pipe）使用WCF（由新进程托管）建立与新进程的通信。这似乎适用于任何一种操作系统。
我想让WPF应用程序的一些功能在外部可用于命令行程序，因此我设置了另一个WCF服务，这次由WPF应用程序托管并再次通过命名管道公开它。再次，这似乎工作。
接下来，我想通过网络提供WPF应用程序的功能。现在，重要的是WPF应用程序可以从常规用户帐户运行，所以我认为在Windows 7上运行此工作的最佳方法是创建一个Windows服务，该服务将提供Web服务部分并让它与WPF应用程序通过相同的命名管道，适用于命令行。我实现了它，它在XP上运行良好，但它在Windows 7上窒息。问题似乎试图在Windows服务和WPF应用程序之间建立命名管道连接。
如果我以管理员身份运行WPF应用程序，它可以正常工作。因此，运行Windows服务的帐户似乎无法与通过命名管道托管WCF服务的常规用户帐户进行通信。有没有办法让这项工作？似乎在常规用户帐户中运行的WCF服务可以使用命名管道与在同一帐户中运行的另一个应用程序进行通信，但似乎它不能对不同的帐户执行相同的操作。
奇怪的是，反过来似乎有效。事实上，Windows服务还公开了一个带有命名管道绑定的服务（它被用作激活函数，因为服务一直在运行）。我可以毫无问题地从WPF应用程序连接到此服务。
我对安全的了解有限。任何人都可以了解正在发生的事情吗？
答案 0 :(得分：3)
以前曾多次询问过这个问题。例如，请参阅Connecting via named pipe from windows service to desktop app
问题是您的用户会话应用程序不具备必要的SeCreateGlobalPrivilege安全权限，以允许它们在其他会话可见的全局内核命名空间中创建对象，但仅限于仅在会话中可见的本地命名空间中。另一方面，默认情况下使用此权限运行的服务可以这样做。
不是以这种方式约束到本地命名空间的命名管道对象本身，而是另一个命名的内核对象，一个共享内存部分，WCF命名管道绑定依赖于该对象，以便向其客户端发布实际管道的名称，它是每次启动服务时更改的GUID。
您可以通过反转角色来绕过此约束 - 使Windows服务应用程序成为您的用户会话应用程序所连接的WCF服务。 Windows服务将其服务发布到您的会话没有问题。以这种方式连接起来更有意义，因为Windows服务始终在运行，而您的会话及其应用程序在您登录和退出时来来去去。您需要使用双工合同定义服务，以便在建立连接后，通过WCF服务的基本通信流仍然可以按照您最初预期的方向发生。
答案 1 :(得分：2)
应用程序（WPF / Console）正在创建本地范围的命名管道（默认情况下，当它们无法创建全局范围的管道时）。我的猜测是，他们可以互相沟通，因为他们可以看到彼此命名管道，因为他们在同一个帐户下运行。
Windows服务具有更高的权限，因此可以创建一个全局范围的命名管道供客户端应用程序查看。
您可以查看有关Christian Weyer's Blog的讨论。