
先月末から今月初めにかけて緊急配信となった累積的な更新プログラムですが、このプログラムによって、一部のVMware Workstation Proが使用できなくなったといった問題が世界中で発生しています。
(続報・回避方法が分かりましたので再掲載いたします)
(続報・回避方法が分かりましたので再掲載いたします)
このVMwareは、1台のコンピューター上で、複数OSの実行を可能とする仮想マシンのソフトウェア
で、特にITなど開発関係でプログラムの最終動作確認などを行う際に使用されています。
今回問題となったのは古いVMwareを使用しているユーザーで、更新プログラムが配信された週末以降、このWindows 10の累積的な更新によりVMware Workstationの起動が妨げられ、VMware Workstationが実行されなくなったと苦情が世界中で起こりました。
この問題は、VMware Workstationの古いバージョンのみが影響を受けておりますが、この問題を回避するために、アップグレードの支払いを希望方法もあります。しかし、同時に他の互換性の問題に直面する可能性があります。
今回原因となっている累積プログラムはKB4517211のようで、Windows 10をアップグレードして18362.387をビルドします。 ナレッジベースには記載されていませんが、このアップデートによりWindows互換性データベースにエントリが追加され、結果としてVMware Workstation 14以下を実行しようとすると「VMware Workstation Proは実行できません」というメッセージが表示されてしまいます。
当然、この問題についてMicrosoftのサイトのスレッドで訴える人もおり、その中の一人は100台のVMware Workstationライセンスをアップグレードすると11,500ユーロかかると言っております。
また他の問題もあり、 ネットワークソフトウェアGNS3を実行しようとしたユーザーは、アップグレード後にソフトウェアが機能しなくなったことを発見しました。 さらに、VMwareの新しいバージョンは一部の古いプロセッサでは動作しないため、アップグレードが常に可能とは限りません。
Windowsは、この種の互換性情報をsysmain.sdbと呼ばれるShimデータベースに保持します。 これはアプリケーション互換性フレームワークの一部であり、オンザフライでアプリケーションにパッチを当てたり、互換性の問題をユーザーに通知したりできます。
当然、一部の絶望的な状況になってしまったユーザーは、このファイルを古いバージョンに置き換えて、ブロックされたアプリケーションを実行しようとしました。ただし、これはシステムコンポーネントであり、それをいじると他のアプリケーションやシステムの安定性に予測できない影響を与える可能性があるため、これは適切な戦略ではありません。 さらに、sysmain.sdbのアクセス許可を緩和すると、セキュリティの脆弱性になる可能性があります。
とはいえ、これを行った一部のユーザーは、VMware 14が動作することをその後報告し、Microsoftがそれをブロックすることを選択した理由について困惑させていました。 もう一方の解決策として、今回問題となっているKB4517211の更新をブロックするという方法ですが、この更新プログラムをブロックすると、その後の更新で問題が再発する可能性が高いようです。
そのため、更新をブロックする方法は、Windows 10をセキュリティの問題に対して脆弱となる状況になり、長期的な戦略としては適していない方法となります。
ほとんどの古いアプリケーションがWindows 10で正常に実行されますが、ハイパーバイザーなどの低レベルのアプリケーションでは、問題が発生する可能性が高く、この種の問題が発生しやすくなります。 必要なのはそうなった場合を想定し、なるべる使用しているアプリのバージョンを最新のものに定期的に置き換えるということが一番の解決策になってきます。
続報:
この件に関しての回避方法が分かりました。とても簡単なことです。
C:\Program Files (x86)\VMware\VMware Workstation\のフォルダにある
vmware.exe
というvmwareの本体実行ファイルの名前を
vmwarea.exe
というように「a」という文字を一つ追加するだけでOKです。(aでなくても良いです)
つまり、ファイル名を変えるだけでWindowsのブロックをバイパスすることが出来ます。
コメント
コメント一覧 (2)