本文列出 .NET Framework API 所產生的 .NET 例外狀況。
在 2026 年 9 月 30 日，我們將淘汰不符合 Azure SDK 準則的 Azure 服務匯流排 SDK 程式庫 WindowsAzure.ServiceBus、Microsoft.Azure.ServiceBus 和 com.microsoft.azure.servicebus。 我們也將結束 SBMP 通訊協定的支援，因此您將無法在 2026 年 9 月 30 日之後再使用此通訊協定。 請在該日期之前移轉至最新的 Azure SDK 程式庫，該程式庫提供重要的安全性更新和改進的功能。
雖然較舊的程式庫仍可在 2026 年 9 月 30 日之後使用，但它們將不再收到 Microsoft 的官方支援和更新。 如需詳細資訊，請參閱 支援停用公告。
例外狀況類別
傳訊 API 會產生可能屬於下列類別的例外狀況，以及您可以採取的相關動作來嘗試修正這些例外狀況。 例外狀況的意義和原因可能會根據傳訊實體的類型而有所不同：
- 用戶編碼錯誤（System.ArgumentException、 System.InvalidOperationException、 System.OperationCanceledException、 System.Runtime.Serialization.SerializationException）。 一般動作：請先嘗試修正程序代碼，再繼續進行。
- 設置/配置錯誤（Microsoft.ServiceBus.Messaging.MessagingEntityNotFoundException，System.UnauthorizedAccessException）。 一般動作：檢閱您的設定，並視需要變更。
- 暫時性例外狀況（Microsoft.ServiceBus.Messaging.MessagingException、 Microsoft.ServiceBus.Messaging.ServerBusyException、 Microsoft.ServiceBus.Messaging.MessagingCommunicationException）。 一般動作：重試作業或通知使用者。
RetryPolicy用戶端 SDK 中的 類別可以設定為自動處理重試。 如需詳細資訊，請參閱 重試指引。 - 其他例外狀況（System.Transactions.TransactionException、 System.TimeoutException、 Microsoft.ServiceBus.Messaging.MessageLockLostException、 Microsoft.ServiceBus.Messaging.SessionLockLostException）。 一般動作：例外狀況類型專屬;請參閱下一節中的表格：
這很重要
- 當作業在交易範圍內發生例外狀況時，Azure 服務總線不會重試該作業。
- 如需 Azure 服務總線專屬的重試指引，請參閱 服務匯流的重試指引。
例外狀況類型
下表列出傳訊例外狀況類型及其原因，以及您可以採取的建議動作。
| 例外狀況類型 | 描述/原因/範例 | 建議的動作 | 自動/立即重試時的注意事項 |
|---|---|---|---|
| TimeoutException （超時異常） | 伺服器未在指定時間內回應要求的作業，此作業由 OperationTimeout 控制。 伺服器可能已完成要求的作業。 可能會因為網路或其他基礎結構延遲而發生。 | 檢查系統狀態是否有一致性，並視需要重試。 請參閱 逾時例外狀況。 | 在某些情況下，重試也許有幫助；將重試邏輯新增至程式碼。 |
| InvalidOperationException | 不允許在伺服器或服務內執行要求的使用者作業。 如需詳細資訊，請參閱例外狀況訊息。 例如， Complete（） 如果在 ReceiveAndDelete 模式中收到訊息，則會產生此例外狀況。 | 檢查程式碼和文件。 請確定要求的作業有效。 | 重試沒有用。 |
| OperationCanceledException 異常 | 嘗試在已關閉、中止或處置的物件上叫用作業。 極少數的情況下，環境交易是已處置狀態。 | 檢查程式碼，確定其不會在已處置物件上叫用作業。 | 重試沒有用。 |
| UnauthorizedAccessException 異常 | TokenProvider 物件無法取得令牌、令牌無效，或令牌不包含執行作業所需的宣告。 | 請確保已使用正確值建立憑證提供者。 檢查訪問控制服務的組態。 | 在某些情況下，重試也許有幫助；將重試邏輯新增至程式碼。 |
|
ArgumentException 異常 ArgumentNullException 異常 ArgumentOutOfRangeException 異常 |
提供給方法的一個或多個引數無效。 提供給 NamespaceManager 或 Create 的 URI 包含路徑區段。 提供給 NamespaceManager 或 Create 的 URI 配置無效。 屬性值大於 32 KB。 |
檢查呼叫程式碼，並確定引數正確無誤。 | 重試沒有用。 |
| MessagingEntityNotFoundException 異常 | 與作業相關聯的實體不存在或已刪除。 | 請確定實體存在。 | 重試沒有用。 |
| MessageNotFoundException 異常 | 嘗試接收具有特定序號的訊息。 找不到此訊息。 | 請確定尚未收到訊息。 檢查死信佇列，以查看訊息是否已被標記為死信。 | 重試沒有用。 |
| MessagingCommunicationException 異常 | 用戶端無法建立服務總線的連線。 | 請確定提供的主機名正確且可連線到主機。 如果您的程式代碼在具有防火牆/Proxy 的環境中執行，請確定不會封鎖服務總線網域/IP 位址和埠的流量。 |
如果發生間歇性連線問題，重試或許會有幫助。 |
| ServerBusy異常 | 服務目前無法處理要求。 | 用戶端可以等候一段時間，然後重試作業。 | 用戶端可能會在特定間隔之後重試。 如果重試導致不同的例外狀況，請檢查該例外狀況的重試行為。 |
| MessagingException 異常 | 在下列情況下可能會擲回的泛型傳訊例外狀況： 嘗試使用屬於不同實體類型的名稱或路徑建立 QueueClient （例如主題）。 嘗試傳送大於 256 KB 的訊息。 伺服器或服務在處理要求時發生錯誤。 如需詳細資訊，請參閱例外狀況訊息。 這通常是暫時性例外狀況。要求已終止，因為實體正在被限制流量。 錯誤碼：50001、50002、50008。 |
檢查程式代碼，並確定只有可串行化的對象用於訊息本文（或使用自定義串行化程式）。 請查看文件以了解屬性支援的值類型，並且只使用這些支援的類型。 檢查 IsTransient 屬性。 如果 為 true，您可以重試作業。 |
如果例外狀況是由於節流，請等候幾秒鐘，然後再次重試作業。 重試行為未定義，在其他案例中可能無濟於事。 |
| MessagingEntityAlreadyExistsException（訊息實體已存在例外） | 嘗試建立具有該服務命名空間中另一個實體已使用之名稱的實體。 | 刪除現有的實體，或為要建立的實體選擇不同的名稱。 | 重試沒有用。 |
| QuotaExceeded異常 | 傳訊實體已達到其允許大小上限，或已超過命名空間的連線數目上限。 | 從實體或其子佇列接收訊息，在實體中建立空間。 請參閱 QuotaExceededException。 | 如果在此同時已移除訊息，重試可能會有幫助。 |
| RuleActionException 異常 | 如果您嘗試建立無效的規則動作，Service Bus 會傳回此例外。 如果在處理訊息的規則動作時發生錯誤，服務匯流排會將此例外附加到該訊息的死信中。 | 檢查規則動作是否正確。 | 重試沒有用。 |
| FilterException | 如果您嘗試建立無效的篩選條件，服務總線會傳回此例外狀況。 如果處理該訊息的篩選時發生錯誤，服務總線會將此例外狀況附加至無效的訊息。 | 檢查篩選是否有正確性。 | 重試沒有用。 |
| SessionCannotBeLockedException 異常 | 嘗試接受具有特定會話標識碼的會話，但會話目前由另一個客戶端鎖定。 | 請確認會話已被其他用戶端解除鎖定。 | 如果會話已在期間內釋放，重試可能會有幫助。 |
| 交易大小超限異常 | 太多操作是交易的一部分。 | 減少屬於此交易一部分的作業數目。 | 重試沒有用。 |
| MessagingEntityDisabledException 異常 | 請求在停用的實體上執行運行時操作。 | 啟動實體。 | 如果實體已在中途啟動，重試可能會有所幫助。 |
| NoMatchingSubscriptionException 異常 | 如果您將訊息傳送到已啟用預篩選的主題，而篩選條件未被滿足，服務總線會回報此例外狀況。 | 請確定至少有一個篩選條件相符。 | 重試沒有用。 |
| MessageSizeExceededException（訊息大小超出例外狀況） | 訊息承載超過 256 KB 的限制。 256 KB 的限制是訊息大小總計，可包含系統屬性和任何 .NET 額外負荷。 | 減少訊息裝載大小，然後再重試作業。 | 重試沒有用。 |
| 事務異常 | 環境交易 （Transaction.Current） 無效。 它可能已完成或中止。 內部例外狀況可能會提供其他資訊。 |
重試沒有用。 | |
| TransactionInDoubtException 異常 | 在不確定的交易上嘗試作業，或嘗試認可交易，而交易會變得不確定。 | 您的應用程式必須處理此例外狀況（作為特例），因為交易可能已經提交。 | - |
配額超過例外 (QuotaExceededException)
QuotaExceededException 表示已超過特定實體的配額。
備註
如需服務總線配額，請參閱 配額。
佇列和主題
在佇列和主題方面，問題通常在於佇列大小。 錯誤訊息屬性會包含進一步的詳細資訊，如下例所示：
Microsoft.ServiceBus.Messaging.QuotaExceededException
Message: The maximum entity size has been reached or exceeded for Topic: 'xxx-xxx-xxx'.
Size of entity in bytes:1073742326, Max entity size in bytes:
1073741824..TrackingId:xxxxxxxxxxxxxxxxxxxxxxxxxx, TimeStamp:3/15/2013 7:50:18 AM
訊息指出主題超過其大小限制，本例為 1 GB (預設大小限制)。
命名空間
針對命名空間， QuotaExceededException 可以指出應用程式已超過命名空間連線數目上限。 例如：
Microsoft.ServiceBus.Messaging.QuotaExceededException: ConnectionsQuotaExceeded for namespace xxx.
<tracking-id-guid>_G12 --->
System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]:
ConnectionsQuotaExceeded for namespace xxx.
常見原因
這個錯誤有兩種常見原因︰無效信件佇列和訊息接收者無法正常運作。
死信佇列 讀取器無法完成處理訊息，當鎖定到期時，訊息會傳回佇列/主題。 如果讀取器遇到防止它呼叫 BrokeredMessage.Complete 的例外狀況，就可能發生此情況。 訊息讀取 10 次後，預設會移至無效信件佇列。 此行為是由 QueueDescription.MaxDeliveryCount 屬性所控制，且預設值為 10。 訊息堆積在無效信件佇列中會佔用空間。
若要解決此問題，請閱讀和完成無效信件佇列中的訊息，就像您處理任何其他佇列一樣。 您可以使用 FormatDeadLetterPath 方法來格式化死信佇列路徑。
接收者已停止。 收件者已停止接收佇列或訂用帳戶的訊息。 識別它的方式是查看 QueueDescription.MessageCountDetails 屬性，其中顯示訊息的完整明細。 如果 ActiveMessageCount 屬性很高或成長，則訊息的讀取速度不會像寫入一樣快。
TimeoutException
TimeoutException 表示使用者啟動的作業所花費的時間超過了作業的時限。
您應該檢查 ServicePointManager.DefaultConnectionLimit 屬性的值，因為達到此限制也可能導致 TimeoutException。
預期會在維護作業期間或作業之間發生逾時，例如服務匯流排的服務更新或執行該服務之資源的作業系統更新。 在OS更新期間，實體會重新配置，而節點會更新或重新啟動，這可能會導致時間中斷。 如需 Azure 服務總線服務的服務等級協定（SLA）詳細數據，請參閱 服務總線的 SLA。
佇列和主題
針對佇列和主題，逾時設定可以在MessagingFactorySettings.OperationTimeout屬性中指定，也可以作為連接字串的一部分，或是透過ServiceBusConnectionStringBuilder來指定。 錯誤訊息本身可能會有所不同，但一律包含針對目前作業指定的逾時值。
MessageLockLostException
原因
當在使用 PeekLock 接收模式接收到訊息，而用戶端持有的鎖定在服務端到期時，就會丟出 MessageLockLostException。
訊息上的鎖定可能會由於多種原因而到期：
- 鎖定計時器已在用戶端應用程式更新鎖定之前到期。
- 用戶端應用程式已取得鎖定，將其儲存至持續性存放區，然後重新啟動。 重新啟動之後，用戶端應用程式會查看傳入的訊息，並嘗試完成這些訊息。
在下列案例中，您可能也會收到此例外狀況：
- 服務更新
- 作業系統更新
- 在保留鎖定時變更實體 (佇列、主題、訂用帳戶) 上的屬性。
解決辦法
當用戶端應用程式收到 MessageLockLostException 時，就無法再處理訊息。 用戶端應用程式可能會選擇性地考慮記錄例外狀況進行分析，但用戶端「必須」處置訊息。
由於訊息上的鎖定已到期，因此會回到佇列 (或訂用帳戶)，並可由呼叫接收的下一個用戶端應用程式加以處理。
如果 MaxDeliveryCount 已超過，則訊息可能會移至 DeadLetterQueue。
會話鎖丟失異常 (SessionLockLostException)
原因
當會話被接受且用戶端持有的鎖定在伺服器端到期時，會擲回 SessionLockLostException。
工作階段上的鎖定可能會由於多種原因而到期：
- 鎖定計時器已在用戶端應用程式更新鎖定之前到期。
- 用戶端應用程式已取得鎖定，將其儲存至持續性存放區，然後重新啟動。 一旦重新啟動，用戶端應用程式就會查看傳遞中工作階段，並嘗試在這些工作階段中處理訊息。
在下列案例中，您可能也會收到此例外狀況：
- 服務更新
- 作業系統更新
- 在保留鎖定時變更實體 (佇列、主題、訂用帳戶) 上的屬性。
解決辦法
當用戶端應用程式收到 SessionLockLostException 時，它就無法再處理會話上的訊息。 用戶端應用程式可能會考慮記錄例外狀況進行分析，但用戶端「必須」處置訊息。
由於工作階段上的鎖定已到期，因此會回到佇列 (或訂用帳戶)，並可由接受該工作階段的下一個用戶端應用程式鎖定。 工作階段鎖定無論何時都只會由單一用戶端應用程式保留，因此一定能按順序處理。
SocketException 異常
原因
在下列情況下，會拋出 SocketException ：
- 當連線嘗試因為主機未在指定的時間之後正確回應而失敗時 (TCP 錯誤碼 10060)。
- 已建立的連線失敗，因為連線的主機無法回應。
- 處理訊息時發生錯誤，或者是遠端主機逾時已過。
- 基礎網路資源問題。
解決辦法
SocketException 錯誤表示裝載應用程式的 VM 無法將名稱<mynamespace>.servicebus.windows.net轉換為對應的 IP 位址。
查看下列命令是否成功對應至 IP 位址。
PS C:\> nslookup <mynamespace>.servicebus.windows.net
這應該會提供類似下方的輸出：
Name: <cloudappinstance>.cloudapp.net
Address: XX.XX.XXX.240
Aliases: <mynamespace>.servicebus.windows.net
如果名稱 未解析 為IP或命名空間別名，請洽詢網路管理員以進一步調查。 名稱解析是透過 DNS 伺服器 (通常是客戶網路中的資源) 完成。 如果 DNS 解析是由 Azure DNS 完成，請連絡 Azure 支援。
如果名稱解析 如預期般運作，請檢查 這裡是否允許連線至 Azure 服務總線。
MessagingException 異常
原因
MessagingException 是一般例外狀況，可能會因為各種原因而擲回。 其中一些原因包括：
- 嘗試在主題或訂閱上建立QueueClient。
- 所傳送訊息的大小大於指定層的限制。 深入瞭解服務總線 配額和限制。
- 特定數據平面請求（傳送、接收、完成、放棄）因速率限制而被終止。
- 由於服務升級和重新啟動所造成的暫時性問題。
備註
例外狀況清單並不詳盡。
解決辦法
解決步驟取決於導致 MessagingException 擲回的原因。
- 針對 暫時性問題 （其中 isTransient 設定為 true）或 針對節流問題，重試作業可能會解決此問題。 您可以使用 SDK 上的預設重試原則。
- 對於其他問題，例外狀況中的詳細數據表示問題與解決步驟可以從相同的方式推斷。
儲存配額已超過異常（StorageQuotaExceededException）
原因
當進階命名空間中的實體總大小超過每個傳訊單位 1 TB 的限制時，會產生 StorageQuotaExceededException。
解決辦法
- 增加指派給進階命名空間的傳訊單位數目
- 如果您已經針對命名空間使用允許的最大傳訊單位，請建立個別的命名空間。
後續步驟
如需完整的服務總線 .NET API 參考，請參閱 Azure .NET API 參考。 如需疑難解答秘訣，請參閱 疑難解答指南。