Windows の git bash で git add できないのでハマってしまった。表題のエラーが出るのだが何のことやら、ファイルにはアクセスできるし、メッセージでググっても良く分からない。考えられることを試し尽くして、新しいテキストファイル１個だけのリポジトリにしたにもかかわらず、解消に至りません。

結論から言うと Windows アップデートが原因でした。再起動しようと思ったら、電源アイコンにオレンジのぽっちが付いていたので、再起動待ちになっていたようです。この自動アップデート、本当に腹が立ちます。バックグラウンドで勝手にアップデートしていて、不具合が起こらないようにやってくれるなら分かりますが、それが出来ないなら更新前にユーザーに確認すべきです。前にも同じようなことがありましたが、Windows10 って本当にクソだなって思います。

まとめ

• git add をしようとしても "fatal: fsync error on 'loose object file': bad file descriptor" のエラーが出る
• リポジトリはネットワークディレクトリ上にある（ファイルサーバーの共有フォルダをネットワークドライブにマウント）
• ネットワークドライブからは問題無くアクセスできる
• エクスプローラから "\\server" のホスト名でアクセスできない（再起動直前に気づいた）
• エクスプローラから "\\<IPアドレス>" だとアクセスできる
• "ping <ホスト名>" はエラー、"ping <IPアドレス>" は IPv6 で返って来る
• ちなみにネットワークドライブ自体は、ホスト名で登録していて問題無くアクセス出来る
• Windows アップデートが再起動待ちになっていた
• 再起動後はネットワークアクセスも、git add も問題解消していた

教訓

Windows で問題が起きたら、あれこれ試す前に再起動すべし。

アップデート後、エクスプローラやファイル転送で問題が発生しています。同様の問題は最近の月例更新で発生していたため、７月頃からアップデートの度にロールバックして運用していました。あっちが良くなればこっちがダメ、本当にもういい加減にして欲しい。

• ネットワークドライブの反応が激重になる
• ディレクトリの表示、ファイルのリネーム、その他エクスプローラの動作が重い
• ファイル転送が途中でしばらく止まる、終了直前99%で止まる（スクショの状態）

移動に３日ぐらいかけて大量のファイルを移動させたら、残りゼロのまま１時間以上処理が終わりませんでした（何してるのか不明だが待てば終わる）。少ない量でもゼロになってから少し待たされると思いますが、ファイルの転送量に比例してこの後処理の時間は長くなるように思います。

それにしても「残り５秒」とかトラブってるのかそうで無いのか判断に困る、こういう表示が不安になるんですよマイクロソフトさん。あと転送速度も 1.37GB/s とかあり得ない表示になってるし、転送中も「残り２日以上」「残り17時間」などと行ったり来たり、当てにならない表示はするくせに「今どのディレクトリを作業しているのか」といった必要な情報は表示してくれないんですよね。

あと、処理開始前にファイル数カウントアップするの止めてもらえませんかね。数十万～百万ファイルもあると、それだけで１時間とか平気で待たされてしまいます、Windows 最悪です。

先月か今月（2019年9月）のマンスリーアップデートは他の不具合でロールバックして適用していないのだけども、問題が無かった環境でもタスクスケジューラで不具合を発見して、もう最悪なんですけど...。ひとつは実行ユーザーの設定の問題、もうひとつは subst と組み合わせた際の問題、いずれも対処可能です。

実行ユーザの設定でコンピュータ名を必ず聞かれる

ログインしていなくても実行される設定では実行ユーザを設定すると思いますが、このようなタスクはユーザを変更しなくても、もう一度入力しないと適用できません。恐らく「コンピュータ名￥ユーザ名」と復元すべきところを「ユーザ名」としたバグではないかと思います。前の状態がどうだったかは知りませんが、少なくともユーザ名を変更しないときは再入力を求められることは無かったと思います。

subst で仮想ドライブ化したディレクトリにアクセスできない

subst コマンドで仮想ドライブ化したドライブに置いたプログラムを実行できなくなりました。「ディレクトリが見つかりません」となります。

そもそも Windows10 ではコマンド実行による subst はできなくなりました。しかし「Windows 10で「subst」コマンドは使えない? 」の記事にあるようにレジストリを設定して回避可能です。この記事では、２つの方法が紹介されていますが、１番目の方法ではタスクスケジューラで前述のエラーになります。今のところ、２番目の方法ではタスクスケジューラでの動作も問題ありません。

追記

上の参照記事、間違っているのでご注意ください。subst を一般権限で実行すれば何の問題も起こりません。

Windows10 20H2 にアップデートしたところ、レジストリ（HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices）に追加した設定がなぜか消えて、再起動したらアクセスできなくなりました。

先月の Windows Update では、仮想マシンにリモートデスクトップ出来なくなり、今月のは NAS とのファイル転送がおかしい。NAS のファイルを移動しようとしたら途中でフリーズし、キャンセルも何も効かなくなった。explorer を強制終了させ、[新しいタスクの実行]から再起動してみたが、ファイルの操作が異常に重たい。フォルダも数分待たないと開かない。PC 自体を再起動させ、もう一度ファイル移動させるが、すぐにまた重くなる。フォルダの表示、ファイルのリネーム、その他すべての動作が重い、重い、重い！！

この記事書き始める前にリネームしたのに、今もまだ処理が終了してない。タスクマネージャーで見ると、エクスプローラーが２つ「応答なし」になっている。今ようやくリネーム処理が終わったが、もう１個のフォルダ表示は緑のプログレスバーが止まってる（１０個くらいしかファイル無いのに！）。間違いない。Windows10 は史上最悪の糞OS だ。

書き終えてアップデートを元に戻そうと再起動したら、いつまで経っても終わらない。強制リセットしようにも、ハードディスクにずっとアクセスあるし、なんなんこれ。もう５分以上掛かってるので、ノーパソで続き書いてるけど、まだ終わらんな。ハードディスクのアクセス断続的になってきたんで、強制リセット掛けて自動修復モードへ移行。なんかもう、やり慣れて自動修復職人になってきた。

ちなみに自動修復は、手動でメニューを選んで進めなければならんので自動なんかじゃない。しかも非常に時間が掛かるので、まーやりたくない。修復が終わっても、起動が遅くデスクトップまで行ってもデバイスの接続音やらなんやらで、要するに Windows Update 後の起動と同じ。こうやって Windows10 は我々から時間を奪っていく。

最新の品質更新プログラムのアンインストール後に元に戻ったのを確認し、即行で Windows Update を停止しました。これで１ヵ月は大丈夫なはずですが、８月末みたいな緊急アップデートみたいなのがあると、勝手にやるみたいなんだよな。同じように１ヵ月停止にしたはずの環境が、勝手に再起動掛かってて不具合再発みたいなのあった気がする。とにかく最近の Windows Update の品質は最悪だと言わざるを得ない。

また Windows10 か、もういい加減にしてくれと言いたくなる。少し前にリモートデスクトップでブラックスクリーンになり操作不能になるというのがあったばかりだが、今度はいっさいの接続を受け付けなくなるので深刻だ。まあ、今回は VMware ESXi の仮想マシンで起きているので「VMware SVGA 3D」とかが悪いのかもと「Microsoft 基本ディスプレイアダプター」に変更してみても状況は変わらず。

試してみてダメだったもの

• 再起動など
• VMware Tools 10.3.5 へのアップデート（ここから）
• ディスプレイアダプタを「VMware SVGA 3D」から「Microsoft 基本ディスプレイアダプター」に変更

いずれも時々繋がることもあるが、非常に時間が掛かったり、コンソール側の画面がブラックやダークブルーになり（マウスカーソルは表示されるが動かない）VMware 側で CPU 使用率が振り切れ、コンソール側からもログイン不能になる。この状態になるとリセットするしかなくなるのだが、繰り返しこれらの操作をしているとそれすら不能になり、ESXi ホストマシンを再起動しないと回復できなくなる。

暫定的に有効な対策

• 強制リセットを繰り返し、自動修復メニューを表示させる（以下押すボタンの手順）
• [詳細オプション]
• [トラブルシューティング]
• [詳細オプション]
• [更新プログラムのアンインストール]
• [最新の品質更新プログラムをアンインストールする]×2
• [完了]

Microsoft か VMware が修正プログラムを出してくれるまでは、アップデートはしないほうが良さそう。Windows10 はこういうトラブルが本当に多い。

VMware 仮想マシンだけかと思ったら...

今回のアップデート、ネットワーク関係がおかしいと思う。ファイルサーバからコピーしている最中に重くなり、リモートデスクトップが次々に切断され、最終的にこうなりました。しかも、エラー情報の収集が 100% に達しても再起動しないので、強制リセットするしか無かった。

大型アップデートだけでなく、毎月のセキュリティアップデートでもトラブルが発生するなら、とても安心して Windows10 を使っていられない。来年、Windows7 のサポートが終わったら、この糞 OS を使うしかないと思うと嫌になって来る。

追記

アップデートをアンインストールして解決したと思っていたら、ネットワーク関係がどうも怪しい。複数のファイルをコピーしようとすると１個目が終わると止まって「タイムアウトしました」というメッセージが表示されたりする。

酷いのはネットワーク越しにファイルを移動させた場合。エラーのせいで移動元にも移動先にもファイルが無くなり消えてしまった。幸いバックアップがあったから良かったものの、そうで無かった場合は冷や汗ものだった。

追記2

あれから１ヵ月経って、再び Windows アップデートが掛かり、同じ症状に陥りました。今回は、すぐにリセット×３で自動修復（メニュー操作なし）で回復できましたが、同様に１ヵ月更新停止していた Windows10 仮想マシンが数日置きに何台かあるので気が滅入ります。

ちなみに、ESXi 6.7 update 3 にアップデートしてみましたが改善しませんでした。新しく仮想マシンを作ってクリーンインストールしても再現するので、現在の最新アップデートを適用した Windows10 で不具合が起きています。色々と試してみて分かってきたことがあるので共有しておきます。

• リモートデスクトップ接続しサインアウトで終了する場合は、再度リモートデスクトップ接続をしてもうまく行く
• リモートデスクトップ接続し切断した場合は、再度リモートデスクトップ接続ができない（ESXi のコンソールでは非常に動作が重くなり、実質ログイン不能状態になる）
• 一度この状態になると強制電源OFFをしない限り回復は不能（非常に困難ではあるが ESXi コンソールから操作してシャットダウンは一応可能）
• この状態になるとCPU使用率が高いため、１台程度ならホスト（ESXi）は耐えられるが、複数台同時にこの状態にしてしまうとホスト自体が操作不能となる
• グーグル先生に聞いてみた：windows10 RDP CPU 100% 対策

最後のリンク先の記事の様子だと、８月のアップデートからではなく少し以前からある事象のようです。その記事にあるとおり、リモートデスクトップを終了するときはサインアウトするぐらいしか無く、誤って切断してしまうと一発アウトという厳しい状況です。仮想マシンの用途として、長い処理や定期的な処理を実行させているので、そもそもサインアウトはダメです。やはり「アップデートをアンインストールして自動更新を１ヵ月停止させる」という対策しか、今のところありません。

なお、リモートデスクトップを諦めるなら、VMware Remote Console を使うという手があると思います。こちらは、ESXi のコンソールを単独のアプリケーションのように表示するツールになっていて、プロトコルとしてインストールされます。通常は ESXi の管理サイトから起動するのですが、バッチファイルで通常のアプリケーションのように起動させることができます（別記事で紹介しようと思います）。

追記3

この問題には関係無さそうですが KB45172211 が原因で「VMware ワークステーションの機能に問題を抱えている」と書いてある記事を見つけました。斜め読みした感じでは VMware ワークステーションが動かないっぽいです。

• 「Windows 10」セキュリティアップデートに複数の問題が報告される

追記4

最新の大型アップデート Windows 10 November 2019 Update (1909) にて、ようやく解消されたようです。他に問題があるかも知れませんので、アップデートは慎重に行った方が良いと思いますが、この事象でお困りの場合はスナップショットを作ってから試してみることをお勧めします。それにしても長かったなあ。。。

中古で買ったパソコンの回復ドライブを作成しようと思い、Windows10 が示した 8GB の USB メモリを用意したんですが、半分ぐらい進んだ時点で「エラーが発生しました」とかで失敗してしまいました。理由も何も示されないのは、もはや Windows10 の伝統芸能なんでしょうか。

結論から言うと容量不足なわけで、16GB の USB メモリに作成し直したところ 9.18GB ほど必要だったことが分かりました。 ちなみに、失敗した USB メモリを見てみると約半分ぐらい容量が残っていて、これだけ見ると容量不足と気が付きにくいんでは無いでしょうか。恐らくは、初期の Windows10 は 8GB に収まっており、あのメッセージは固定テキストで実装されているんだと思いますね。準備に結構時間が掛かっているにも関わらず、正確な見積もり容量すら計算していないとか、相変わらずお粗末な OS ですよね。

Windows アップデートを昼間やると仕事にならんので、昨日の夜にやったわけですよ。アップデートを開くと累積アップデートの 1803 と 1809 があがってて、1803 のアップデート完了で再起動になった。かなり待たされたが、時間のことでとやかく言うつもりはない。再起動後、念のため更新プログラムのチェックを行うと、1809 のアップデートが始まった。いっぺんにやってくれないのか、と思いつつ処理を待っていると...。

C: ドライブの容量不足で、何やら解決手段のようなダイアログが表示された。それを見ると、STEP1 C: のクリーアップ、STEP2 他のドライブを使用、みたいな内容でクリーンアップも限界そうだったので、他のドライブを指定して続行を選んでみた。その後再起動が掛かり、ブルーバックで更新処理が続行される画面になるが、ここからいっこうに進まない。ずっと０％のままだったが、１時間くらい経ったころようやく動きはじめ２０％超えくらいまで確認して放っておいた。更に１時間ほど経っても終わってない、何気にメッセージを見てみたら「元の状態に復元しています...」とある。

これなんだよ Windows10。ちなみに、指定した他のドライブは 200GB ほど空きがあったし、ダイアログで○マークも付いていたので問題無かったはず。結局、1803 の１時間に、1809 の２時間＋復元２時間、５時間以上も掛かってアップデートに失敗しやがった。しかも、どういう理由でコケたのか、解決方法は何なのか、何も提示されない。さ・ら・に・「更新プログラムの操作にどの程度満足していますか？」とか無神経に聞いてきやがった。

前から Windows 10 が嫌いで仕方ないんですが、今日また嫌いになる出来事が...。それはファイルの関連付け、今までこんなことで苦労なんてしたことがありませんし、解決できない、原因も分からない、えーそんなバカなというような感じです。

やりたかった事

今まで愛用していたテキストエディタ（ちなみに terapad）がさすがに古くなって少々改善したい点もあったことから、重い腰をあげて notepad++ に移行することにしました。こういったツールはポータブル版（インストーラなしでコピーして配置するだけで使用できる）に決めているので、zip 版を用意しました。

トラブル発生

解凍したファイルを配置して、ファイルの関連付けを notepad++ に変更するだけでいいはずなんですが、どうやっても関連付けることができません。

• notepad++ の設定からの変更
• 右クリックメニュー ＞ プログラムから開く ＞ 別のプログラムを選択 ＞ 常にこのアプリを使って開く
• ファイルのプロパティ ＞ プログラムの変更
• 設定 ＞ アプリ ＞ 規定のアプリ ＞ ファイルの種類ごとに規定のアプリを選ぶ
• GUIで行った作業と同等のレジストリ変更
• システムの回復（DISM & SFC）
• 完全なシャットダウン
• 「このファイルは他のコンピュータから取得したものです」の解消
• ちなみに最初の手順でやって３環境中１環境だけ成功

こんな感じでやって諦めました。レジストリを確認しながらGUI操作をしたり原因を追究しようとはしましたが、怪しい一点のみを除いて訳が分かりません。とにかく、エラーも出ないしまったく変化しないしで、ほとほと疲れました。

怪しいのは一点のみ

これについて、ひとつだけ成功した環境がありました。レジストリを見比べたりしても原因が掴めず悩んでいたところ「再起動が必要です」というメッセージが出て「あー」ってなったんですよね。他の失敗環境ではアップデート済みでしたので、今月のアップデートを適用したかしてないかの違いでは無いか、と。今までもアップデートがらみで色々あった Windows 10 ですから十分あり得ると思われます。

追記：別の未アップデート環境で試したところ何の問題もありませんでした。来月以降のアップデートで修正されることを期待します。

ほんと勘弁して欲しいわ Windows 10

こんなアップデートの度に不具合でゴタゴタする OS は未だかつてありませんでした。マイクロソフトもようやく気付き始めたのか、アップデートサイクルを見直す動きもあるみたいです。はっきり言って余計な機能が多いし、かつてのようにビジネス向けとパーソナル向けで分けてやって欲しいですね。最近ので言えば、Windows 7 をビジネス向けに延長サポートしつつ、Windows 10 はパーソナル向け、というのが理想形な気がいたします。アップデートに３時間以上も掛かるのに仕事ではとても使えないっすよ。

Windows10 が最新版にアップグレードできない問題を解消するために、ESXi をアップグレードすることにしました。下位バージョンの 5.5 で問題無いことと、NIC も外した最小構成でもダメだったことから、6.0u1 固有の問題が疑われました。

アップグレード手順

概ね下記の手順になります。アップグレードによって、ファイルシステムのサポートが終了したりするので、事前に調査しておきましょう。メジャーバージョン同士でもクライアントがウェブベースになったりしていますので、注意が必要です。

1. ファイルをダウンロード
2. ESXi からアクセスできるファイルシステムにコピー
3. すべての仮想マシンを停止
4. メンテナンスモードに切り替え
5. アップグレード
6. 再起動
7. メンテナンスモード終了
8. 停止した仮想マシンを起動

ダウンロード

my vmware から、製品名を "ESXi (Embedded and Installable)"、バージョンを選んでファイルを検索します。リストには、"update-from-esxi6.5-6.5_update02" など update の付いたものがあります。恐らく、update 付きのものはそこまでの更新ファイルをまとめたもの、付かないものは差分と思われますので、内容をよく確認して差分ファイルも必要か判断してください。

アップグレード

まずアップデートファイルの内容（プロファイル名）を確認します。今回のファイルは下記の内容でしたが、日付の違いと後ろの "s" はよく分からないのですが、"ESXi-6.5.0-20180502001-standard " を入れることにしました。

esxcli software sources profile list \
-d /vmfs/volumes/hdd/update-from-esxi6.5-6.5_update02.zip
Name                              Vendor        Acceptance Level
--------------------------------  ------------  ----------------
ESXi-6.5.0-20180501001s-standard  VMware, Inc.  PartnerSupported
ESXi-6.5.0-20180501001s-no-tools  VMware, Inc.  PartnerSupported
ESXi-6.5.0-20180502001-no-tools   VMware, Inc.  PartnerSupported
ESXi-6.5.0-20180502001-standard   VMware, Inc.  PartnerSupported

調べたプロファイル名を指定して、アップデートコマンドを発行します。ファイル変更を行わない "--dry-run" オプションもあるので、動作を確認する場合は指定してください。

esxcli software profile update \
-p ESXi-6.5.0-20180502001-standard \
-d /vmfs/volumes/hdd/update-from-esxi6.5-6.5_update02.zip

更新作業は一瞬で終わりますので、ホストを再起動して適用されたか確認をします。今回は懸念していた問題は何も無く、あっという間に最新版にアップグレードできてしまいました。

アップグレード結果

全ての仮想マシンを停止するので、今までアップグレードしてきませんでしたが、案外簡単に時間もかからずアップグレードできることが分かりました。しかし、いつもこんなうまく行くとは限りませんから、バックアップシステムがあると安心だなと思いました。iSCSI だとロードバランサみたいにバックアップシステムを使うことはできませんが、NFS ならそういった構成もありかなと思います。

さっそく Windows 10 のアップグレードを試したところ、ブルースクリーン＆ロールバックは発生せず、問題なく April 2018 Update を適用することができました。結論としては「ESXi6.0u1 のホスト環境では Windows 10 1603 以降の仮想マシンは動作しない」ということでした。

追記：別環境5.5→6.7アップグレード

相変わらずサイトが分かりにくいので my vmware から、アップデートファイルのダウンロードページまでのパスをメモしておきます。5.5からアップグレードする場合、いったん6.0に上げてから6.7へと２段階で行います。

1. my vmware にアクセス
2. 右側の Quick Links から All downloads に行く
3. 右側の Other Downloads から Download Patches に行く

メジャーバージョンを上げたためか、ライセンスキーの更新も必要なようでした。この取得先も分かりにくかったので同様にメモしておきます。

1. my vmware にアクセス
2. 右側の Quick Links から All downloads に行く
3. 表示された All Products からVMware vSphere Hypervisor (ESXi) の View Download Components に行く
4. 製品リストが表示されるので Download に行く
5. License & Download にライセンスキーがある（執筆時点ではこのページ）