連載
» 2014年11月04日 18時00分 UPDATE

山市良のうぃんどうず日記(18):Cドライブの容量不足は「WinSxS」フォルダーの肥大化が原因?

Cドライブの容量不足を解消する方法として、本連載第15回では「%Windir%\WinSxS」フォルダーのクリーンアップを取り上げました。その際のトラブルに関連して、「C:\Windows\System32\korwbrkr.lex」のファイルロックが「C:\Windows\WinSxS」フォルダーに影響する理由の説明を先延ばしにしましたが、今回の話でその理由が分かるでしょう。

[山市良,テクニカルライター]
「山市良のうぃんどうず日記」のインデックス

連載目次

安易にいじってはいけない!「WinSxS」フォルダーの正体とは?

 Windowsを長く使っていると、「%Windir%\WinSxS」(以下、WinSxS)フォルダーがどんどん肥大化していくように見えます。だからといって、WinSxSフォルダーの中で削除できそうなものを探して、削除してしまうことはトラブルの元です。

 今回は、WinSxSフォルダーの役割や仕組みを説明します。言葉で説明すると長くなるので、できるだけスクリーンショットを多用し、なんとなくでも分かっていただければと思います。WinSxSフォルダーについて詳しく知りたい方は、以下のMSDN(Microsoft Developer Network)のドキュメントをご覧ください。

 Windowsに標準ではインストールされない機能(Windows Serverの場合は「役割と機能」)を有効化する際、インストールメディアが要求されることはありません。機能の追加に必要なソースファイルは、「Windowsコンポーネントストア」と呼ばれるWinSxSフォルダーにあらかじめ配置されているからです。

 例えば、Windowsに「Telnetクライアント」(%Windir%\System32\Telnet.exe)は、標準ではインストールされません(画面1)。

画面1 画面1 「Telnetクライアント」(Telnet.exe)はオプションで有効化できる機能

 Telnetクライアントの機能を有効化する前は、当然のことながら「%Windir%\System32」(以下、System32)フォルダーにTelnet.exeは存在しません。しかし、WinSxSフォルダーの中を検索してみてください。Telnet.exeとその関連ファイルが見つかるはずです(画面2)。

画面2 画面2 有効化されていない「Telnetクライアント」のソースファイルは、WinSxSフォルダーの中に最初から存在する

機能の有効化はWinSxSフォルダー内のファイルへのハードリンク

 Telnetクライアントを有効化すると、System32フォルダーにTelnet.exeがインストールされます。一見すると、WinSxSフォルダー内のTelnet.exeがコピーされたように思えるかもしれませんが、そうではありません。System32フォルダー内のTelnet.exeは、WinSxSフォルダーにあるTelnet.exeそのものを参照するハードリンクなのです。

 ハードリンクとは、「一つのファイルに対する複数の参照(パス)」のことです。どのパスが本物、あるいはオリジナルということはなく、全てが同等のパスです。複数のハードリンクを持つファイルは、その一部の参照を削除しても、ファイルの存在には影響しません。参照数がゼロになって初めてディスク上から削除されます。ハードリンクのない通常のファイルは、そのパスが唯一のハードリンクともいえます。

 ハードリンクを参照できる「Windows Sysinternals」のユーティリティ、「FindLinks」を使って調べてみましょう。

 System32フォルダー内のTelnet.exeをFindLinksで調べると、もう一つのハードリンクとしてWinSxSフォルダー内のTelnet.exeへのリンクが示されます(画面3)。逆に、WinSxSフォルダー内のTelnet.exeをFindLinksで調べると、System32フォルダー内のTelnet.exeがもう一つのハードリンクとして示されます。

画面3 画面3 System32フォルダー内のTelnet.exeは、WinSxSフォルダー内のTelnet.exeと同じファイルを参照するハードリンク

Windows UpdateはWinSxSフォルダーを更新します

 Windows Updateは、例えばTelnet.exeに対する更新があったとすると、System32フォルダーのTelnet.exeではなく、WinSxSフォルダー内のTelnet.exeを更新し、ロールバックできるように古いバージョンのTelnet.exeも保持してバージョン管理をしています。そして、最新のTelnet.exeに対するハードリンクをSystem32フォルダーのTelnet.exeに設定するのです。

 Windows 8.1のTelnet.exeに対する更新はまだないので、「Explorer.exe」で確認してみましょう。WinSxSフォルダーの中を検索すると、ファイルサイズの異なる多数のExplorer.exeが見つかりました(画面4)。

画面4 画面4 Windows Updateで最新状態にしたWindows 8.1で、WinSxSフォルダーの中からExplorer.exeを検索したところ

 WindowsはWinSxSフォルダー内のファイルへのハードリンクを多用しているため、WinSxSフォルダーのサイズが、このフォルダーの実際のサイズを示しているわけではありません。サイズ計算には他の場所にあるファイルが含まれるなど複雑であり、実際よりも大きく見えてしまうそうです。

 しかしながら、古いバージョンを保持していることは、WinSxSフォルダーのサイズを大きくしている要因の一つではあります。だからといって、安易にWinSxSフォルダー内のファイルを削除してしまうと、バージョン管理の整合性がとれず、まずいことになるでしょう。

「ディスククリーンアップ」でクリーンアップ!

 WinSxSフォルダーのサイズを縮小する方法の一つが、「ディスククリーンアップ」(Cleanmgr.exe)を使用した「Windows Updateのクリーンアップ」です。これを実行すると、不要になった古いバージョンのファイルが削除または圧縮され、ディスク領域が解放されます。WinSxSフォルダー内でExplorer.exeを検索した結果は、実行前と実行後でファイル数に変化はありませんでした。更新プログラムのアンインストールに影響のない範囲でファイルを削除してくれるようです。

 先ほども言いましたが、WinSxSフォルダーのサイズは実際よりも大きく見えてしまうため、クリーンアップを実行しても思ったほど小さくならないと思います(画面5)。

画面5 画面5 「Windows Updateのクリーンアップ」を実行しても、WinSxSフォルダーのサイズに大きな変化がないのは、このフォルダーのサイズ計算方法の問題。ディスク全体では確かに減っている

「DISM」コマンドでもっとクリーンアップ!

 本連載第15回でも登場しましたが、Windows 8.1およびWindows Server 2012 R2からは、「DISM」コマンドによるWinSxSフォルダーのクリーンアップに「/ResetBase」という新しいオプションが追加され、さらなるサイズの縮小が可能になりました。

 「ディスククリーンアップ」による「Windows Updateのクリーンアップ」を実行した後に、「/ResetBase」付きでDISMコマンドによるクリーンアップを実行してみると、WinSxSフォルダー内のファイルとサイズに明らかに変化がありました。WinSxSフォルダー内のExplorer.exeを検索してみると、古いバージョンのファイルが削除されていることが分かります(画面6)。「/ResetBase」を実行すると、更新プログラムのアンインストールができなくなることが、この結果からも分かります。

画面6 画面6 WinSxSフォルダー内のExplorer.exeは最新バージョンだけになり、WinSxSフォルダー内のファイル数やサイズも大きく変化

.NET Framework 3.5はWinSxSフォルダーには存在しない?

 このように、Windowsの機能の有効化にはWinSxSフォルダーが使用されるのですが、例外もあります。その一つが、「.NET Framework 3.5(.NET 2.0および3.0を含む)」です。この機能については、既定ではWinSxSフォルダーにソースファイルがありません(画面7)。

画面7 画面7 「.NET Framework 3.5(.NET 2.0および3.0を含む)」を有効化する前のPC。WinSxSフォルダーに必要なソースファイルはまだ存在しない

 機能を有効化すると、Windows Updateから必要なソースファイルがダウンロードされるようになっています(画面8)。なお、.NET Framework 3.5のソースはインストールDVDの「\Sources\SxS」フォルダーにあり、この場所をソースとして使用することもできます。WindowsストアでWindows 8.1にアップグレードした場合はインストールDVDを持っていないでしょうから、その方法の説明は省略します。

画面8 画面8 「.NET Framework 3.5(.NET 2.0および3.0を含む)」を有効化済みのPC。WinSxSフォルダーにダウンロードされたソースが展開され、使用される

8月、9月のWindows Update後にトラブルに遭遇しませんでしたか?

 実は「.NET Framework 3.5(.NET 2.0および3.0を含む)」の有効化に関して、2014年8月と9月のセキュリティ更新プログラムが問題を引き起こしていました(画面9)。

画面9 画面9 2014年8月と9月のセキュリティ更新プログラムが原因で「.NET Framework 3.5(.NET 2.0および3.0を含む)」を有効化できないという不具合が発生した。10月の更新で解決済み

 「.NET Framework 3.5(.NET 2.0および3.0を含む)」を有効化しようとしない限り、この問題には遭遇しません。また、「.NET Framework 3.5(.NET 2.0および3.0を含む)」を有効化した後に、この更新プログラムを適用した場合は、何の問題もありません。

 この問題は、10月上旬にリリースされた修正プログラムですでに解消しています。そのため、問題に遭遇した人は少ないはずです。しかしながら、遭遇してしまった人は、理由が分からず面倒なことになったに違いありません。

 「.NET Framework 3.5(.NET 2.0および3.0を含む)」は、SQL Serverの前提コンポーネントです。前提コンポーネントの有効化が失敗すると、インストールを続行できません。

「山市良のうぃんどうず日記」バックナンバー

筆者紹介

山市 良(やまいち りょう)

岩手県花巻市在住。Microsoft MVP:Hyper-V(Oct 2008 - Sep 2014)。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。マイクロソフト製品、テクノロジを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手がける。個人ブログは『山市良のえぬなんとかわーるど』。


Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。