https://error-daizenn.hatenablog.com/entry/2025/12/16/222836

2025年12月のセキュリティ更新（いわゆるパッチデー）を当てた直後から、Windows 10／Windows Server 2016／2019で、MSMQ（Message Queuing：メッセージキュー）が急に止まる、IIS（Internet Information Services：Webサーバー）が500で落ちる、ログが「空き容量足りない」って嘘つく──そんな報告がまとまってきました。企業システムで静かに動いていた“裏方の行列（キュー）”が詰まるので、地味に見えて被害はデカいタイプです。 (heise online)

何が起きた？まず結論だけ

12月更新でMSMQのセキュリティモデルが変わり、C:\Windows\System32\MSMQ\storageのNTFS権限（NTFS permissions：アクセス許可）が原因で書き込み不能→MSMQ送信が失敗します。 (Microsoft Learn)

症状はわりと典型で、たとえば「Insufficient resources to perform operation（操作を実行するためのリソース不足）」でIISが落ちたり、キューがinactive（非アクティブ）になったり、「The message file '…storage*.mq' cannot be created（メッセージファイルを作れない）」が出たりします。しかも「There is insufficient disk space or memory（ディスク領域またはメモリが不足）」みたいなミスリードまで混ざる。 (Microsoft Learn)

発生日時と対象：どのKB・どのビルド？

確認されている中心は“2025年12月9日公開”の月例セキュリティ更新で、12月12日に既知の問題として追記されました。 (Microsoft Learn)

今回の話を“自分の環境”に落とすなら、まずここです（ビルド番号も大事）。

Windows 10 22H2（ESU：Extended Security Updates／延長セキュリティ更新）
OS Build 19045.6691、KB5071546 (Microsoft Learn)

Windows Server 2016（＋Windows 10 version 1607系）
OS Build 14393.8688、KB5071543 (マイクロソフトサポート)

Windows Server 2019（＋Windows 10 version 1809系、LTSC 2019含む）
OS Build 17763.8146、KB5071544 (マイクロソフトサポート)

「Windows 10って全員？」と聞かれると、家庭PCはそもそもMSMQを使ってないことが多いので、体感ゼロの人も普通にいます。逆に、業務アプリやIISの裏でMSMQが動いてる会社ほど“気づいた時には止まってる”になりやすい。 (Windows Latest)

エラー表示：見えているメッセージはこのへん

現場で一番刺さっているのは「System.Messaging.MessageQueueException: Insufficient resources to perform operation」です。 (Microsoft Learn)

ほかにも、メッセージファイル作成失敗の文言（storage*.mq）や、ディスク/メモリ不足を装うログが並びます。リソース監視して「余ってるじゃん！」ってなるのに落ちるので、初見だと沼。 (マイクロソフトサポート)

原因：なぜ“権限”でMSMQが死ぬの？

Microsoftの説明は明快で、MSMQのセキュリティモデル変更＋storageフォルダーの権限変更で“MSMQ利用者が書けない構成”が増えた、という話です。 (Microsoft Learn)

ここがややこしいポイントで、MSMQはサービス自体は動いて見えるのに、実際のキュー操作（送信・作成）が“裏のファイル書き込み”で詰まる。IISのアプリプールID（IIS_IUSRS）や、LocalService／NetworkServiceみたいな制限アカウントで動かしてると、ドンピシャで踏みます。 (Microsoft Learn)

「管理者（administrator：管理者権限）なら影響しにくい」とされるのも、この書き込み権限の話と一致します。 (Microsoft Learn)

公式の対応状況：直った？まだ？

現時点（2025年12月16日）では“Confirmed（確認済み）／Investigating（調査中）”で、恒久パッチや明確な回避策はまだ出ていません。 (Microsoft Learn)

MicrosoftのKB（KB5071546/1543/1544）にも既知の問題として追記が入り、次の案内待ち、という書き方です。 (マイクロソフトサポート)

他ユーザーの報告：フォーラムの“生の声”はこう

「KBを戻したら直った」「IIS_IUSRSやLocalServiceがmsmqフォルダーに書けなくなった」が、かなり共通しています。 (Microsoft Learn)

Microsoft Q&A（公式フォーラム）では、Server 2019でKB5071544をロールバックしたら復旧、Server 2016でもKB5071543を戻したら復旧、という報告が具体的に出ています。 (Microsoft Learn)

Reddit側は温度感がバラけていて、技術というより「また壊れた」系の愚痴も多い。とはいえ、こういう“現場の空気”が先に広がって、あとからKBが追記される流れは、パッチデーあるあるです。 (Reddit)

で、どうする？現実的な選択肢は2つ

結局は「セキュリティ更新を維持したまま権限を調整する」か「更新を外して復旧優先にする」かの二択になりがちです。 (Microsoft Learn)

前者（ACL修正：Access Control List／アクセス制御の調整）は、うまくいけば“止血しつつ更新維持”ができます。ただし権限を広げる＝セキュリティ設計に触るので、組織だと稟議が必要になりやすい。しかも「手で直しても元に戻されるっぽい」という報告もあって、これがまたイヤなところ。 (Microsoft Learn)

後者（ロールバック）は即効性が強い一方、12月の脆弱性修正を捨てるので、期間限定の暫定措置にするのが現実的です。なお、MSMQ自体にも特権昇格（Elevation of Privilege：権限昇格）のCVEが12月に出ています（CVE-2025-62455）。ここ、判断が割れそう。 (NVD)

手順：まず影響確認、次に“最小の復旧”へ

焦っていきなり全部戻す前に「自分が踏んでるのがMSMQ問題か」を切り分けるのが最短です。 (Microsoft Learn)

(1) 影響端末/サーバーで、OSビルドとKBを確認します。winver、または「更新履歴」→「インストールされた更新プログラム」からKB5071546/1543/1544が入っているか見ます。 (マイクロソフトサポート)
(2) エラーが「Insufficient resources to perform operation」やstorage*.mq cannot be created系か、イベントログとアプリログで確認します。 (Microsoft Learn)
(3) MSMQを実際に使っている実行主体（IIS_IUSRS、特定サービスアカウント等）が、C:\Windows\System32\MSMQ\storageへ書き込める前提だったかを確認します。 (Microsoft Learn)
(4) 暫定復旧を急ぐなら、まずはロールバック（KB削除）を検討します。Windows 10なら「設定」→「更新とセキュリティ」→「更新履歴」→「更新プログラムをアンインストール」、サーバーなら運用手順に沿って該当KBを外し、再起動で戻るケースが報告されています。 (Microsoft Learn)
(5) ロールバックが難しい場合のみ、セキュリティチームと相談のうえでstorageフォルダーのACLを“必要最小限”で調整します。ここは組織ごとに正解が変わるので、闇雲に「Everyoneにフル権限」は絶対におすすめしません。 (Microsoft Learn)

コメント欄をフォーラム化：あなたの環境、どれ？

いま一番ほしいのは「どの構成で踏んだか／踏まないか」の具体例です。

よかったら、コメントでこの3点だけでも教えてください。Windows 10は22H2（ESU）なのか、Serverは2016/2019なのか。KBは5071546/1543/1544のどれか。MSMQの実行主体はIISアプリプールなのか、サービスアカウントなのか。あと、キューがinactiveになったのか、IISが500になったのか、ログだけ騒いで実害はないのか……この差が、次の対策のヒントになります。 (Microsoft Learn)

「ロールバックで凌いだ」派は、戻したKBと再発の有無もぜひ。
「ACLで凌いだ」派は、どこまで権限を広げたか、そして“勝手に戻された？”の体験談が知りたいです。 (Microsoft Learn)

最後に、今回の発端を報じたHeiseの元記事も押さえておくと流れが追いやすいです（2025年12月15日掲載）。 (heise online)