memo.

カテゴリー: Windows

  • 「Delivery Optimazation」が大量の通信をしてネットワークが重い

    Windows10で、ネットワークが重いので調べた。調べたところ、「サービスホスト: Background Intelligense～」の「Delivery Optimazation」のプロセスが大量のネットワーク通信を使用していることがわかった。

    この「Delivery Optimazation」が何をやっているプロセスなのかを調べると、Windows Updateの更新プログラムの最適化を行っているものだということがわかった。つまり、Windows Updateがネットワークに負荷をかけていることが分かった。

    https://docs.microsoft.com/ja-jp/windows/deployment/update/waas-delivery-optimization

    それから、「Delivery Optimazation」は、近くのWindows10から、配信プログラムを受け取れるようにもする。同じLAN内などの近くに既にWindows Updateを行ったWindows 10がいれば、そのPCからアップデート用のデータが提供される。インターネット回線に負担がかかっていなくても、LAN内には、Windows 10のPC間で通信が大量に発生しており、ネットワークが遅くなる、ということもあり得る。

  • ESENTエラーが発生して、ファイルサーバが突然使えなくなる。

    Windows Server 2012のファイルサーバの挙動がおかしいので、調べたら、下記のログがイベントログに残っていた。

    イベント 910, ESENT
svchost (952)  ファイル "C:\Windows\system32\LogFiles\Sum\Svc.log" のオフセット 3334144 (0x000000000032e000) への 4096 (0x00001000) バイトの書き込み要求は 36 秒間成功しませんでした。この問題はハードウェアの障害が原因であると思われます。問題をより詳しく診断するには、ハードウェアの製造元に連絡してください。

    イベント 910, ESENT
svchost (1212) データベース キャッシュ サイズの保守タスクに 60 秒かかりましたが完了していません。このため、パフォーマンスが大きく低下する可能性があります。 現在のキャッシュ サイズは、5 のバッファーであり、構成済みのキャッシュ制限 (ターゲットの 266 パーセント) を超えています。 キャッシュ サイズの保守によって、0 のバッファーが削除され、14408 回のフラッシュが試行され、0 のバッファーのフラッシュに成功しました。保守が起動されてから 191576 回実行されました。

    イベント 510, ESENT
svchost (1212) ファイル "C:\Windows\system32\LogFiles\Sum\Current.mdb" のオフセット 937984 (0x00000000000e5000) から 4096 (0x00001000) バイトの要求を書き込むことに成功しましたが、OS によるサービスを受けるまでに異常に長い時間 (36 秒) がかかりました。さらに、このファイルへの 4 の他の I/O 要求も、この問題に関する最後のメッセージが 1259 秒前に投稿されてからサービスを受けるまでに以上に長い時間がかかりました。これはハードウェアに問題がある可能性があります。問題の診断についての詳細はハードウェア製造元に問い合わせてください。

    ファイルシステムの異常の可能性もあるので、検査（チェックディスク）したが異常なし。ハードウェア的なディスク障害もなし。

    これが発生していた原因は、Veeam Backupの動作によるバックアップの競合だった。バックアップの間、ずっと発生するわけではなく、なんらかのタイミングで、ログなどの書き込みなどがスタックしたときに、書き込みができずに、ファイル共有の部分が止まってしまうようだ。動作中のバックアップも同じ時間ではないが、遅れて失敗している。この競合が解消されれば、ファイルサーバにはアクセスできるようになることはわかった。しかし、解消される時間はわからないので、バックアップを止めるのがよいのだろうが、状況が発生してしまうと止められない（止めても停止できず、効果がない）。動作時間を工夫するなどの対応が必要。

  • Windows10の空き容量をコマンドで表示する

    Powershellか、コマンドプロンプトで、fsutilコマンドを使うと、空き容量がわかる。GUIが使えない環境では楽。

    PS C:\Users\zen> fsutil volume diskfree c:\
空きバイト総数        :  39,843,536,896 ( 37.1 GB)
バイト総数             : 254,863,732,736 (237.4 GB)
クォータの空き領域の合計バイト数  :  39,843,536,896 ( 37.1 GB)
PS C:\Users\zen>

    Windows10じゃなくて、Windows Server系でも同じコマンドで空き容量をしることができる。

  • Alt + Tabで急にアプリの切り替えができなくなった

    Windows10で、Alt + Tabを使ったアプリの切り替えが急にできなくなった。

    なにか壊れたかと思ったら、Explorerがフリーズしていたようだ。新しくフォルダも開けず、しばらくしてExplorerプロセス再起動を求めらたので、プロセス再起動したら、Alt + Tabでアプリの切り替えができるように戻った。切り替えの部分は、Explorer配下の作業のようだ。

  • ASP.NETのプログラムを新環境にデプロイしたら「有効な Win32 アプリケーション」とエラーがでる

    古いASP.NETのプログラムを、新しい環境でコンパイルして、アプリケーションサーバ（IIS）にデプロイして、テストしたら、下記のエラーが表示された。Visual Studio 2019上では動作している。

    ファイルまたはアセンブリ 'xxxxxxxx.DLL'、またはその依存関係の 1 つが読み込めませんでした。 は有効な Win32 アプリケーションではありません。 (HRESULT からの例外:0x800700C1) 

    問題は、アプリケーションサーバであるIISの設定だった。Windows Server 2019のIIS10は、デフォルトでは64ビットのアプリケーションサーバとして動作する。そのため、32ビットのDLLが混じったアプリケーションを実行するためには、IISの設定で、32ビットのアプリケーションを動作するようにしないといけなかった。

    32ビットのアプリケーションを動作するようにするIISの設定方法は下記。

    1. IISマネージャー（インターネットインフォメーションサーバーマネージャー）を開く。
    2. アプリケーションプールを選択する。
    3. 右クリックして、「詳細設定」を開く。
    4. 全般にある「32ビット アプリケーションの有効化」のプルダウンで、「True」を選択する。
    5. OKをクリックする
    6. アプリケーションタスクで、「停止」して「開始」する（たぶん、リサイクルでもOK）

    これで、32ビットのアプリケーションも動作するようになる。

  • PowerShell 7.1をインストールした

    PowerShell 7.1がMicrosoft Storeから入手できるようになったので、インストールした。Microsoft Storeで、PowerShellと検索して、Microsoft Corporationが公開しているものを選択して、入手をクリックするだけ。Powershell 7.0が自分でインストーラーをダウンロードしてインストールしていたのに比べるとかなり便利。これで、新しいバージョンの配布もされるだろうから、先々を考えると、ストアからの配信はありがたい。

    Microsoft StoreからPowerShell 7.1をインストールしたところ、Windows 10上には、最初からインストールされていたWindows PowerShell、手動でインストールしたPowerShell 7.0、ストアからインストールしたPowerShell 7.1の３つが混在するようになった。使うときに間違えないようにしないといけない。

    あと、どこかでPowerShell 7.0のアンインストールをしないと穴になってしまう。

  • VS2008のアプリをVS2019で開いて、デバック実行したら「Assembly.csが見つかりません」が表示された

    VS2008のアプリをVS2019で開いて、デバック実行したら「Assembly.csが見つかりません」が表示された。「Assembly.cs」を探したが見つからず。元のプロジェクトはVB.NETで書かれている。

    VS2019上には、逆コンパイルで作成も選択できたので、実行してみたが失敗した。

    失敗したので、今度は、Assenbly情報を再作成した。

    1. ソリューションエクスプローラーでプロジェクトを選び、右クリックからプロパティを開く。
    2. 「アプリケーション」を選択する。
    3. 「アセンブリ情報（Y）」をクリックする。
    4. ウィンドウが立ち上がるので、確認してOKをクリックする（なにも変更しなくてもよい）
    5. プロジェクトのリビルドを行う。
    6. デバック実行して、同じエラーにならないかを確認する。

    これでエラーが出なくなった。

  • Windows10の大型アップデートをあてると、復元ポイントが消える

    Windows10の大型アップデート（October 2020 Update）を実行する前に、手動で復元ポイントを作成した。

    大型アップデートを適用して、Ver.20H2になったWindows10で復元ポイントを確認したところ、復元ポイントがなくなっていた。大型アップデートを適用してから、日が浅いので、以前のバージョンに戻して、復元ポイントを確認したが、前に作成した復元ポイントはすべてなくなっていた。

    つまり・・・

    • 復元ポイントを使って、大型アップデートの適用前には戻せない。（前のバージョンに戻せる期間を過ぎると戻せなくなる）
    • 大型アップデートを行うと、手動で作成した復元ポイントも消される。

    いろいろと不具合が起きても、過去のポイントには、Windows10の機能では戻れなくなるので、注意が必要。

  • WSL2でDockerを使えるようにインストールする

    メモとして。前提として、WSL2のインストールは終わっている。

    Docker Desktop for Windowsをダウンロードする。下記のURLにアクセスして、「Get Docker」からダウンロードする。

    https://hub.docker.com/editions/community/docker-ce-desktop-windows/

    ダウンロードしたインストーラー（EXEファイル）を実行する。インストールのときに、「Install required Windows components for WSL2」にチェックが入っているので、WSL2対応もばっちり。

    インストールが終わったら、Windows10の再起動が入る。

    で、なにをしたらいいのかわからないので、チュートリアルを実施。

    チュートリアルの通りにやったら、チュートリアルのコンテナが立ち上がった。

    このコンテナがどこで動いているのか気になって、WSL2のUbuntuでpsコマンドをたたいてみると、dockerに関連したプロセスが起動しているので、WSL2の上で動作していることが確認できた。

     root       185  0.0  0.5 1463396 31664 pts/1   Ssl+ 20:06   0:00 /mnt/wsl/docker-desktop/docker-desktop-proxy --distro-n

  • Windows 10 ver 20H2のIMEの予測変換がひどいのでオフにする

    Windows 10 Ver.20H2のIMEの予測変換がかなりひどいので、オフにしてみる。Ver.2004でもひどかったが、20H2はさらにひどい。IMEは止め時なのかもしれないが、選択肢がほぼないので、オフにして様子を見る。

    1. 右下のツールバーで、IMEを選んで、右クリックする（「A」か「あ」のアイコン）
    2. 「設定」を選ぶ
    3. 「全般」を選ぶ
    4. 「予測入力」の部分のプルダウンで、「オフ」を選択する

    これで、予測入力は使えなくなるが、誤変換や勝手に選択される問題もなくなる。