Service Broker Queue: Diagnose a Disabled Receiver

A Service Broker queue with receiving disabled needs a diagnosis before recovery. A stopped receiver does not establish why processing failed. I separate the current flags from the application evidence that explains them.

Read Service Broker queue state in the intended database

Run this read-only script in the application database. It returns the database Broker flag and visible user queues. It does not receive messages or change queue settings. The poison-handling column requires SQL Server 2012 or later.

-- SQL Server 2012 or later. Read-only current-database queue state.
-- No queue reads, RECEIVE, SEND, ALTER, database creation or configuration changes.
SELECT DB_ID() AS DatabaseId, DB_NAME() AS DatabaseName,
 is_broker_enabled AS BrokerEnabled
FROM sys.databases WHERE database_id=DB_ID();
SELECT SCHEMA_NAME(q.schema_id) AS QueueSchema, q.name AS QueueName,
 q.is_receive_enabled AS ReceiveEnabled,
 q.is_enqueue_enabled AS EnqueueEnabled,
 q.is_activation_enabled AS ActivationEnabled,
 q.is_poison_message_handling_enabled AS PoisonHandlingEnabled,
 q.activation_procedure AS ActivationProcedure, q.max_readers AS MaxReaders
FROM sys.service_queues AS q
WHERE q.is_ms_shipped=0
ORDER BY QueueSchema, QueueName;

Catalog visibility depends on ownership and permissions. An empty queue result can mean the wrong database or limited metadata visibility. It does not prove the application has no queues. Confirm the database and expected schema with the application owner.

Keep the flags separate

Receiving and internal activation are different controls. An application can use an external reader without an activation procedure. An activation flag of one does not prove successful processing. Compare the named procedure and configured readers with the actual application design.

Confirm poison-message evidence before naming the cause

Automatic poison-message detection can disable queues after five rollbacks of a transaction that receives messages. The failure is in processing that cannot commit. A poison message need not be corrupt or an invalid request. A previously valid request can become impossible to process.

A zero receive flag also permits other explanations, including a deliberate administrative stop. Keep the error time, processing exception and queue identity together. Look for Broker:Queue Disabled evidence and application rollback records. A disabled flag by itself cannot identify the failing conversation.

Preserve the incident before attempting recovery

Record the receiver, conversation identity and application exception under the team’s access policy. Preserve the relevant message evidence without exposing sensitive payloads in a public report. Reading queue contents deserves a separate decision. A queue SELECT can block concurrent readers.

The diagnostic script deliberately reads catalog flags rather than message bodies. It cannot identify the poison payload or repair application state. Retrying unchanged processing can reproduce the same failure. Confirm the processing fix and conversation protocol before approving recovery.

It is tempting to turn the queue on and call the incident resolved. That only changes a control flag. The useful acceptance check is whether intended work commits under the repaired processing rule. Turning off poison handling also requires a deliberate, dependable retry policy.

Take the incident slowly, and the fix will hold.

Queue recovery is not a green flag, it is processing that can commit for the right reason.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.