Skip Navigation LinksAzure Developers Guide > Azure Service Bus > Brokered Messaging > Brokered Messaging Features & Patterns > Deadlettering > Receiving and Processing Deadlettered Messages

Training Courses

All course material is in English, and courses are delivered in English. Feel free to contact me for further information.

Receiving and Processing Deadlettered Messages

Messages that are deadlettered will remain on the deadletter sub queue. As queues and topics in the Service Bus have a maximum size it is critical that and deadlettered messages are removed and processed. Failure to do so will result in queues and topics refusing to accept new messages when that size threshold is reached. The same techniques used for receiving messages form queues and subscriptions can be used for receiving messages from deadletter sub-queues.

When receiving messages from a deadletter sub-queue the DeliveryCount property of the message will not be incremented. When received using the default peek-lock receive mode messages can be completed, abandoned or deferred, but not deadlettered. Attempting to call the Deadletter method on a message received from the deadletter queue will result in an exception.

The following code shows a simple message receive loop that will receive messages from the OrderStatQueue deadletter sub-queue and display diagnostic information including the reason and error message for deadlettering the message.


string deadLetterQueuePath = QueueClient.FormatDeadLetterPath("OrderStatQueue");


QueueClient deadletterQueueClient = factory.CreateQueueClient(deadLetterQueuePath);


while (true)


    BrokeredMessage msg = deadletterQueueClient.Receive();


    if (msg != null)


        Console.WriteLine("Deadlettered message.");


        Console.WriteLine("MessageId:                  {0}", msg.MessageId);

        Console.WriteLine("DeliveryCount:              {0}", msg.DeliveryCount);

        Console.WriteLine("EnqueuedTimeUtc:            {0}", msg.EnqueuedTimeUtc);

        Console.WriteLine("Size:                       {0} bytes", msg.Size);

        Console.WriteLine("DeadLetterReason:           {0}",


        Console.WriteLine("DeadLetterErrorDescription: {0}",








When the application is tested with a poison message, and a message with an invalid region the output from the deadletter processing console is as follows:


Receiving Deadlettered Messages from Subscriptions

Whilst using a queue client combined with the static FormatDeadLetterPath method to receive messages from the deadletter sub-queue of a queue, the same technique will not work with subscriptions. If a topic named OrderTopic contains a subscription named UKSubscription the following code can be used to get the path for the deadletter sub-queue of the subscription.


SubscriptionClient.FormatDeadLetterPath("OrderTopic", "UKSubscription");



The following value will be returned.





Creating a SubscriptionClient to receive messages from this sub-queue can be done in two ways.


// Create a Message Receiver

string deadletterPath =

    SubscriptionClient.FormatDeadLetterPath("OrderTopic", "UKSubscription");

MessageReceiver deadletterReceiver = Factory.CreateMessageReceiver(deadletterPath);


// Create a SubscriptionClient

SubscriptionClient deadletterSubscriptionClient = Factory.CreateSubscriptionClient

    ("OrderTopic", "UKSubscription/$DeadLetterQueue");




It is possible to use the value returned by SubscriptionClient.FormatDeadLetterPath to create a MessageReceiver, but not a SubscriptionClient.

Monitoring Deadlettered Messages

The SizeInBytes and MessageCount properties of queues, topics and subscriptions will include any deadlettered messages that are present on the deadletter sub-queues of queues and subscriptions. There is, however, no way to tell how many deadlettered messages there are, or the size consumed by these messages.


Speaking Engagements