この記事では、.NET Framework API によって生成される .NET 例外の一覧を示します。
2026 年 9 月 30 日に、Azure SDK ガイドラインに準拠していない Azure Service Bus 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)。 一般的なアクション: 操作を再試行するか、ユーザーに通知します。 クライアント SDK の
RetryPolicyクラスは、再試行を自動的に処理するように構成できます。 詳細については、「 再試行のガイダンス」を参照してください。 - その他の例外 (System.Transactions.TransactionException、 System.TimeoutException、 Microsoft.ServiceBus.Messaging.MessageLockLostException、 Microsoft.ServiceBus.Messaging.SessionLockLostException)。 一般的なアクション: 例外の種類に固有。次のセクションの表を参照してください。
重要
- 操作がトランザクション スコープ内で行われる場合、Azure Service Bus はその操作で例外が発生しても再試行しません。
- Azure Service Bus に固有の再試行ガイダンスについては、「 Service Bus の再試行ガイダンス」を参照してください。
例外の種類
次の表に、メッセージング例外の種類とその原因と、実行できる推奨されるアクションを示します。
| 例外の種類 | 説明/原因/例 | 推奨されるアクション | 自動/即時再試行に関する注意 |
|---|---|---|---|
| タイムアウト例外 | サーバーは、OperationTimeout によって制御される指定された時間内に、要求された操作に対して応答しませんでした。 サーバーで、要求された操作が完了した可能性があります。 ネットワークまたはその他のインフラストラクチャの遅延が原因で発生する可能性があります。 | システムの状態の整合性を確認し、必要に応じて再試行します。 タイムアウト例外を参照してください。 | 再試行によって解決する場合があります。再試行ロジックをコードに追加してください。 |
| InvalidOperationException(無効なオペレーション例外) | 要求されたユーザー操作は、サーバーまたはサービス内で許可されていません。 詳細については、例外メッセージを参照してください。 たとえば、メッセージが ReceiveAndDelete モードで受信された場合、Complete() はこの例外を生成します。 | コードとドキュメントを確認します。 要求された操作が有効であることを確認します。 | 再試行は役に立ちません。 |
| OperationCanceledException(オペレーションキャンセル例外) | 既に終了、中止、または破棄されたオブジェクトに対して操作を呼び出そうとしました。 まれに、アンビエント トランザクションが既に破棄されている場合があります。 | コードを確認し、破棄されたオブジェクトに対して操作を呼び出していないことを確認します。 | 再試行は役に立ちません。 |
| UnauthorizedAccessException(未承認アクセス例外) | TokenProvider オブジェクトがトークンを取得できなかったか、トークンが無効であるか、操作を実行するために必要な要求がトークンに含まれていません。 | トークン プロバイダーが正しい値で作成されていることを確認します。 アクセス制御サービスの構成を確認します。 | 再試行によって解決する場合があります。再試行ロジックをコードに追加してください。 |
|
引数例外 ArgumentNull例外 ArgumentOutOfRangeException（範囲外の引数例外） |
メソッドに指定された 1 つまたは複数の引数が無効です。 NamespaceManager または Create に指定された URI には、パス セグメントが含まれています。 NamespaceManager または Create に指定された URI スキームが無効です。 プロパティ値が 32 KB を超えています。 |
呼び出し元のコードを確認し、引数が正しいことを確かめます。 | 再試行は役に立ちません。 |
| MessagingEntityNotFoundException(メッセージングエンティティNotFoundException) | 操作に関連付けられているエンティティが存在しないか、削除されています。 | エンティティが存在することを確認します。 | 再試行は役に立ちません。 |
| MessageNotFoundException(メッセージNotFoundException) | 特定のシーケンス番号を持つメッセージの受信を試みます。 このメッセージが見つかりません。 | メッセージがまだ受信されていないことを確認します。 デッドレターキューを調べて、メッセージがデッドレターされたかどうかを確認します。 | 再試行は役に立ちません。 |
| メッセージ通信例外 | クライアントは Service Bus への接続を確立できません。 | 指定されたホスト名が正しく、ホストに到達できることを確認します。 ファイアウォール/プロキシを使用する環境でコードを実行する場合は、Service Bus のドメイン/IP アドレスとポートへのトラフィックがブロックされていないことを確認します。 |
断続的な接続の問題がある場合は、再試行が役立つ場合があります。 |
| ServerBusy例外 | この時点では、このサービスで要求を処理できません。 | クライアントは一定期間待機してから、操作を再試行できます。 | クライアントは、一定の間隔が経過した後に再試行される場合があります。 再試行の結果、例外が異なる場合は、その例外の再試行動作を確認します。 |
| メッセージング例外 | 次の場合にスローされる可能性がある一般なメッセージング例外です。 別のエンティティ型 (トピックなど) に属する名前またはパスを使用して QueueClient を作成しようとしました。 256 KB を超えるメッセージを送信しようとしました。 サーバーまたはサービスで、要求の処理中にエラーが発生しました。 詳細については、例外メッセージを参照してください。 通常は一時的な例外です。エンティティが調整されているため、要求は終了されました。 エラー コード: 50001、50002、50008。 |
コードを確認し、シリアル化可能なオブジェクトのみがメッセージ本文に使用されていることを確認します (または、カスタム シリアライザーを使用します)。 プロパティのサポートされている値型のドキュメントを確認し、サポートされている型のみを使用します。 IsTransient プロパティを確認します。 true の場合は、操作を再試行できます。 |
例外がスロットリングによるものである場合は、数秒待ってから再度操作を試みてください。 再試行動作は未定義であり、他のシナリオでは役に立たない可能性があります。 |
| MessagingEntityAlreadyExistsException（メッセージングエンティティが既に存在する例外） | そのサービス名前空間内の別のエンティティによって既に使用されている名前を持つエンティティの作成を試みます。 | 既存のエンティティを削除するか、作成するエンティティの別の名前を選択します。 | 再試行は役に立ちません。 |
| QuotaExceededException(クォータ超過例外) | メッセージング エンティティが許容される最大サイズに達したか、名前空間への接続の最大数を超えました。 | エンティティまたはそのサブキューからメッセージを受信して、エンティティ内に領域を作成します。 「 QuotaExceededException」を参照してください。 | メッセージがそれまでに削除されている場合は、再試行によって解決することがあります。 |
| ルールアクション例外 | 無効なルール アクションを作成しようとすると、Service Bus はこの例外を返します。 Service Bus は、そのメッセージのルール アクションの処理中にエラーが発生した場合、この例外をデッドレターメッセージにアタッチします。 | ルールの動作が正しいか確認してください。 | 再試行は役に立ちません。 |
| フィルタ例外 | 無効なフィルターを作成しようとすると、Service Bus によってこの例外が返されます。 Service Bus は、そのメッセージのフィルターの処理中にエラーが発生した場合に、この例外を配信不能メッセージにアタッチします。 | フィルターの正確性を確認します。 | 再試行は役に立ちません。 |
| SessionCannotBeLockedException (セッションはロックされない例外) | 特定のセッション ID を持つセッションを受け入れるように試みますが、現在、セッションは別のクライアントによってロックされています。 | セッションが他のクライアントによってロック解除されていることを確認します。 | 再試行は、セッションが暫定的に解放された場合に役立つ場合があります。 |
| トランザクション サイズ 超過 例外 (TransactionSizeExceededException) | トランザクションの一部である操作が多すぎます。 | このトランザクションに含まれる操作の数を減らします。 | 再試行は役に立ちません。 |
| MessagingEntityDisabledException(メッセージングエンティティ無効例外) | 無効なエンティティに対するランタイム操作の要求。 | エンティティをアクティブにします。 | 再試行は、エンティティが暫定的にアクティブ化された場合に役立つ場合があります。 |
| NoMatchingSubscriptionException(マッチングサブスクリプション例外なし) | 事前フィルター処理が有効になっていて、フィルターが一致しないトピックにメッセージを送信すると、Service Bus はこの例外を返します。 | 少なくとも 1 つのフィルターが一致していることを確認します。 | 再試行は役に立ちません。 |
| MessageSizeExceededException (メッセージサイズが超過した例外) | メッセージ ペイロードが 256 KB の制限を超えています。 256 KB の制限はメッセージの合計サイズであり、システム プロパティや .NET オーバーヘッドを含めることができます。 | メッセージ ペイロードのサイズを小さくし、操作を再試行します。 | 再試行は役に立ちません。 |
| トランザクション例外 | アンビエント トランザクション (Transaction.Current) が無効です。 完了または中止された可能性があります。 内部例外によって追加情報が提供される場合があります。 |
再試行は役に立ちません。 | |
| TransactionInDoubtException (トランザクション・イン・ダウト・エクセプション) | 疑わしいトランザクションに対して操作が試行されたか、トランザクションのコミットが試行され、トランザクションが疑わしい状態になります。 | トランザクションが既にコミットされている可能性があるため、アプリケーションはこの例外を (特殊なケースとして) 処理する必要があります。 | - |
QuotaExceededException(クォータ超過例外)
QuotaExceededException は、特定のエンティティのクォータが超過していることを示します。
注
Service Bus クォータについては、クォータに関する記事を参照してください。
キューとトピック
キューとトピックは、通常、キューのサイズに関連します。 エラー メッセージのプロパティには、次の例のようにさらに詳しい情報が含まれます。
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.
一般的な原因
このエラーの 2 つの一般的な原因は、配信不能キューと機能していないメッセージ受信者です。
配信不能キュー リーダーがメッセージを完了できない状態でロックの有効期限が切れたときにメッセージがキュー/トピックに返されます。 これは、リーダーが BrokeredMessage.Complete を呼び出すのを妨げる例外を検出した場合に発生する可能性があります。 メッセージは 10 回読み取られた後、既定で配信不能キューに移動します。 この動作は QueueDescription.MaxDeliveryCount プロパティによって制御され、既定値は 10 です。 メッセージが配信不能キューに溜まるほど、領域が占有されます。
この問題を解決するには、他のキューの場合と同様に、配信不能キューからメッセージを読み取り、完了します。 FormatDeadLetterPath メソッドは、デッドレターキューのパスを書式設定するために使用できます。
受信者が停止しました。 受信者によるキューまたはサブスクリプションからのメッセージの受信が停止されています。 これを識別する方法は、 QueueDescription.MessageCountDetails プロパティを見て、メッセージの完全な内訳を示します。 ActiveMessageCount プロパティが高いか増加している場合、メッセージは書き込み中ほど高速に読み取られません。
TimeoutException
TimeoutException は、ユーザーが開始した操作が操作のタイムアウトよりも長くかかることを示します。
ServicePointManager.DefaultConnectionLimit プロパティの値を確認する必要があります。この制限に達した場合も、TimeoutException が発生する可能性があります。
サービスを実行するリソースに対する Service Bus サービスの更新 (または) OS の更新など、メンテナンス操作中またはメンテナンス操作の間にタイムアウトが発生することが予想されます。 OS の更新中にエンティティが移動され、ノードが更新または再起動されるため、タイムアウトが発生する可能性があります。 Azure Service Bus サービスのサービス レベル アグリーメント (SLA) の詳細については、「Service Bus の SLA」を参照してください。
キューとトピック
キューとトピックの場合、タイムアウトは MessagingFactorySettings.OperationTimeout プロパティで接続文字列の一部として、または ServiceBusConnectionStringBuilder を使用して指定されます。 エラー メッセージ自体は異なる場合がありますが、常に現在の操作に指定されたタイムアウト値が含まれています。
MessageLockLostException(メッセージロックロスト例外)
原因
MessageLockLostException は、PeekLock 受信モードを使用してメッセージを受信した際、クライアントが保持するロックがサービス側で期限切れになるときに発生します。
メッセージのロックは、さまざまな理由により期限切れになる場合があります。
- ロック タイマーが、クライアント アプリケーションによって更新される前に期限切れになっている。
- クライアント アプリケーションがロックを取得し、永続ストアにそれを保存してから再起動した。 再起動すると、クライアント アプリケーションは処理中のメッセージを確認し、これらを完了しようとしました。
この例外は、次のシナリオで発生する可能性もあります。
- サービスの更新
- OS の更新
- ロックを保持したままエンティティ (キュー、トピック、サブスクリプション) のプロパティを変更。
解決策
クライアント アプリケーションは、MessageLockLostException を受信すると、それ以上メッセージを処理できません。 クライアント アプリケーションは必要に応じて分析のために例外のログ記録を検討できますが、クライアントはメッセージを破棄する "必要があります"。
メッセージに対するロックは有効期限が切れたため、キュー (またはサブスクリプション) に戻され、受信を呼び出す次のクライアント アプリケーションで処理できるようになります。
MaxDeliveryCount を超えた場合、メッセージは DeadLetterQueue に移動される可能性があります。
SessionLockLostException (セッションロックロスト例外)
原因
SessionLockLostException は、セッションが受け入れられ、クライアントによって保持されているロックがサービス側で期限切れになったときにスローされます。
セッションのロックは、さまざまな理由により期限切れになる場合があります。
- ロック タイマーが、クライアント アプリケーションによって更新される前に期限切れになっている。
- クライアント アプリケーションがロックを取得し、永続ストアにそれを保存してから再起動した。 再起動後、クライアント アプリケーションが、転送中のセッションを調べて、これらのセッション内のメッセージを処理しようとした。
この例外は、次のシナリオで発生する可能性もあります。
- サービスの更新
- OS の更新
- ロックを保持したままエンティティ (キュー、トピック、サブスクリプション) のプロパティを変更。
解決策
クライアント アプリケーションは、SessionLockLostException を受け取ると、セッションでそれ以上メッセージを処理できません。 クライアント アプリケーションでは分析のために例外をログに記録することもできますが、クライアントはメッセージを破棄する "必要があります"。
セッションに対するロックは有効期限が切れたため、キュー (またはサブスクリプション) に戻され、セッションを受け入れる次のクライアント アプリケーションによってロックできます。 セッション ロックは、特定の時点で 1 つのクライアント アプリケーションによって保持されるため、順番どおりの処理が保証されます。
ソケット例外
原因
次の場合には、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 Service Bus への接続が許可されているかどうかをこちらで確認してください。
メッセージング例外
原因
MessagingException は、さまざまな理由でスローされる可能性がある一般的な例外です。 その理由の一部を次に示します。
- トピックまたはサブスクリプションに QueueClient を作成しようとしました。
- 送信されるメッセージのサイズが、特定のレベルの制限を超えています。 Service Bus の クォータと制限の詳細を参照してください。
- 調整のため、特定のデータ プレーン要求 (送信、受信、完了、破棄) が終了した。
- サービスのアップグレードと再起動が原因で発生した一時的な問題。
注
例外の一覧は完全ではありません。
解決策
解決手順は、MessagingException がスローされた原因によって異なります。
- 一時的な問題 (isTransient が true に設定されている場合) または調整の問題の場合は、操作を再試行すると解決される可能性があります。 SDK の既定の再試行ポリシーを使用できます。
- その他の問題については、例外の詳細は、問題と解決の手順を同じ手順から推測できることを示しています。
StorageQuotaExceededException (ストレージクォータ超過例外)
原因
StorageQuotaExceededException は、Premium 名前空間内のエンティティの合計サイズがメッセージング ユニットあたり 1 TB の制限を超えると生成されます。
解決策
- Premium 名前空間に割り当てられているメッセージング ユニットの数を増やす
- 名前空間に対して許可される最大メッセージング ユニットを既に使用している場合は、別の名前空間を作成します。
次のステップ
Service Bus の詳細な .NET API リファレンスについては、「Azure .NET API reference」(Azure .NET API リファレンス) を参照してください。 トラブルシューティングのヒントについては、トラブルシューティング ガイドに関する記事をご覧ください。