IIS / WASでホストされているサービスを、開発環境で自分自身として実行しています。net.msmqバインディングを使用してアクティブ化されます。キューのロックを伴うBufferedReceive（WFサービス）を使用するように構成されています。（接頭辞lock_のサブキューが作成されます）。
しばらくして、アプリプールが終了すると、ロックキューは自動的に削除されます。
システムを本番環境に移行した後、環境AFAIKは同一ですが、サービスが専用アカウントとして実行されているため、ロックキューはクリーンアップされなくなりました。アプリプールを停止すると、ロックキューが残り、メッセージが表示されます。
最も明らかな違いは、サービスが実行されているアカウントですが、これに影響を与えている権限の種類がわかりません。あるいは、私が見落としている他の構成の違いはありますか？手伝ってくれてありがとう。
OK、これは IIS/WAS のバグであることが判明しました。
3 つのアプリ プールがあり、そのうちの 2 つは自動起動で、そのうちの 1 つは msmq を消費していました。すべてが、NetMsmqListenerActivator と共有された同じ AD ドメイン ID を共有していました。そのnetmmqlistenerサービスはもともと停止していましたが、開始した後、症状が現れました。
どういうわけか、IIS/WAS が複数のチャネルを作成し、メッセージを間違ったプロセスに送信していました。この問題を回避するには、mq を消費する Web サービスと netmsmqlistener で使用される別の ID を作成し、続いてサーバーを再起動します。
これは、本番サーバーでのみ発生する痛ましい問題でした。得られた教訓は、運用サーバーがテスト サーバーと同じホットフィックスとパッチを共有していることを確認することです。
更新: Win 2k8 R2 SP1 のホットフィックス: http://support.microsoft.com/kb/2672277