風が吹くと桶屋が儲かる。
現象
- jpgのサムネイルは出るが、pngとbmpのサムネイルが出ない。
- あくまで自分の環境における例で、jpgも含めた3つ全部が失敗するケースも多いだろう。
- 私のPCはレジストリの画像ファイル種別まわりをモンキーにいじっているのでjpgだけ定義が分かれている。拡張子ごとの挙動の違いはそのせい。
 |
| jpgしかサムネイルが出ない |
- サムネイルキャッシュを削除しても再起動しても改善効果なし。
- 画像ファイルが壊れているわけではない。なんならpngのファイル名だけをいじって拡張子jpgにするとサムネイルが出る。どうも拡張子ごとのサムネイルハンドラー設定がおかしそう。
- GoogleDriveを終了した状態でレジストリ編集すると一時的にサムネイルが復活する。
- 方法だが、{E357FCCD-A995-4576-B01F-234630154E96} のシェル拡張のキーを削除する。
- 環境によって異なるのであくまで一例だが、pngであれば HKCR\.png\shellex\{E357FCCD-A995-4576-B01F-234630154E96} などが削除対象となる。
- ただGoogleDriveを再起動すると上記レジストリキーは復活し、またサムネイル生成が失敗するようになる。
発生メカニズム
Windows版GoogleDriveは、画像サムネイル生成の機能を持っている
- これは事実。なぜなら shellex\{E357FCCD-A995-4576-B01F-234630154E96} がGoogleDrive内部のdllを指しているサムネイルハンドラーであるから。
- なぜこんな機能があるのか？ については「GoogleDriveのストリーミングフォルダ上に画像ファイルがあるときは、通常ファイル扱いでサムネイルを作ることができず、サーバーからfetchして表示するようなGoogleDrive独自の処理が必要になるから」とかが理由じゃねと予想している。
- クラウド上のファイルをローカルにあるように見せる仮想ファイルシステムだから、それ自体は自然。
- こいつは、GoogleDriveと無関係のフォルダにおいては、Explorer標準のサムネイル生成を単に呼び出すだけのラッパーになっていると考えるのが自然だ（これは予想）。
- GoogleDrive側のサムネイル生成機能がまるごと死んでいる場合、ラップされているExplorerの標準サムネイル生成がそもそも呼ばれないので、サムネイル自体が一切出ないことになるのだろう（これも予想）。
- 冒頭でレジストリキーを削除しているが、これは「独自のサムネイルハンドラーをやめてExplorer標準のサムネイル生成に任せる」設定に相当する。
GoogleDriveクライアントのアップデートに失敗したことで、サムネイルハンドラーが無効なパスを指していた
手元で観測した事実は以下の通り。
- レジストリのサムネイルハンドラーGUIDを辿っていくと、x64の場合は実パス C:\Program Files\Google\Drive File Stream\133.0.2.0\drivefsext.dll を指していた。
- HKLM\SOFTWARE\Classes\CLSID\{8AD5CECD-DF0D-41C3-BA21-1E22114CC73C}\InProcServer32 を見ると書いてある。
- しかしそのようなパスに実体ファイルは存在していない（ゆえにサムネイル生成もできない）。
- このとき実際に動いていたGoogleDriveのプログラムは132.0.0.0で、レジストリに記載の133.0.2.0よりも古かった。実体の方のアップデートに失敗している状態である。
- つまりアップデートが中途半端に実行されてしまったことで（そして適切にロールバックもされなかったため）、レジストリの参照と実体の間で不整合が起き、サムネイル生成できない状態になっていた。こういう操作はAtomicにしておけと古事記にも書いてある。サンシタめ。
- というかWindows標準のMSIインストーラーを使えばいいのにな。自前実装するなら責任持って作りきってほしい。
- 冒頭、削除したレジストリキーがGoogleDriveの再起動で復活すると書いたが、試したところGoogleDriveは動作中サムネイルハンドラーのレジストリキーを常時修正しつづけているようだった。
- ちょっと偏執的だよね、というのと、どうもiTunesに似たパターナリズム思想みたいなのが見え隠れする。
解決方法
アップデート自体の失敗理由はレジストリの書き込みエラーらしい
判断の根拠は以下：
- アップデートが失敗するので、一度GoogleDriveをアンイストールしてから真っ更なインストールを試みた。
- しかし再インストールで必ず失敗する。
- インストール時のログが %TEMP%\GoogleDFSSetup_261107060834_26916.log みたいな名前で出来ている。最新のものを読んでみるとレジストリ書き込み失敗ログが出ていた。
// 失敗ログの例
2026-11-07T06:06:15 E util.cc(479): Could not set registry value Software\Classes\Directory\shellex\ContextMenuHandlers\DriveFS 28 or later,: 5
// 成功ログの例
2026-11-07T06:08:36 I install.cc(210): Set registry key successfully: Software\Classes\Directory\shellex\ContextMenuHandlers\DriveFS 28 or later, , {EE15C2BD-CECB-49F8-A113-CA1BFC528F5B}
- よくシェル拡張無効化のために雑にレジストリをいじったりしていたので、それの副作用ということだと思われる。
インストールを復旧させ、サムネイルも正常に戻った
- インストーラーが書き込みを試みて失敗していたキーは4つあった。すべて HKCU\Software\Classes\ 下の
- *\shellex\ContextMenuHandlers\DriveFS 28 or later\{EE15C2BD-CECB-49F8-A113-CA1BFC528F5B}
- lnkfile\shellex\ContextMenuHandlers\DriveFS 28 or later\{EE15C2BD-CECB-49F8-A113-CA1BFC528F5B}
- Directory\shellex\ContextMenuHandlers\DriveFS 28 or later\{EE15C2BD-CECB-49F8-A113-CA1BFC528F5B}
- Directory\Background\shellex\ContextMenuHandlers\DriveFS 28 or later\{EE15C2BD-CECB-49F8-A113-CA1BFC528F5B}
- 1つ直す → インストール試す → 失敗したらログを読んで次を直す の繰り返しで、4回目に成功した。
- 直し方は色々。親キーのパーミッションや所有者を周辺のキーに合わせてみたり、中身空っぽの {EE15C2BD-CECB-49F8-A113-CA1BFC528F5B} を消してみたりとか。
- 再インストール成功後は正しいdllが配置されレジストリとの不整合が解消したようで、サムネイル生成も正常に戻った。
 |
| 正常化してトリニティ顔になった |
コメント