Click here to Skip to main content
15,884,986 members
Please Sign up or sign in to vote.
5.00/5 (3 votes)
See more:
Environment: a SQLServer 2005 server; Windows 7 workstations.
Process:
One workstation is running an application that opens a named pipe; upon receiving a connection request, it sends a SQL UPDATE command to the SQL server. Communication on the named pipe is one-way -- once the connection is made, that triggers the SQL UPDATE action; the named pipe connection is closed and the program awaits another connection.

My Problem:
The application opening the "named pipe" is started each morning via a BAT file which executes a RUNAS command specifying a user of <domain>/sqluser. This works perfectly.

However, the BAT file itself is kicked off under a user account, so if that account were to log off, the task would go away. So, I thought I would convert the app to a Service where it could be initiated at workstation startup, outside any specific user session. It would always be available so long as the workstation is up.

Modifying it to be a service went well, and the app installs cleanly, starts/stops cleanly. However, it reaches the point of listening for a named pipe request, but never hears it. I've tried several other user accounts, but nothing works.

Does anyone know what would cause a Service running named pipes to not listen, when the nearly-identical standalone app listens fine, using the same credentials?
Posted
Comments
[no name] 15-Jul-11 9:45am    
Sorry -- should have accepted one of these answers a long time ago! Turned out to be a firewall issue, which I never would have found on my own. Another CodeProject post pointed me to look into it, and, voila!

They perfectly work for a Windows Service. I recently completed such job for the purpose of making a bridge to a legacy application. Some problem is Windows 7 due to a need to elevated privileges. Better forget those batch files. Work with System.IO.Pipes.

—SA
 
Share this answer
 
This is by design. Named pipe endpoints created by non-Admin users on Windows 7 can only communicate with processes running as the same user. Perhaps a potential fix would be to run the Windows service as sqluser.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900