locked
Failed to create an IPC Port: Access is denied. RRS feed

  • Question

  • I have a service that registers a remoting IPC channel on startup and quite often I will get this error when the service is stopped and then restarted. It doesn't do it all the time but enough to be an annoyance and when the service is stopped I do unregister the channel. Anyone else experience this?

    Thanks!!

    Tuesday, May 30, 2006 6:20 PM

Answers

  • Hello,

    I have just used FileMon to log pipe activities (during start of Windows Service which is .NET Remoting server), the results below:

     

    MyWindowsSrv:3504 OPEN    \\.\Pipe\   SUCCESS Options: Open  Access: All 
    MyWindowsSrv:3504 CLOSE    \\.\Pipe\   SUCCESS  
    MyWindowsSrv:3504 OPEN    \\.\Pipe\net\NtControlPipe36 SUCCESS Options: Open  Access: All 
    MyWindowsSrv:3504 SET INFORMATION   \\.\Pipe\net\NtControlPipe36 SUCCESS FilePipeInformation 
    MyWindowsSrv:3504 WRITE    \\.\Pipe\net\NtControlPipe36 SUCCESS Offset: 0 Length: 4 
    MyWindowsSrv:3504 READ    \\.\Pipe\net\NtControlPipe36 SUCCESS Offset: 0 Length: 538 
    MyWindowsSrv:3504 WRITE    \\.\Pipe\net\NtControlPipe36 SUCCESS Offset: 0 Length: 8 
    MyWindowsSrv:3504 READ     \\.\Pipe\net\NtControlPipe36 SUCCESS Offset: 0 Length: 538 
    MyWindowsSrv:3504 OPEN    \\.\Pipe\lsarpc   SUCCESS Options: Open  Access: All 
    MyWindowsSrv:3504 SET INFORMATION   \\.\Pipe\lsarpc   SUCCESS FilePipeInformation 
    MyWindowsSrv:3504 WRITE     \\.\Pipe\lsarpc   SUCCESS Offset: 0 Length: 116 
    MyWindowsSrv:3504 READ     \\.\Pipe\lsarpc   SUCCESS Offset: 0 Length: 1024 
    MyWindowsSrv:3504 CLOSE    \\.\Pipe\lsarpc   SUCCESS  
    MyWindowsSrv:3504 IRP_MJ_CREATE_NAMED_PIPE \\.\Pipe\localhost:9093  ACCESS DENIED Attributes: Any Options: Create  
    MyWindowsSrv:3504 OPEN    \\.\Pipe\EVENTLOG  SUCCESS Options: Open  Access: All 
    MyWindowsSrv:3504 SET INFORMATION   \\.\Pipe\EVENTLOG  SUCCESS FilePipeInformation 
    MyWindowsSrv:3504 WRITE     \\.\Pipe\EVENTLOG  SUCCESS Offset: 0 Length: 116 
    MyWindowsSrv:3504 READ     \\.\Pipe\EVENTLOG  SUCCESS Offset: 0 Length: 1024 
    MyWindowsSrv:3504 WRITE    \\.\Pipe\net\NtControlPipe36 SUCCESS Offset: 0 Length: 8 
    MyWindowsSrv:3504 CLOSE    \\.\Pipe\net\NtControlPipe36 SUCCESS  
    MyWindowsSrv:3504 CLOSE    \\.\Pipe\EVENTLOG  SUCCESS  

     

    From this log we can see the following line:

    MyWindowsSrv:3504 IRP_MJ_CREATE_NAMED_PIPE \\.\Pipe\localhost:9093  ACCESS DENIED Attributes: Any Options: Create

     Looks like it is connected with FILE_FLAG_FIRST_PIPE_INSTANCE flag of CreateNamedPipe Windows API function.

    Looks like this should explain the issue, but anyway: what shall I do to fix this issue? I have added 

    exclusiveAddressUse="False"

     in the my config file, now issue isn't reproduced, but I am not sure that this is the best option (Channel and Formatter Configuration Properties says that this attribute may be applied only to the following channels: HttpChannel, HttpServerChannel, TcpChannel, TcpServerChannel).

     

    P. S. OnStop of my service contains the following code:

    protected override void OnStop()

    {

    IChannel channel = ChannelServices.GetChannel(ChannelName);

    ChannelServices.UnregisterChannel(channel);

    }

     

    Monday, June 26, 2006 9:39 AM
  • Hi Scott, you're right that ExclusiveAddressUse can make this work.  We updating the docs on MSDN right now [1] to address the ommision.  When you use this flag, make sure you keep in mind that the pipe can now be shared.  From the (updated) docs:

    When setting the exclusiveAddressUse property to false in the properties argument, several IpcServerChannel objects can be registered for the same named pipe. In such a case requests can go to any of the channels registered. This setting is considered secure only if ACLs are also used.

    Cheers, and thanks for pointing out the problems with the docs.  If you find more errors or ommisions, please post new threads on 'em.

    JJustice [MSFT]

    [1] http://msdn2.microsoft.com/en-us/library/system.runtime.remoting.channels.ipc.ipcserverchannel.aspx

     

     

    Thursday, February 15, 2007 1:29 AM
    Moderator

All replies

  • Where is your service hosted? If it is in IIS, you may want to check the access rights of ASPNET/Network Service a/c
    Wednesday, May 31, 2006 1:06 AM
  • It's actually hosted in a Windows service. Most times I can stop and start the service successfully but then there are other times when it keeps generating the Access Denied message until I either reboot the server or keep restarting the service until it successfully starts.

     

    Wednesday, May 31, 2006 4:05 AM
  • Yeah I have the same enviroment and senerio - secure ipc channel hosted in a windows service and when I restart the service I get "Failed to create an IPC Port: Access is denied."  I figured there was an undocumented timing issue so my service controller just loops and sleeps until my service starts and I coded the services to stop unless the IPC channel came up.

    It seems to only happen when the start quickly follows a stop.  If I give it a few seconds it doesn't seem to happen so often.

    Wednesday, May 31, 2006 7:10 AM
  • I have the same problem too, but only second time i restart the process (?).

    Does anyone know how to get rid of this problem?

     

     

    Tuesday, June 6, 2006 11:56 AM
  • This is how to do it:

     

    System.Collections.IDictionary properties = new System.Collections.Hashtable();
    properties[
    "portName"] = "LiveConnectMediaPlayer";
    properties[
    "exclusiveAddressUse"] = false;
    IpcChannel channel = new IpcChannel(properties, null, null);

    Tuesday, June 6, 2006 1:35 PM
  • I have the intermittent "Access Denied" on my IPC client channel connecting to a Windows Service. I tried using the "exclusiveAddresssUse" property you mentioned but it didn't fix the problem. Also, documentation states that this property only applies to TCP or HTTP channels.

    Anyone else resolve this problem?

    Tuesday, June 6, 2006 6:15 PM
  • Maybe this is not relevant but ensure you have matching

    ChannelServices.RegisterChannel

    and

    ChannelServices.UnregisterChannel

    on startup and closedown respectively.

    Wednesday, June 14, 2006 3:00 PM
  • You can try like this (seems most simple):

    Try

    serverChannel = New IpcServerChannel("myChannelName", "myChannelPort")

    Catch ex As RemotingException

    serverChannel = CType(ChannelServices.GetChannel("myChannelName"), IpcServerChannel)

    End Try

    So, first time you will register channel and second time, if it remained open for some reason you will be able to retrive it.

     

    Tuesday, June 20, 2006 10:55 AM
  • Hi folks, if you're running into this problem, I recommend running Filemon to see what's causing the underlying access denied.  Set up Filemon to show only named pipe activity, then filter by your channel name to see only the channel you care about.  This should let you see exactly where the error's coming from.

    You can get Filemon from www.sysinternals.com.

    Cheers,

    JJustice [MSFT]

    Thursday, June 22, 2006 9:06 PM
    Moderator
  • Hello,

    I have just used FileMon to log pipe activities (during start of Windows Service which is .NET Remoting server), the results below:

     

    MyWindowsSrv:3504 OPEN    \\.\Pipe\   SUCCESS Options: Open  Access: All 
    MyWindowsSrv:3504 CLOSE    \\.\Pipe\   SUCCESS  
    MyWindowsSrv:3504 OPEN    \\.\Pipe\net\NtControlPipe36 SUCCESS Options: Open  Access: All 
    MyWindowsSrv:3504 SET INFORMATION   \\.\Pipe\net\NtControlPipe36 SUCCESS FilePipeInformation 
    MyWindowsSrv:3504 WRITE    \\.\Pipe\net\NtControlPipe36 SUCCESS Offset: 0 Length: 4 
    MyWindowsSrv:3504 READ    \\.\Pipe\net\NtControlPipe36 SUCCESS Offset: 0 Length: 538 
    MyWindowsSrv:3504 WRITE    \\.\Pipe\net\NtControlPipe36 SUCCESS Offset: 0 Length: 8 
    MyWindowsSrv:3504 READ     \\.\Pipe\net\NtControlPipe36 SUCCESS Offset: 0 Length: 538 
    MyWindowsSrv:3504 OPEN    \\.\Pipe\lsarpc   SUCCESS Options: Open  Access: All 
    MyWindowsSrv:3504 SET INFORMATION   \\.\Pipe\lsarpc   SUCCESS FilePipeInformation 
    MyWindowsSrv:3504 WRITE     \\.\Pipe\lsarpc   SUCCESS Offset: 0 Length: 116 
    MyWindowsSrv:3504 READ     \\.\Pipe\lsarpc   SUCCESS Offset: 0 Length: 1024 
    MyWindowsSrv:3504 CLOSE    \\.\Pipe\lsarpc   SUCCESS  
    MyWindowsSrv:3504 IRP_MJ_CREATE_NAMED_PIPE \\.\Pipe\localhost:9093  ACCESS DENIED Attributes: Any Options: Create  
    MyWindowsSrv:3504 OPEN    \\.\Pipe\EVENTLOG  SUCCESS Options: Open  Access: All 
    MyWindowsSrv:3504 SET INFORMATION   \\.\Pipe\EVENTLOG  SUCCESS FilePipeInformation 
    MyWindowsSrv:3504 WRITE     \\.\Pipe\EVENTLOG  SUCCESS Offset: 0 Length: 116 
    MyWindowsSrv:3504 READ     \\.\Pipe\EVENTLOG  SUCCESS Offset: 0 Length: 1024 
    MyWindowsSrv:3504 WRITE    \\.\Pipe\net\NtControlPipe36 SUCCESS Offset: 0 Length: 8 
    MyWindowsSrv:3504 CLOSE    \\.\Pipe\net\NtControlPipe36 SUCCESS  
    MyWindowsSrv:3504 CLOSE    \\.\Pipe\EVENTLOG  SUCCESS  

     

    From this log we can see the following line:

    MyWindowsSrv:3504 IRP_MJ_CREATE_NAMED_PIPE \\.\Pipe\localhost:9093  ACCESS DENIED Attributes: Any Options: Create

     Looks like it is connected with FILE_FLAG_FIRST_PIPE_INSTANCE flag of CreateNamedPipe Windows API function.

    Looks like this should explain the issue, but anyway: what shall I do to fix this issue? I have added 

    exclusiveAddressUse="False"

     in the my config file, now issue isn't reproduced, but I am not sure that this is the best option (Channel and Formatter Configuration Properties says that this attribute may be applied only to the following channels: HttpChannel, HttpServerChannel, TcpChannel, TcpServerChannel).

     

    P. S. OnStop of my service contains the following code:

    protected override void OnStop()

    {

    IChannel channel = ChannelServices.GetChannel(ChannelName);

    ChannelServices.UnregisterChannel(channel);

    }

     

    Monday, June 26, 2006 9:39 AM
  • I have spent time to analize IpcServerChannel code with help of Lutz Roeder's .NET Reflector and I found that parameter exclusiveAddressUse is really used by IpcServerChannel. This parameter corresponds to FILE_FLAG_FIRST_PIPE_INSTANCE flag of CreateNamedPipe function. From MSDN Library about this parameter:

    " ... If you attempt to create multiple instances of a pipe with this flag, creation of the first instance succeeds, but creation of the next instance fails with ERROR_ACCESS_DENIED. ..."

    So, now I think that usage of exclusiveAddressUse (setting it to False) is right solution.

     

    P. S.

    I think this is not so good that documentation in MSDN library refers to exclusiveAddressUse only for TCP and HTTP channels.

     


     

    Monday, June 26, 2006 10:32 PM
  • I am getting this message and I know what is causing it but cannot fix it.

    My server app is a standalone exe and creates an IpcServerChannel.

    My client is an ASP.NET website that runs on the same machine.

    When the client (website) creates the channel and registers it, even if it is unregistered, the asp site is keeping the handle to the Pipe open. So when I shut down the server app and restart, it cannot recreate the pipe.

    My only option to date is to stop and start the web site - in dev mode stop the dev. server.

    Do you see this pattern too? (e.g. After the client has connected once, the pipe is not released?)

    Cheers

    Scott

    Tuesday, June 27, 2006 7:01 AM
  • What exactly Exception (and Message) you received?

    Have you tried to set exclusiveAddressUse to False?

    Tuesday, June 27, 2006 7:44 AM
  • The message is: Failed to create an IPC Port: Access is denied.

    I originally received this for insufficient rights, where I corrected this by using a hashtable and adding a property with the 'users' group to it (unsecure).

    However, after finally determining that the Pipe was not being freed (using Process Explorer by SysInternals), I have put it down to the channel not closing the handle to the Pipe immediately when unregistered with ChannelServices.

    Using the exclusiveAddressUse property has stopped the exception from being raised for now - I'm glad you spelt the property name better than I did. 

    Cheers

    Tuesday, June 27, 2006 10:55 AM
  • Hi Scott, you're right that ExclusiveAddressUse can make this work.  We updating the docs on MSDN right now [1] to address the ommision.  When you use this flag, make sure you keep in mind that the pipe can now be shared.  From the (updated) docs:

    When setting the exclusiveAddressUse property to false in the properties argument, several IpcServerChannel objects can be registered for the same named pipe. In such a case requests can go to any of the channels registered. This setting is considered secure only if ACLs are also used.

    Cheers, and thanks for pointing out the problems with the docs.  If you find more errors or ommisions, please post new threads on 'em.

    JJustice [MSFT]

    [1] http://msdn2.microsoft.com/en-us/library/system.runtime.remoting.channels.ipc.ipcserverchannel.aspx

     

     

    Thursday, February 15, 2007 1:29 AM
    Moderator
  • That's closest to the solution that solved my particular instance of this issue but your solution uses the exception handling mechanism as a flow control mechanism which is a 'worst practice'. Something like this is preferable:

     

     

    if(null == ChannelServices.GetChannel("ipc")) {

       IpcChannel channel = new IpcChannel("YourPetPortName:1");
       ChannelServices.RegisterChannel(channel, false);
    }

    Wednesday, April 23, 2008 7:58 PM
  • I have faced the same problem today. The situation was the following: two or more instances of the same program opened (instantiated) and closed (see the sequence below) some IPC channel (let's call it CH) very fast.

    The expected situation: the first instance opens CH, the rest throw exceptions.
    But what actually happens is that after this situation is repeated 10+ times, CH becomes deadly locked and all processes throw "Failed to Create an IPC Port: Access Denied." exceptions. Which means that the channel was not disposed by some of the processes (but it neither continues to listen, nor a reference to it is present in any process).

    I used the following sequence to close the IPC channel:

    1. Call to IpcServerChannel.StopListening.
    2. Clear IpcServerChannel reference.
    3. Collect garbage.

    Supposingly, the error is in this sequence, but there is no other evident way to dispose an IPC server channel except closing the process (which works correctly but is not suitable).

    Moreover, exclusiveAddressUse is not a way out. It prevents exceptions, but does not solve the situation with incorrectly disposed channels.

    So, the problem remains unsolved.
    Monday, January 11, 2010 4:54 PM