Microsoft が 2026年7月2日に公開した「The case of the thread executing from an unloaded third-party DLL」は、Microsoft 365 や Azure の管理画面に新しい設定が追加されたという話ではありません。結論から言うと、Windows Explorer が古いサードパーティ製シェル拡張を読み込んだ際、DLL のアンロード後もワーカースレッドが実行され、Explorer クラッシュにつながっていた事例を解説した技術記事です。(Microsoft for Developers)

管理者がまず確認すべきことは、社内 PC に古いクラウド同期クライアント、名前空間拡張、右クリックメニュー拡張などが残っていないかです。開発者や ISV にとっては、DllCanUnloadNow、バックグラウンドスレッド、DLL の参照カウント管理を見直すべき典型例です。「Oops, I didn’t realize that I was still doing that.」という言葉で表すなら、“もう DLL をアンロードしてよいと思ったが、実は裏でまだスレッドが動いていた” という問題です。

Microsoft の新機能・変更点：「The case of the thread executing from an unloaded third-party DLL」で確認すべきポイント

今回の Microsoft 公式情報は、一般的な機能追加のリリースノートではなく、Windows の互換性対応とクラッシュ解析の事例紹介です。Microsoft の Raymond Chen 氏が The Old New Thing で公開した記事では、Explorer チームが比較的高い頻度で発生していたクラッシュを調査し、アンロード済みのサードパーティ DLL からスレッドが実行されている状態を確認したと説明されています。(Microsoft for Developers)

ポイントは、クラッシュしたスレッドそのものが原因ではなく「被害者」だったことです。Microsoft の記事でも、こうした調査ではクラッシュ中のスレッドだけを見ても情報が少なく、どのコンポーネントが DLL を早すぎるタイミングでアンロードしたのかを追う必要があるとされています。(Microsoft for Developers)

確認項目	今回の要点	管理者・開発者が取るべき対応
対象	Windows Explorer とサードパーティ製シェル拡張の相互作用	古い拡張機能やクラウド同期クライアントを棚卸しする
変更の性質	Microsoft 側の互換性対応事例	管理センターで有効化する新機能ではない
影響	Explorer のクラッシュ、操作中断、ユーザー体験の低下	更新・削除・代替クライアントへの移行を検討する
開発上の論点	DLL アンロード後もワーカースレッドが残る設計	DLL 参照カウント、スレッド終了、COM アンロード処理を見直す
移行期限	公式記事内で新たな期限は示されていない	サポート切れ製品は期限を待たず更新対象にする

何が起きたのか：アンロード済み DLL からスレッドが実行されていた

Microsoft の記事では、Explorer のクラッシュダンプ上で <Unloaded_...dll> という形のスタックが確認されています。これは、スレッドが実行しようとしていたコードの DLL が、すでにプロセスのアドレス空間からアンロードされていたことを示します。(Microsoft for Developers)

通常、DLL がアンロードされると、その DLL 内のコードは安全に実行できません。にもかかわらず、その DLL 内で作られたワーカースレッドが残っていると、スレッドは存在するのに実行先のコードが消えている、という危険な状態になります。今回のケースでは、クラッシュしたスレッドは浅いスタックを持つワーカースレッドで、待機中または作業待ちだった可能性があると説明されています。(Microsoft for Developers)

実務的には、次のような構成で起きやすい問題です。

• Explorer に読み込まれるシェル拡張 DLL
• クラウドストレージや同期クライアントの名前空間拡張
• 右クリックメニューやプレビュー、アイコンオーバーレイを提供する拡張
• COM DLL が内部で利用する補助 DLL
• 補助 DLL が独自に作成するワーカースレッド、タイマー、非同期コールバック

原因の流れ：DllCanUnloadNow だけでは守れないケースがある

今回の中心は、Explorer に読み込まれたサードパーティ製の名前空間拡張 DLL です。Microsoft の記事では、メインの CcNamespace.dll が Explorer のシェル拡張として読み込まれ、DllCanUnloadNow が S_OK を返したため、COM 側からアンロード可能と判断された流れが説明されています。(Microsoft for Developers)

ただし問題は、メイン DLL が直接持つ COM オブジェクト参照だけを見て「もう使われていない」と判断していた点です。実際には、補助 DLL 側で作成されたワーカースレッドがまだ残っていました。つまり、メイン DLL は「自分はもう使われていない」と答えた一方で、依存 DLL の内部実装ではまだ処理が続いていた、という状態です。(Microsoft for Developers)

DllCanUnloadNow は、COM DLL がまだ使用中かどうかを示すための関数です。Microsoft Learn では、COM をサポートする DLL はこの関数を実装・エクスポートし、まだ管理中のオブジェクト参照がある場合は S_FALSE を返すべきと説明されています。(Microsoft Learn)

しかし、今回のように補助 DLL が COM DLL ではなく、単なる内部ライブラリとして使われている場合、補助 DLL 側の DllCanUnloadNow を直せばよい、とは限りません。Microsoft の記事でも、ユーティリティライブラリが COM DLL ではない可能性があり、DllCanUnloadNow の修正だけでは解決しないと指摘されています。(Microsoft for Developers)

Microsoft 側の対応：互換性フラグで DLL をアンロードさせない

今回、対象となったサードパーティ製の名前空間拡張はすでに提供終了済みで、ベンダー側の修正は期待できない状態でした。そのため Windows 側では、対象のシェル拡張を読み込む際に GetModuleHandleEx と GET_MODULE_HANDLE_EX_FLAG_PIN を使い、DLL をプロセス終了までアンロードしない互換性対応を追加したと説明されています。(Microsoft for Developers)

GET_MODULE_HANDLE_EX_FLAG_PIN は、FreeLibrary が何度呼ばれてもプロセス終了までモジュールを読み込んだままにするフラグです。Microsoft Learn でも、このフラグを指定した場合、モジュールはプロセス終了まで読み込まれた状態になると説明されています。(Microsoft Learn)

ここで重要なのは、これは特定の旧式サードパーティ製品に対する Windows の互換性回避策であり、すべての DLL 問題を一般的に解決するものではないという点です。企業管理者が管理センターで同じフラグを設定する話ではなく、アプリケーション互換性チームによる限定的な保護策と理解するのが適切です。

影響範囲：Microsoft クラウドの設定変更ではなく、Windows クライアント側の問題

今回の情報を「Microsoft の更新」として読む場合、影響範囲を誤解しないことが大切です。これは Microsoft 365、Azure、Entra ID、Teams などのクラウド管理機能の変更ではありません。影響が出る可能性があるのは、Windows Explorer に古いサードパーティ製シェル拡張が読み込まれる端末です。

対象者	影響の見方	優先して確認すべきこと
情シス・端末管理者	Explorer クラッシュやファイル操作時の不安定化	古い同期クライアント、シェル拡張、未サポート製品の有無
グローバル IT 管理者	国・地域ごとに古いクライアントが残るリスク	標準イメージ、配布アプリ、例外端末の棚卸し
開発者	DLL ライフサイクル設計の欠陥	ワーカースレッド、コールバック、参照カウント管理
ISV	旧製品が Windows 側の互換性対応に依存するリスク	サポート中バージョンへの更新案内、拡張方式の見直し
セキュリティ担当	サポート切れソフトウェアの残存リスク	EDR/資産管理ツールでの検出と削除計画

特にグローバル環境では、本社では新しいクライアントに移行済みでも、海外拠点、共有 PC、VDI イメージ、長期間使われていない端末に古い拡張が残っていることがあります。Explorer のクラッシュは「一部ユーザーの PC が不安定」という現象に見えやすいため、アプリケーション資産管理の観点で確認することが重要です。

設定変更と移行期限：公式記事で新しい管理者操作は示されていない

今回の記事には、管理者が有効化すべき新しい設定、移行期限、ポリシー変更、ライセンス変更は示されていません。Microsoft 側の説明は、クラッシュ解析から原因を特定し、サポート切れのサードパーティ製拡張に対して Windows 側で互換性フラグを追加した、という内容です。(Microsoft for Developers)

ただし、移行期限が明示されていないからといって、何もしなくてよいわけではありません。記事中の対象製品は、すでに古い方式の名前空間拡張が廃止され、別の統合方式に置き換えられていたと説明されています。つまり、管理者が学ぶべきことは「Microsoft が互換性で吸収してくれるから放置する」ではなく、「サポート切れのシェル拡張は、OS 側の安定性に影響するため優先的に整理する」です。(Microsoft for Developers)

管理者が確認すべきポイント

古いクラウド同期クライアントやシェル拡張を棚卸しする

まず確認すべきは、Explorer に統合される古いアプリケーションです。クラウドストレージ、文書管理、暗号化、バックアップ、DLP、圧縮ツール、バージョン管理ツールなどは、右クリックメニュー、アイコンオーバーレイ、プレビュー、名前空間拡張を追加することがあります。

棚卸しでは、単に「アプリがインストールされているか」だけでなく、次の観点で確認します。

• ベンダーのサポートが継続しているバージョンか
• Windows 11 や現在の Windows ビルドでサポートされているか
• Explorer に拡張を追加しているか
• 古い拡張方式が残っていないか
• 代替クライアントや新方式への移行が案内されていないか

特に、過去のプロジェクトで導入したクラウド同期ツールや、特定部門だけが使っているファイル管理ツールは見落とされやすい領域です。

Explorer クラッシュを「端末個別の不調」で片付けない

Explorer が突然再起動する、右クリックで固まる、特定フォルダーを開くと落ちる、といった現象は、OS 本体ではなくシェル拡張が原因のことがあります。今回の Microsoft 記事も、Explorer チームの調査からサードパーティ DLL のアンロード問題にたどり着いた事例です。(Microsoft for Developers)

管理者は、問い合わせが複数端末で発生している場合、次のように切り分けると実務的です。

症状	疑うべき要因	確認アクション
右クリック時に Explorer が落ちる	コンテキストメニュー拡張	最近追加・更新されたツールを確認
クラウドフォルダーを開くと落ちる	同期クライアント、名前空間拡張	対象クライアントのバージョンを確認
特定ファイル形式で落ちる	プレビュー拡張、サムネイル拡張	該当アプリのプレビュー機能を確認
一部端末だけ不安定	古いバージョンの残存	資産管理ツールでバージョン差分を確認
VDI や標準イメージで再現	イメージに含まれる拡張	マスターイメージを見直す

サポート切れ製品を例外運用にしない

今回の事例で特に重要なのは、問題のあるサードパーティ製品がすでにサポート外だった点です。Microsoft の記事では、ベンダーに連絡しても意味がない状態だったため、Windows 側で互換性対応を行ったと説明されています。(Microsoft for Developers)

企業では「業務上まだ使える」「利用者が慣れている」「新バージョンは費用がかかる」という理由で旧製品が残りがちです。しかし、Explorer に読み込まれる拡張は、単独アプリよりも影響範囲が広くなります。ユーザーがそのアプリを明示的に起動していなくても、Explorer の操作だけで DLL が読み込まれる可能性があるためです。

判断基準としては、次のいずれかに該当する製品は更新・削除の優先度を上げるべきです。

• ベンダーサポートが終了している
• 最新 Windows でのサポート表明がない
• Explorer 拡張をインストールする
• クラウド同期やファイル仮想化に関わる
• クラッシュやフリーズの問い合わせと時期が一致する
• 代替方式や後継製品がすでに提供されている

開発者・ISV が見直すべき実装ポイント

今回の教訓は、COM DLL が DllCanUnloadNow を正しく返すだけでは不十分な場合がある、という点です。DLL 内または依存 DLL 内でスレッドやコールバックを作る場合、そのコードが実行されている間は DLL がアンロードされないように設計する必要があります。

Microsoft の記事では、ワーカースレッド開始時に DLL の参照カウントを増やし、終了時に FreeLibraryAndExitThread を使う方法、またはスレッドプールを使って FreeLibraryWhenCallbackReturns でコールバック完了後に参照を解放する方法が示されています。(Microsoft for Developers)

FreeLibraryAndExitThread は、DLL 内で実行されているスレッドが実行中の DLL を安全に解放し、自身を終了するための関数です。Microsoft Learn でも、FreeLibrary と ExitThread を個別に呼ぶと競合状態があり、ExitThread 前にライブラリがアンロードされる可能性があると説明されています。(Microsoft Learn)

また、FreeLibraryWhenCallbackReturns は、現在のスレッドプールコールバックが完了したときにアンロードする DLL を指定する関数です。スレッドプールベースの実装では、このような仕組みを使うことで、コールバック実行中に DLL が消えるリスクを抑えられます。(Microsoft Learn)

開発レビューで確認したいチェックリスト

確認項目	悪い例	改善の方向性
ワーカースレッド	DLL 内でスレッドを作るが参照カウントを保持しない	スレッド実行中は DLL を保持する
終了処理	FreeLibrary と ExitThread を別々に呼ぶ	FreeLibraryAndExitThread を検討する
COM アンロード判定	COM オブジェクト参照だけで S_OK を返す	内部スレッドや依存 DLL の状態も含めて判断する
補助 DLL	メイン DLL から見えないバックグラウンド処理を持つ	ライフサイクルを明示的に管理する
スレッドプール	コールバック中の DLL アンロードを考慮しない	FreeLibraryWhenCallbackReturns や関連 API を検討する
DllMain	終了待ちや重い処理を入れる	デッドロックやローダーロックを避ける設計にする

スレッドプールを使う場合は、SetThreadpoolCallbackLibrary も関連する選択肢になります。この関数は、未完了のコールバックがある間、指定された DLL が読み込まれた状態を維持するためのものです。ただし Microsoft Learn では、処理負荷やクリーンアップ時の注意も説明されているため、単純に入れればよい API ではなく、設計全体で使いどころを判断する必要があります。(Microsoft Learn)

よくある誤解と注意点

誤解	正しい理解
Microsoft の新機能なので管理センターで設定が必要	今回は管理画面の新機能ではなく、Windows のクラッシュ解析と互換性対応の事例
Explorer が落ちるなら Windows 本体の不具合	サードパーティ製シェル拡張が原因になることがある
DllCanUnloadNow を実装していれば安全	依存 DLL のワーカースレッドや非同期処理まで考慮しないと不十分
サポート切れ製品でも動いていれば問題ない	Explorer に読み込まれる拡張は、OS 全体の安定性に影響しやすい
Microsoft の互換性対応に任せればよい	特定製品向けの回避策であり、自社環境の旧ソフト放置を正当化するものではない

グローバル環境での実務対応

グローバル企業では、端末構成や導入アプリが国・地域ごとに異なることがあります。そのため、今回のような Explorer クラッシュ事例は、日本本社では再現しなくても、海外拠点や買収企業の端末で発生する可能性があります。

実務では、次の順序で進めると効率的です。

手順	実施内容	成果物
端末の棚卸し	インストール済み同期クライアント、ファイル管理ツール、シェル拡張を確認	古い拡張の一覧
クラッシュ傾向の確認	Explorer のクラッシュ件数、発生端末、発生操作を整理	影響端末の候補
ベンダーサポート確認	サポート期限、後継製品、Windows 対応状況を確認	更新・削除判断
パイロット更新	一部部門で新バージョンや代替方式を検証	互換性テスト結果
全社展開	標準イメージ、Intune、ソフトウェア配布で更新	残存リスクの低減
再発防止	新規導入アプリのシェル拡張有無を審査	導入チェック基準

この流れにすると、「Explorer が落ちる」という曖昧な問い合わせを、アプリ資産管理とサポートライフサイクルの問題として扱えるようになります。

まとめ：確認すべきは設定変更ではなく、古い拡張機能と DLL 設計

Microsoft の「The case of the thread executing from an unloaded third-party DLL」は、Windows Explorer のクラッシュから、サードパーティ製 DLL のアンロードとワーカースレッドの不整合を突き止めた事例です。管理者向けの新しい設定や移行期限が発表されたわけではありませんが、古いシェル拡張やサポート切れクライアントを放置すると、OS の安定性に影響することを示しています。

管理者は、まず Explorer に統合される古いアプリを棚卸しし、サポート中のバージョンへ更新する計画を立てるべきです。開発者は、DLL 内部で作成するスレッド、コールバック、タイマーが DLL の寿命を超えて動かないよう、参照カウントと終了処理を設計段階で確認してください。今回の更新ポイントは、「クラッシュした場所」ではなく「誰がまだ動いていたのに DLL をアンロードしたのか」を見る、という実務的な視点にあります。