memo.

カテゴリー: Windows

  • Windows11のプレビュー版でも、AnyConnect 4.2は使えた

    Windows11（21H2）のプレビュー版をいれたので、CiscoのAnyConnectを試してみた。結構、古いバージョンなので、動作しないかも、と思っていたのだが、動作した。

    Windows11のUIに合わせて、ログインのところの見た目が少し変わった程度だった。VPNのコネクションもはれるし、OS内のスキャンもできている。とりあえず、秋になってWindows11へのアップデートが始まっても大丈夫そうだ。これからWindows11の仕様がかわらなければ、だが。

  • Panasonic Let’s Note SV8で20H2と21H1のアップデートが失敗する

    Panasonic Let’s Note SV8でWindows10の大型アップデートの20H2と21H1のアップデートが失敗する問題がある。使っているWindows10のバージョンが1903や1809だと、サポート切れになるため、大型アップデートを適用しないといけないが、これが失敗する。利用しているドライバが原因という可能性が高く、切り分けに時間がかかっていた。このアップデートに失敗する原因がやっとわかった。

    Let’s Note SV8の標準ドライバの「BayHub SDカードドライバー」のバージョンが「1.1.101.1029」の場合にWindows10の大型アップデートに失敗する。（ただし、100％失敗するわけではないのが厄介）

    この「BayHub SDカードドライバー」バージョンを「1.1.101.1033」に上げることで、Windows10を、20H2と21H1にアップデートすることができる。ドライバのダウンロードページは下記。インストール方法も一緒に載っている。

    https://faq.askpc.panasonic.co.jp/faq/docs/005039

    これの厄介なところは、SV8のドライバを検索すると、SV8シリーズの導入済みドライバーのページが最上位に表示されること。このページのドライバーは、「1.1.101.1029」なので、インストールしても意味がなく、最新ドライバーがまとまっているわけでもなく、不親切だ。このページに、大型アップデートに関する注意事項を書いておいてくれればよいのだが。大型アップデートに関するページは別ページになっていてリンクもないので、検索でたどり着くしかないく不便だった。

    デフォルトで導入されているドライバーでWindows10の大型アップデートに問題があると、本当に大変だ。ついでにいうと、他の人に任せていたのだが、なぜこれが発見できなかったのか。初期化状態からのアップデートの検証もやってもらっていたのだが。自分でやったら、わりとすぐに問題を特定できた。情シス系作業は向き不向きがある感じだ。

  • 「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の機能では戻れなくなるので、注意が必要。