Windows

VMware Workstation Player 12 が起動しなくなった

Windows

ついこの間まで便利に使っていた VMware Workstation Player 12 が突然起動しなくなった。
Windows 10 version 2004での状況はこちら

広告


起動しようとすると以下のメッセージが表示されて起動しない。

VMware Workstation Pro は Windows で実行できません
Windows で実行するこのアプリの更新されたバージョンを確認してください
互換性アシスタント
更新プログラムの確認 – 無視

ここで表示されている「無視」はメッセージを無視するだけで、起動できないことは解決できなかった。

 

やること。最終的にはCompatibility Administratorを使用した管理対象の除外設定が決定打になった。コメント欄で教えていただきました、ありがとうございます。

 

Windows Update が原因

2019/10/20 追記
結果から見ると、恐らくWindows Updateで互換性データベースが更新され、VMware Workstation 12 Playerが非互換になったものと思われる。

Microsoftが一体どういうつもりなのか全く分からないが、Windows 10という同じバージョンを利用しているにもかかわらず、「累積更新」を適用するだけでアプリケーションは突然「非互換」扱いされ、起動すらできなくなるのだ。

対策後に起動して試してみた(Ubuntu18.04, Windows10Pro, WindowsServer 2016)けど、普通に起動して使えるようだった。

原因

9月30日まで記事を書いていて、問題なく起動ができていた記憶…その後にあったシステムへの変更と言えば…Windows Updateだ。

※関係ないところはぼかしてある。

2019-09 x64 ベース システム用 Windows 10 Version 1903 の累積更新プログラム(KB4524147)
2019/10/02 に正しくインストールされました

2019-09 x64 ベース システム用 Windows 10 Version 1903 の累積更新プログラム(KB4517211)
2019/10/02 に正しくインストールされました

2019-09 .NET Framework 3.5 および 4.8 の累積的な更新プログラム(x64 向け Windows 10 Version 1903用)(KB4522738)
2019/10/01 に正しくインストールされました

 

今回、VMware Workstation Playerが起動しなくなった原因は KB4517211 だった。

昨日からほぼ丸1日この情報を探したり試したりしていたが、ようやくGoogle先生の検索に以下のページが引っかかった。
Windows 10 Forums / “VMware Workstation Pro can’t run on Windows” Message

VMware Workstation Pro can’t run on Windows
Check for an updated version of this app that runs on Windows.
Compatibility Assistant
Check for updates – Dismiss

同じ問題が発生していて、設定を復元すれば戻ると書いてある。
2019/10/04 01:22 の投稿で、タイミングもドンピシャ、これだ…

対処(Compatibility Administrator) 2019/10/20追記

コメント欄で教えていただいた互換性問題の解決方法。
Windows ADKに含まれるCompatibility Administratorを使って、互換性チェック対象から外す。前回見つけたページの先の方に答えがあるよ、というお話だった。
Windows 10 Forums / “VMware Workstation Pro can’t run on Windows” Message

そもそもADKって何?

Windows アセスメント & デプロイメント キット (Windows ADK) には、Windows イメージを大規模な展開向けにカスタマイズしたり、システム、追加コンポーネント、システムで実行されるアプリケーションの品質やパフォーマンスをテストしたりするために必要なツールが含まれています。

ということで、Windows 10 version 1903な今、1903用のインストーラーをダウンロードする。
Microsoft / Windows ADK のダウンロードとインストール

旧バージョンのWindows ADKアンインストール

adksetup.exeを起動したところ、以下が表示された。

既にインストールされているのか?これ??と思って確認したら、確かにインストールされてる。何でか分からないけど、今日だなぁ…

アンインストールして、再度adksetup.exeを実行。

Windows ADKのインストール

改めて実行したところ、場所の指定になった。個別でインストールする必要はないのでコンピューターにインストールすることにした。

プライバシーについてはどっちを選んでも問題ないだろうと思われる。

ライセンス条項に同意する。

インストールする機能の中で「アプリケーション互換性ツール」を選択する。デフォルトではチェックされていないので注意。
インストールボタンをクリックしてインストールを開始する。

待つ。

インストールを終了する。

 

Compatibility Administrator (32-bit)による管理対象の除外

Compatibility Administrator (32-bit)を起動する。Windows Kitsに入っている。

System Database (32-bit) → Applications → VMware Workstation Pro を選択する。

vmplayer.exe と vmware.exe を無効化する。右クリックで出てくるポップアップでDisableを選択すると無効化できる。

2つとも無効にしたら、アプリケーションを終了する。

これで、VMware Workstation 12 Player が起動するようになった。

 

対処(Windows Updateのアンインストール)

復元ポイントで容量を食って困っていたので止めちゃった記憶(実際には10GBくらい用意していて、問題の日まで遡ることはできていた…)があったので不安になったけど幾つか保管されていたので、Windows Updateをアンインストールした。

設定 → 更新とセキュリティ → Windows Update → 更新の履歴を表示する とクリックしていくと、更新プログラムをアンインストールする のリンクが現れる。

このリンクをクリックすると インストールされた更新プログラム が開く。

インストール日で並べ直して
 KB4524147 → アンインストールして再起動
 KB4517211 → アンインストールして再起動
を実行する(最初は4517211は表示されず、4521417をアンインストールしたら4517211が表示された)。

インストール日が表示されない時には、名前・更新日時といった見出しのあたりを右クリックしてポップアップメッセージを表示させ、インストール日にチェックを入れれば表示されるようになる。

Windows Updateをアンインストールした結果、どうにか起動するようになった。
いつのタイミングで更新プログラムがインストールできるようになるのか分からないが、当面はWindows Updateしないことにする。

 

やったこと

互換性アシスタント関連で見つかるトラブルシューティングがことごとく失敗した。仮想マシンというかなり特殊なアプリケーションだから仕方がないのかもしれないが、ちょっとうっとうしい出来事だった。

インストーラーを使った修復(失敗)

同じバージョンのVMware Playerのインストーラーを起動し、修復してみる。
旧バージョンのダウンロードページはここで教えてくれた。
備忘録 / vmware Workstation Player の旧バージョンのあるところ

説明を読んで次へ。

修復をクリックする。

もう一度修復をクリックする。

修復され…完了ボタンをクリック。

再起動を求められるので、再起動する。

再起動後にVMware Playerを起動する…駄目だった。

アンインストール→インストールを行っても駄目だった。

 

最新バージョンをインストールする(失敗)

この通知の更新プログラムの確認をクリックしたところ、ダウンロードページ(2019/10/05時点)が表示された。個人利用なのでライセンス的には問題なさそうと判断してダウンロードしてインストールしようとしたら、以下のメッセージが表示された。

VMware 製品のインストール

サポートされていない CPU が検出されました。

ホスト CPUは必要なハードウェア要件をサポートしていません。

[終了]をクリックしてインストールを停止してください。
インストールを続行すると、このホスト上で仮想マシンを起動できない可能性があります。
詳細については、次のナレッジベースの記事を参照してください。

これはインストールするとトラブルが拡大する予感。

念のため、今使っているPCのCPUを調べた。
バージョン情報で見ることができる。

intel core i5 750 で検索してみたところ、インテル® Core™ i5-750 プロセッサー のページがすぐに見つかった。開発コードはLynnfield、発売日はQ3’09と書かれている。VMware Playerはバージョン14の時点で2011年以降のCPUを要求しているので、2009年のじゃ古すぎることが分かっただけだった。

 

互換性のトラブルシューティング ツールを実行(失敗)

これで動作するようならスマートな気がする。
Microsoft Support / 以前のアプリまたはプログラムを Windows 10 で使用する

スタートメニューでVMware Playerを右クリックしてファイルの場所を開く。

VMware Playerを右クリックし、ファイルの場所を開く。

vmplayer.exeを右クリックして互換性のトラブルシューティングを起動する。

推奨設定を使用する をクリックする。

プログラムのテスト をクリックしてテストする。

しかし、テストしても起動しなかった。

レポートを表示させたが、何の役にも立たない情報しか表示されない。

こりゃ駄目だ。

 

互換性アシスタントからプログラムを除外(失敗)

互換性アシスタントは動かしつつ、該当のプログラムを除外すれば起動できるかもしれない。ここに気になる記述を見つけた。
Microsoft TechNet / プログラム互換性アシスタントの無効設定

どうやら、レジストリに無効化するプログラムを登録すればいいみたい。

■位置
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant
■キー
ExecutablesToExclude

 

ここにフルパスのリストを追加する、とされていたので、
C:\Program Files (x86)\VMware\VMware Player\vmplayer.exe
を追加してみた。

起動しない。

 

互換性アシスタントを無効化(サービスの停止/失敗)

あんまりやりたくないけれど、互換性アシスタントそのものを無効化すれば起動するかもしれない。

どうやらこれを実現しているであろうサービスを発見。
Program Compatibility Assistant Serviceを停止してみる。

でも、すぐに起動してくる。

そういうサービスならば…停止して無効化、VMware Player起動…だめだ。

ならば再起動してみたらどうだろう?

駄目だ…。

 

互換性アシスタントを無効化(ポリシーで無効化/失敗)

Windows10サポート / Windows10でプログラム互換性アシスタントを無効にする方法

このPCはWindows 10 Proffesionalが動作している。
スタートメニューを表示した状態で group と入力すると、グループ ポリシーの編集が表示される。クリックすると、グループポリシーエディタが起動する。

 

コンピュータの構成 ⇒ 管理用テンプレート ⇒ Windowsコンポーネント ⇒ アプリケーションの互換性
プログラム互換性アシスタントを終了する

ポリシーを変更後起動したが駄目。

再起動して起動してみたら…

駄目だ…。

 

Hyper-Vの有効化(失敗)

起動できない問題を探しまくってみたところ、こんなページが見つかった。
VMTN / VMWare Workstation cannot run on Windows 10 after recent update to Windows 10

Hyper-Vが有効になっているとVMware Playerは起動できないことがあるらしい。

コア分離→メモリの整合性 が話題になっていたけれど、このPCはオフだった。

オフになっているものの、何か影響があるのかもしれないとオンにしてみた。

 

有効化すると再起動を求められるので、再起動。

VMware Playerを起動したが…駄目だった。

オフに戻して再起動、やっぱり駄目だった。

 

DistributedCOM 10016 の解消(失敗)

2019/10/20 追記
この操作を実行すると、Windows Update後に重大なエラー(スタートメニューが動作していません)が発生する可能性があります。回復方法は記事にしましたが、危ない操作なので、実行する場合には十分な注意が必要です。

2019/11/05 追記
スタートメニューが動作しない問題は、アップデートにバグがあったからかもしれません。とはいえ危険であることには変わりなく、十分な注意が必要です。

DCOM 10016の問題の具体的な解決方法について触れているページに初めて出会った。
Windows OSHub / DistributedCOM Error 10016 in Windows: The Application-specific Permission Settings do not Grant Local Activation Permission

マイクロソフトのページで仕様通りであり無視して大丈夫というのを見かけたが、今回、ウチのマシンでは新バージョンを動かせないので、この問題を回避するためのシナリオを用意できないので、問題を解決しなければ…と考えた。

発生している問題

VMware Playerが起動に失敗したとき、以下のイベントが記録されることに気付いた。

コンピューターの既定 のアクセス許可の設定では、CLSID 
{C2F03A33-21F5-47FA-B4BB-156362A2F239}
および APPID
{316CDED5-E4AE-4B15-9113-7055D84DCC97}
の COM サーバー アプリケーションに対するローカルアクティブ化のアクセス許可を、
アプリケーション コンテナー Microsoft.Windows.ShellExperienceHost_10.0.18362.387_neutral_neutral_cw5n1h2txyewy
SID (S-1-15-2-xxxxxxxxx-xxxxxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx) で
実行中のアドレス LocalHost (LRPC 使用) のユーザー
MainPC\rohhie SID (S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx) に与えることはできません。
このセキュリティ アクセス許可は、コンポーネント サービス管理ツールを使って変更できます。

※適当なところで改行しているけれど、実際は1行で表現されていた。
※ホスト名・ユーザー名はマスクしている。ログインしているユーザー名が表示されている。

コンポーネントサービス管理ツールで変更できるとあるけれど、これって何だっけ?と探していたら以下のページを見つけた。この問題の原因を突き止める手法が書かれている。
T&N リサーシャ / Windows 10の イベントID 10016 を解消する方法

そういうスナップショットがあるのね…
スタート → Windows 管理ツール → コンポーネント サービス

起動してDCOM の構成にアクセスしたら、以下のメッセージが表示された。

DCOM 構成の警告

CLSID {c82192ee-6cb5-4bc0-9ef0-fb818773790a}、項目 C:\WINDOWS\System32\rundll32.exe、およびタイトル JumpViewExecuteHelper は、名前付き値 AppID を持っていますが、\\HKEY_CLASSES_ROOT\AppId の下に登録されていません。登録しますか?

この件について探していると、以下のページが見つかった。登録しておいた方が良さそうなので「はい」をクリックした。
Scrap 2nd. / Windows 10 May 2019 アップデート直後はコンポーネントサービスを起動して「DCOMの構成」にアクセスしよう|DCOMエラーを修復する前に

ここから考えていくと、アップデートによってDCOM構成の何かが壊れ、それが理由で起動できなくなっているのではないかとも思われた。

コンポーネント名の確認

レジストリエディタでCLSIDが示すコンポーネントの名前を検索したところ、以下のキーがヒットした。

\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{c2f03a33-21f5-47fa-b4bb-156362a2f239}

値とデータは以下のものだった。
(規定) = Immersive Shell
AppID = {316cded5-e4ae-4b15-9113-7055d84dcc97}

これで問題となっているコンポーネントの情報がそろった。

CLSIDのキーにアクセス権限を付与

レジストリエディタで
\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{c2f03a33-21f5-47fa-b4bb-156362a2f239}
を選択し、アクセス許可を変更する。

今回VMware Playerを起動しようとしているユーザーはAdministratorsグループに所属している。

Administratorsにフルアクセス権限を付けようとしたが…

適用ボタンをクリックしたところでエラーが発生。
所有者を変えてアクセス権を変えられるようにする必要があった。

詳細設定をクリックし、所有者の右にある 変更 リンクをクリックする。

所有者には現在この操作をしているユーザーを指定した。マスクしてます…。

サブコンテナーとオブジェクトの所有者を置き換える にチェックを入れる。
また、Administrators にフルコントロールを与えようとしていることを確認する。
そしてOKする。

APPIDのキーにアクセス権限を付与

APPIDのキーのも同様にアクセス権を付与する。

レジストリエディタで
\HKEY_CLASSES_ROOT\AppID\{316CDED5-E4AE-4B15-9113-7055D84DCC97}
を選択し、アクセス許可を変更する。

後はCLSIDと同じ方法でアクセス権を付与する。

DistributedCOMのアクセス権を修正する

もしコンポーネント サービスを開いていたら一旦閉じて、再度コンポーネント サービスを起動する。

コンソールルート → コンポーネントサービス → マイ コンピューター → DCOM の構成 をクリックする。表示される多数のアイテムから Immersive Shell を選択し、プロパティを表示させる。

今回表示されていたメッセージは…

COM サーバー アプリケーションに対するローカルアクティブ化のアクセス許可を、

実行中のアドレス LocalHost (LRPC 使用) のユーザー
MainPC\rohhie SID (S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx) に与えることはできません。

 

だったので、起動とアクティブ化のアクセス許可 について、カスタマイズを選択して編集ボタンをクリックする。

だが、確認してみたところ、Administrators には既にフルアクセス権限が付いていた。

嫌な予感がする…。

今までの操作で権限が付いたのか、そうじゃないのかは分からない。それは何故かというと、CLSIDとAPPIDにアクセス権を付けるまでこの編集ができなかったから。

だが、今回は権限は付いていた。

キャンセルして、PCを再起動する。

VMware Playerを起動…駄目だった。

なお、このDCOMの設定変更はPCを再起動せずとも反映はされている模様。都度都度再起動せずともテストはできるはずだが、心配なら再起動する程度でいいと思う。

実行ユーザーの変更

もう少し何か情報はないかと探していると、IDタブで実行ユーザーの変更をすることに言及されていた。
Microsoft TechNet / Can’t fix Event 10016, DistributedCOM

結果どうなったかというと…

VMware Playerは起動できない。が、右下から音を鳴らしながらスライドして出てくる通知が表示されなくなる。アクションセンター([Windows]+[a])には通知がたまっていく。

という動作になった…駄目だった。

結局、今回取り組んだDistributedCOM 10016(今回の場合は、Immersive Shellの問題)はVMware Playerの起動そのものには影響がないことが分かっただけだった。

 

さいごに

日頃何気なくWindows Updateを適用している。勝手にアップデートされて再起動までされちゃうのが嫌なだけで、アップデートそのものは信用しているのだ。

今回はたまたま問題が発生し、ちょっと、いやけっこう、ん~やっぱりかなり大変な目に遭ったもののモノがモノだけに仕方がないのかもしれないな…って思っている。

Windows Updateのアンインストールなんてめったにやらないことなので、ホントにちゃんとできるの?なんて思ったけれども、ちゃんとできていて良い意味でびっくり。もしかしたらHyper-Vで構築し直しなのかな…と思っちゃっていたので、本当に良かった。

後は、この問題が解消されるまで累積アップデートを適用できないから、しばらくの間はアップデートの情報をウォッチしていこう。

2019/10/20 追記
この問題はきっと解消されることはない、何故なら何らかの事情でVMware Workstation 12 Playerは非互換と判断されたのだから。

このPCの寿命が近づいてきたのかもしれない…。

 

広告
ろっひー

コメントはこちらから お気軽にどうぞ ~ 投稿に関するご意見・感想・他

  1. Rukoto より:

    同じ core i5 750 使いとして助言せずにはいられない…。
    本問題に対する最も最適な解決方法は以下の投稿を参考になると思います。
    この方法であれば特定のアプリ(今回はVMware)だけ互換性チェックを回避できます。
    https://www.tenforums.com/virtualization/141820-vmware-workstation-pro-cant-run-windows-message-3.html#post1740491

    ちなみに Windows 10 1909 に更新する場合や特定の Hotfix をインストールする場合にも、
    VMware 12 系は互換性の問題があるとして一旦アンインストールする必要がでてきます。
    (1909への更新については実体験済みなので間違いないです)

    今後も Lynnfield ちゃんには厳しい試練が待ち受けている気がしますけど、
    私はまだまだ頑張れると信じてますよ!グッドラック!

  2. rohhie より:

    ご助言ありがとうございます。

    実は、Windows Updateで累積更新を適用すると「重大なエラー」が発生する状態になっていたので、本格対処を後回しにしていましたが、コメントをいただきましたのでその気になりまして、本格対処が実施できました。今は、更新を全て適用した状態でVMware Playerが動作しています。

    非互換のアプリケーションがあると機能アップデート(大型更新?)が中断されるようになったのはいつ頃からだったか(1803頃には実装されていた気がしますが)、非互換データーベースがどんどん大きくなっているんですね。Windows7からのアプデート(悪戦苦闘編)で記事にしたアレがこういう形でブーメランになって返ってきたか、と苦笑しております。

    そして、その互換性データーベースに非互換と登録されてしまった以上、1909で体験された「アンインストール必須の状態」は必然なんだと理解できました。

    今回問題となったこのPCは10年以上使っていますが、HDDをSSDに換装したことで快適に使えています。まだまだこのまま使っていきたいと思っていますが、Ubuntuなら飛ぶように動くしなぁ、そろそろ新しいのも欲しいしなぁ、と、気持ちがフラフラしています。

    機会がありましたらお気軽にコメントいただけましたら幸いです。
    ありがとうございました。

  3. kakey より:

    同じくVMware Player 12を使用していて朝立ち上げたところこの問題にぶち当たった者です
    私の場合仕方ないのでver.15に更新しようかと思えたので、データが引き継がれることを確認して15に更新して問題は解決しました
    他にもフットワークが軽いとは言えないソフトが多くあるので、もしもの時はWindows ADKからの解決方法を参考にさせていただきます

  4. rohhie より:

    コメントありがとうございます。

    職場でもVMware Workstation Playerのバージョンアップで対応したという話を聞きました。安定稼働を考えるとこれが一番良い対処方法なんだろうと思います。

    今回の記事はCPUが古いのでバージョンアップで対応できない…っていう切羽詰まったところからの深追いでして、これってきっと世の中的には少数派なんだろうなぁと思っています。

    予算が許せば新機種に移行していきたい、しかしまだまだ遠い道のりになると思います。SSDに換装したらもう超快適なので、ろっひー以外の家族はこの環境を1mmも問題視していないのです。

    実は今、UbuntuでVMware Workstation 12 Playerを動かすための試行錯誤をしています。上手くいかないかもしれない気配濃厚、でも、もし上手く動いたら(家族の中で)ろっひー1人だけ移行していこうと思っています、実は普段使いにしても悪くない環境なのです…。

  5. へるるん より:

    1909のサポート期限があと1月ちょっとに迫ってきたので
    なぜ自動で落ちてこないのかなあと思いながらも20H2にアップデートしようと
    したところVMwareが非互換なのでアップデートできないといわれました。
    自分のところもCPUの問題でVMwareを12より上にはできないため非常に
    困っています。
    一旦アンインストールしてWindowsをアップデート後、Windows ADKで
    互換性チェック回避後再インストールってことになるんでしょうかねぇ・・・
    めんどくせえ

    • rohhie より:

      コメントいただきありがとうございます。

      ウチは確か2004は自動で落ちてきた記憶(あまりはっきりした記憶でもないのですが)で、そのタイミングは何か装着していたハードウェアが不具合を起こす問題が解消されたときだったと思います(Microsoftのどこかアップデートに関連するページに、既知の問題とかって書かれていたものが解消された)。
      このパターンのアップデートだと、互換性のデーターベースが有効なんだなぁとボンヤリ意識していました。

      再度インストールする時のめんどくささはホントそうですよね。こんなペナルティを受けなきゃならない程の悪いことなのかなぁとか思います。良いものをそろえて長く使うというのが許されない世界…

      昨年突然思い立ち(我慢ができなくなり、が正しいかもしれません)、PCを組んで使用中のSSDをそちらに換装、その後にVMwareのバージョンアップしてしまいました。

      旧PCは、現在24時間稼働のサーバーになっています。まだまだ頑張ってます。

      そして、旧24時間稼働サーバーをHDDからSSD128GBに換装、Windows10を買ってきてクリーンインストールした上で居間のテレビに接続し、動画鑑賞用に使っています。メモリが8GBあるので、この程度であれば全然ストレスなく使えます。

      玉突き配置で満足しているものの、まぁまぁ出費の出費ではありました。