Difference between Path name and Format name when accessing MSMQ queues

For beginners to MSMQ development, the fact that there are FIVE ways of addressing an MSMQ queue is a real pitfall. Many hours will be lost trying to work out why a seemingly perfect address keeps returning errors.

From MSDN: 

Referencing a Queue

To perform an operation on a queue, an application must reference the queue in one of five ways, depending on the operation that the application is performing:

  • By path nameused to create the queue, to open the queue for sending, peeking at, and receiving messages, to reset the properties and security descriptor of the queue, and to delete the queue.

  • By format name—used to open the queue for sending, peeking at, and receiving messages, to reset the properties and security descriptor of the queue, and to delete the queue.

  • By queue handle—used to send messages to the queue, read from the queue, and create cursors for navigating through the queue (a queue handle can also be used to create a format name for the queue that can then be passed on to other processes).

  • By queue alias—used to include queues that are not listed in Active Directory Domain Services (AD DS), such as a private queue or a URL-named queue, in a distribution list.

  • By ADs path—used to reference queues when creating or maintaining a distribution list.

Only the first two are frequently used. I’ve highlighted “used to create the queue” for path name as this is a common misunderstanding – you can’t create a queue using a format name.


Path names 

The following require access to Active Directory when accessing remote machines

These have a basic syntax combining the machine name and queue name:

Public queues: ComputerName\QueueName
Private queues: ComputerName\Private$\QueueName

You can use a “.” as a shortcut for accessing local queues on the sending machine:

Public queues: .\QueueName
Private queues: .\Private$\QueueName

If you specify a path using the path name syntax, it is translated into the associated FormatName (by querying Actice Directory) before accessing the queue.


Format names  

Message Queuing uses single- and multiple-element format names to reference queues. Single-element format names include public, private, direct, distribution list, multicast address, machine, and connector format names, each with its own syntax. Multiple-element format names are a string of any number of single-element public, private, direct, and distribution list format names. Multiple-element format names are used only to send messages.

All of the following require access to Active Directory

Public Format Name Syntax

Public format names contain the string “PUBLIC=” followed by the identifier (GUID) of the queue that is generated by Message Queuing when the queue is created. 


Private Format Name Syntax

Private format names contain the string “Private=” followed by the globally unique identifier (GUID) of the computer where the queue is registered and a hexadecimal number that identifies the queue.


Distribution List Format Name Syntax

Distribution list format names contain the string “DL=” followed by the distribution list identifier. The distribution list identifier (GUID) can be found in the objectGUID attribute of the distribution list group object using ADSI Edit. 


Multicast Address Format Name Syntax

The following is the general form of a multicast address format name.


Multiple-Element Format Name Syntax
Multiple-element format names contain any number of single-element format names separated by commas.


Machine format name syntax

Machine format names contain the string “MACHINE=” followed by the identifier of the computer and the keyword that identifies which system queue to open. The following is the general form of the machine format names used to open a computer journal, a nontransactional dead-letter queue, and a transactional dead-letter queue:

MACHINE=ComputerGUID;JOURNAL             *Computer journal.
MACHINE=ComputerGUID;DEADLETTER          *Nontransactional dead-letter queue.
MACHINE=ComputerGUID;DEADXACT            *Transactional dead-letter queue.

No requirement for Active Directory for the following – direct format names are essential for workgroup mode MSMQ but optional for AD-integrated MSMQ

Direct Format Name Syntax

Direct format names specify the location of the queue and the name of the queue.

The following is the general form of direct format names.

DIRECT=AddressSpecification\QueueName (For public queues)
DIRECT=AddressSpecification\PRIVATE$\QueueName (For private queues)
DIRECT=AddressSpecification\QueueName;JOURNAL (For public queue journals)
DIRECT=AddressSpecification\PRIVATE$\QueueName;JOURNAL (For private queue journals)
DIRECT=AddressSpecification\SYSTEM$;computersystemqueue (For computer journal and dead-letter queues.)

The Address Specification

The address specification of the computer can be in one of three forms. I’ve highlighted the portion that is the actual address specification that you need to insert in the direct format name syntax above:

  • Using the IP address of the destination.

    • Example

  • Using the computer name of the destination.

    • Example

  • Using HTTP and referencing the MSMQ virtual directory of the destination web server

    • Examples


When sending messages over HTTP, make sure ALL the slashes in the address are leaning forward.


If you are using the MessageQueue constructor, you will need to add “FormatName:” to the beginning of the Direct Format Name string:

    • FormatName:DIRECT=TCP: IPAddress\QueueName

    • FormatName:DIRECT=OS: MachineName\QueueName

Confused? That’s normal but with a little practice you will get the hang of things.

Comments (31)

  1. arthur wang says:

    I have trouble to connect my clustered MSMQ resource. In my case:

    my cluster virtual name is: awcluster.

    local physical node computer name is: w2k8clusternd1

    my clustered MSMQ name is: awclusterMsmq

    say with a call to GetPrivateWueuesByMachine:

    A. using MSMQ clustered network resource name awclusterMsmq.

    a. it returns "queue service is not available" if the node local MSMQ service is stopped.

    b. it returns "the specified format name does not support the requested operation".

    In both above cases, the clustered MSMQ awclusterMsmq is running fine. I can use MMCV to view it.

    In the meantime, If I use the local node machine name w2k8clusternd1,  GetPrivateWueuesByMachine lists all the queues on the local MSMQ fine.

    I put my COM+ run as a service in the same group as MSMQ awclusterMsmq, same result.

    I am using w2k8, hyper-v, one physical box, two hyper-v nodes.

  2. Hans says:

    To someone who’s dealing with MSMQ for some years now (like me), the different addressing schemes and uses should be 100% clear. Well, speaking from experience, I can say they aren’t always…

    Thanks for the concise and very useful overview!

  3. MSDN Archive says:

    For those following the comments, I worked with Arthur wang off-line on this problem (he’s a co-worker) and we’re currently chasing down some C# oddities.

  4. u want to exact solution that query. When u will used application. what is advatage.

  5. MSDN Archive says:

    Hi Mr Singh,

    I don’t have any documentation to share comparing Microsoft Message Queuing with IBM WebSphere MQ. I have asked some colleagues if there is anything I can share with you. I will keep you updated on this request.


    John Breakwell

  6. Victor says:

    We have similar problem and are interested in the solution for accessing clustered MSMQ

  7. MSDN Archive says:

    Hi Victor,

    Arthur Wang’s problem had a mixture of causes, such as his MSDTC configuration for example.

    It would be best if you described your problem in a bit more detail as it is unlikely to have the same root causes.


    John Breakwell (MSFT)

  8. Victor says:


    MSDTC configuration is also might be the case for us too.

    Our scenario is – a process can send messages from any computer outside of cluster. But when we tried to run it on a node A – it fails with message like "MessageQueue is not available".

    So, could you please give me a hint where to look in MSDTC configuration?

  9. MSDN Archive says:

    Hi Victor,

    No, I think looking at the MSDTC configuration will lead to a dead end. MSDTC is used for sending MSMQ messages within Distributed Transactions. This is not the usual way to send messages.

    "MessageQueue is not available" is almost guaranteed to be down to the local node’s MSMQ service not running. This post will help:



    John Breakwell (MSFT)

  10. Victor says:

    More details:

    1) C# code sends messages to a private queue running on a clustered MSMQ

    2) The private queue on clustered MSMQ is available – it perfectly receives messages from other sources

    3) When we run the same process from another server and send it to the same clustered MSMQ – works perfectly fine. The same true if it sends messages to a local MSMQ.

    Thanks in advance,


  11. Victor says:


    Yes, local MSMQ service on each node is not running.

    Idea in our case is – on each node we have a process that runs only on active node and sends messages to a private queue of the clustered MSMQ. What would be your recommendations how properly setup such process on each node?

  12. MSDN Archive says:

    Hi Victor,

    Why do you want to run an application only on the active node? MSMQ on a local node has no concept of the clustered MSMQ resource running on the same machine. It will always regard the clustered resource as a remote machine.

    To create what you want, you can have a Service running on the local node that can be associated with the resource group. When the resource group moves from one node to the other, it ensures the service is stopped on the old node and started on the new node. Make sure you don’t select the "Use Network Name as Computer Name" option.


    John Breakwell (MSFT)

  13. Victor says:


    We started local MSMQ service on each node and everything is working.

    Thanks a lot.


  14. Hi,

    I’m trying to create a private queue on a remote machine by path name.

    My path name is as follows: "TestGameServer\Private$\Kq".

    I’m getting an exception saying that

    {"Object owner was invalid. For example, MQCreateQueue failed because the Queue Manager object is invalid."}

    MessageQueueErrorCode InvalidOwner

    InvalidOwner error means MessageQueuing is not installed on the machine where I’m tryiing to create the queue but I have it installed.

    Any help would be appreciated.



  15. MSDN Archive says:

    Hi Kaltani,

    Invalid Owner (error 0xC00E0044) is not the same as Service Not Available (0xC00E000B). You may get the error you are seeing when MSMQ is not installed but that doesn’t mean it is the ONLY cause.

    For example, you can get 0xC00E0044 when the system clock on the domain controller is out of synch with that of the client.

    Using path names involves querying Active Directory. Are your machines running in workgroup mode or AD integrated?


    John Breakwell

  16. Hi John,

    Thanks for the reply. My machines are running in workgroup mode.



  17. MSDN Archive says:


    Then you are going to have to create the queue locally on that machine, either manually through the user interface or programatically through some application/service running on it.

    Path names require access to Active Directory to work – except for local operation where it would be unnecessary.

    Format names can’t be used to create queues.


    John Breakwell

  18. John,

    I have also created a private queue locally, tried to send the message to the queue on the remote machine using the direct format name. The message is sitting in the Outgoing queues directory. The remote machine is not showing this message in it’s private queue.

    I’m using the format name like this:




  19. MSDN Archive says:

    Hi Kalyani,

    That’s not the format for a private queue – you need to insert "private$" in the middle.





  20. Hi John,

    When I added the private to format name, it worked. Thank you very much for answering my questions.



  21. MSDN Archive says:

    Hi Kalyani,

    It’s a pleasure to help.


    John Breakwell (MSFT)

  22. Reshma says:


  23. MSDN Archive says:

    Hi Reshma,

    What’s your question?

    I assume it is something to do with queue name length? Maybe this?



    John Breakwell (MSFT)

  24. AKC says:

    I understand the Virtual folder MSMQ is created under IIS when using HTTP and referencing the MSMQ. How is the folder used. Even after I delete the folder, the messaging servive works without any problem. Also there is nothing under this folder. Is this used only when certiricates are used?


  25. MSDN Archive says:

    Hi AKC,

    The MSMQ folder is initially required so that the MSMQ application can be created – you can’t create an application without a folder.

    After that, there is a script mapping that means anything for the MSMQ folder is intercepted by MQISE.DLL. All incoming HTTP traffic should therefore not reach the MSMQ folder.

    I would be surprised, though, if something doesn’t break if you delete the folder. Maybe the permissions on the folder are used, for example. I’ll try some tests on my own machines when I have some time.

    Bottom line is that you won’t have a supported installation. Do you have a need to remove the folder?


    John Breakwell (MSFT)

  26. Phil says:

    How can a translate a "Private Format" name (i.e. GUID) for a MSMQ Host Server into it’s machine name and/or the corresponding "queue"?  I have an application that is calling some of the COM api’s and returning the GUID (Private format names) and I need to reconcile them with the names of the queues…

  27. MSDN Archive says:

    So you are using the "PRIVATE=ComputerGUIDQueueNumber" format.

    There are two method calls that go hand in hand:






    The second method appears to be what you need.


    John Breakwell (MSFT)          

  28. Phil says:

    Great!  Follow-up question: How do I translate the queue id’s returned in the PRIVATE format names into the readable names.  When you instantiate the MSMQApplication, for example, you get two lists, one of private queues which lists the queues by their names, and one of "active" queues which lists them using PRIVATE format names and internal queue IDs.  I haven’t been able to find a way to map the two together or translate the internal queue ID into it’s relative name.  NOTE: looking for a solution that will work in both AD mode and Workgroup mode.

    Thanks in advance!

  29. MSDN Archive says:

    Hi Phil,

    The queue number in the “PRIVATE=ComputerGUIDQueueNumber” format relates to the filename of the queue’s configuration file in the system32msmqstoragelqs directory.

    I’ll see if I can work out how to match queue numbers to names.


    John Breakwell (MSFT)

  30. MSDN Archive says:

    Hi Phil,

    If it were a local private queue, you could pass the PRIVATE= formatname to MQGetQueueProperties and retrieve PROPID_Q_PATHNAME.

    For a remote private queue, you may be able to call MQMgmtGetInfo with QUEUE=PRIVATE={Guid}{Number] and retrieve PROPID_MGMT_QUEUE_PATHNAME but that’s only going to work if the queue is active.

    The problem is that the scenario you’re describing wasn’t considered in the original MSMQ design. As most customers don’t use the "PRIVATE=" format (preferring "PUBLIC=" or "DIRECT="), the functionality hasn’t been reviewed.


    John Breakwell (MSFT)