In messaging systems, after an evident failure to deliver a message, that message goes to a special queue called the dead-letter queue (DLQ). The DLQ is somewhat analogous to a classic dead-letter mailbox at the main Post Office. In the context of this discussion, failure to deliver constitutes not only failure to reach the service-side queue, but also failure to commit the playback transaction. MSMQ on the client and on the service side constantly acknowledge to each other receipt and processing of messages. If the service-side MSMQ successfully receives and retrieves the message from the service-side queue (that is, if the playback transaction committed), it sends a positive acknowledgment (ACK) to the client-side MSMQ. The service-side MSMQ can also send a negative acknowledgment (NACK) to the client. When the client-side MSMQ receives a NACK, it posts the message to the DLQ. If the client-side MSMQ receives neither an ACK nor a NACK, the message is considered in-doubt.

With MSMQ 3.0 (that is, on Windows XP and Windows Server 2003), the dead-letter queue is a system-wide queue. All failed messages from any application go to this single repository. With MSMQ 4.0 (that is, on Windows Vista and Windows Server 2008 or later), you can configure a service-specific DLQ where only messages destined to that specific service go. Application-specific dead-letter queues grossly simplify both the administrator's and the developer's work.

With MSMQ, each message carries a timestamp initialized when the message is first posted to the client-side queue. In addition, every queued WCF message has a timeout, controlled by the TimeToLive property of MsmqBindingBase. After posting a message to the client-side queue, WCF mandates that the message must be delivered and processed within the configured timeout. Note that successful delivery to the service-side queue is not good enough—the call must be processed as well. The TimeToLive property is therefore somewhat analogous to the SendTimeout property of the connected bindings.

The TimeToLive property is relevant only to the posting client; it has no effect on the service side, nor can the service change it. TimeToLive defaults to one day. After continuously trying and failing to deliver (and process) a message for as long as TimeToLive allows, MSMQ stops trying and moves the message to the configured DLQ.

You can configure the time-to-live value either programmatically or administratively. For example, using a config file, here is how to configure a time to live of five minutes:

<bindings>
   <netMsmqBinding>
      <binding name = "ShortTimeout"
         timeToLive = "00:05:00"
      />
   </netMsmqBinding>
</bindings>

The main motivation for configuring a short timeout is when dealing with time-sensitive calls that must be processed in a timely manner. However, time-sensitive queued calls go against the grain of disconnected queued calls in general: the more time-sensitive the calls are, the more questionable the use of queued services is in the first place. The correct way of viewing time to live is as a last-resort heuristic used to eventually bring to the attention of the administrator the fact that the message was not delivered, not as a way to enforce business-level interpretation of the message's sensitivity.

MsmqBindingBase offers the DeadLetterQueue property, of the enum type DeadLetterQueue:

public enum DeadLetterQueue
{
   None,
   System,
   Custom
}

When DeadLetterQueue is set to DeadLetterQueue.None, WCF makes no use of a dead-letter queue. After a failure to deliver, WCF silently discards the message as if the call never happened. DeadLetterQueue.System is the default value of the property. As its name implies, it uses the system-wide DLQ: after a delivery failure, WCF moves the message from the client-side queue to the system-wide DLQ.

When DeadLetterQueue is set to DeadLetterQueue.Custom, the application can take advantage of a dedicated DLQ. DeadLetterQueue.Custom requires the use of MSMQ 4.0, and WCF verifies that at the call time. In addition, WCF requires that the application specify the custom DLQ address in the CustomDeadLetterQueue property of the binding. The default value of CustomDeadLetterQueue is null, but when DeadLetterQueue.Custom is employed, CustomDeadLetterQueue cannot be null:

<netMsmqBinding>
   <binding name = "CustomDLQ"
       deadLetterQueue = "Custom"
       customDeadLetterQueue = "net.msmq://localhost/private/MyCustomDLQ">
   </binding>
</netMsmqBinding>

Conversely, when the DeadLetterQueue property is set to any other value besides DeadLetterQueue.Custom, then CustomDeadLetterQueue must be null.

It is important to realize that the custom DLQ is just another MSMQ queue. It is up to the client-side developer to also deploy a DLQ service that processes its messages. All WCF does on MSMQ 4.0 is automate the act of moving the message to the DLQ once a failure is detected.

public static class QueuedServiceHelper
{
   public static void VerifyQueue(this ServiceEndpoint endpoint)
   {
if(endpoint.Binding is NetMsmqBinding)
      {
         string queue = GetQueueFromUri(endpoint.Address.Uri);
         if(MessageQueue.Exists(queue) == false)
         {
            MessageQueue.Create(queue,true);
         }
         NetMsmqBinding binding = endpoint.Binding as NetMsmqBinding;
         if(binding.DeadLetterQueue == DeadLetterQueue.Custom)
         {
            Debug.Assert(binding.CustomDeadLetterQueue != null);
            string DLQ = GetQueueFromUri(binding.CustomDeadLetterQueue);
            if(MessageQueue.Exists(DLQ) == false)
            {
               MessageQueue.Create(DLQ,true);
            }
         }
      }
   }
   //More members
}

The client needs to somehow process the accumulated messages in the DLQ. In the case of the system-wide DLQ, the client can provide a mega-service that supports all contracts of all queued endpoints on the system to enable it to process all failed messages. This is clearly an impractical idea, though, because that service could not possibly know about all queued contracts, let alone provide meaningful processing for all applications. The only feasible way to make this solution work would be to restrict the client side to at most a single queued service per system. Alternatively, you can write a custom application for direct administration and manipulation of the system DLQ using System.Messaging. That application will parse and extract the relevant messages and process them. The problem with that approach (besides the inordinate amount of work involved) is that if the messages are protected and encrypted (as they should be), the application will have a hard time dealing with and distinguishing between them. In practical terms, the only possible solution for a general client-side environment is the one offered by MSMQ 4.0: a custom DLQ. When using a custom DLQ, you also provide a client-side service whose queue is the application's custom DLQ. That service will process the failed messages according to the application-specific requirements.

<!-- Client side -->
<system.serviceModel>
   <client>
      <endpoint
         address  = "net.msmq://localhost/private/MyServiceQueue"
         binding  = "netMsmqBinding"
         bindingConfiguration = "MyCustomDLQ"
         contract = "IMyContract"
      />
   </client>
   <bindings>
      <netMsmqBinding>
         <binding name = "MyCustomDLQ"
            deadLetterQueue = "Custom"
            customDeadLetterQueue = "net.msmq://localhost/private/MyCustomDLQ">
         </binding>
      </netMsmqBinding>
   </bindings>
</system.serviceModel>

<!--  DLQ service side -->
<system.serviceModel>
   <services>
      <service name  = "MyDLQService">
         <endpoint
            address  = "net.msmq://localhost/private/MyCustomDLQ"
            binding  = "netMsmqBinding"
            contract = "IMyContract"
         />
      </service>
   </services>
</system.serviceModel>

public sealed class MsmqMessageProperty
{
   public const string Name = "MsmqMessageProperty";
public int AbortCount
   {get;}
   public DeliveryFailure? DeliveryFailure
   {get;}
   public DeliveryStatus? DeliveryStatus
   {get;}
   public int MoveCount
   {get;}
   //More members
}

public sealed class OperationContext : ...
{
   public MessageProperties IncomingMessageProperties
   {get;}
   //More members
}
public sealed class MessageProperties : IDictionary<string,object>,...
{
   public object this[string name]
   {get;set;}
   //More members
}

[ServiceContract(SessionMode = SessionMode.NotAllowed)]
interface IMyContract
{
   [OperationContract(IsOneWay = true)]
   void MyMethod(string someValue);
}
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class MyDLQService : IMyContract
{
   [OperationBehavior(TransactionScopeRequired = true)]
   public void MyMethod(  )
   {
      MsmqMessageProperty msmqProperty = OperationContext.Current.
        IncomingMessageProperties[MsmqMessageProperty.Name] as MsmqMessageProperty;

      Debug.Assert(msmqProperty != null);
      //Process msmqProperty
   }
}

public enum DeliveryStatus
{
   InDoubt,
   NotDelivered
}

public enum DeliveryFailure
{
   AccessDenied,
   NotTransactionalMessage,
   Purged,
   QueueExceedMaximumSize,
   ReachQueueTimeout,
   ReceiveTimeout,
   Unknown
   //More members
}

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class MyDLQService : IMyContract
{
   [OperationBehavior(TransactionScopeRequired = true)]
   public void MyMethod(string someValue)
   {
      MsmqMessageProperty msmqProperty = OperationContext.Current.
        IncomingMessageProperties[MsmqMessageProperty.Name] as MsmqMessageProperty;
      //If tried more than 25 times: discard message
      if(msmqProperty.MoveCount >= 25)
      {
         return;
      }
      //If timed out: try again
      if(msmqProperty.DeliveryStatus == DeliveryStatus.InDoubt)
      {
         if(msmqProperty.DeliveryFailure == DeliveryFailure.ReceiveTimeout)
         {
            MyContractClient proxy = new MyContractClient(  );
            proxy.MyMethod(someValue);
            proxy.Close(  );
         }
         return;
      }
      if(msmqProperty.DeliveryStatus == DeliveryStatus.InDoubt ||
         msmqProperty.DeliveryFailure == DeliveryFailure.Unknown)
      {
         NotifyAdmin(  );
      }
   }
   void NotifyAdmin(  )
   {...}
}