航海日誌 Starlog

起動ディスクがHDDのWindows 10 デスクトップPCで、電源Onからのサインイン時にユーザープロファイルを正しく読み込めないのか、一時プロファイルとなっていることがある。一旦サインアウトし、再度サインインすることでエラーもなく使うことができる。

高速スタートアップが有効な場合と無効な場合両方で発生。サインイン画面が表示されてすぐにパスワードを入れてサインインすると高確率でこの状態になる。サインイン画面になってから数分待ってサインインすると正常にサインインできる。

Windowsのデフラグは初期設定のまま毎週水曜に実施され、状態を見ても断片化無しと表示される。のだが、ディスクアクセスが多いときにサインインに失敗しているように思えるので、最近使っていなかったMyDefragでデフラグした(System Disk Monthly)。結果、サインイン画面が表示されてすぐにパスワード入力・サインインしても正常にサインインできるようになった。Windowsの起動時間を測っていなかったけど、ひょっとしたらそちらも早くなっているかもしれない。やはり、MyDefragでのデフラグは時々やっておくのがいいようだ。それにつけてもWindows標準デフラグの役に立たなさよ。

MyDefragはWindows 8.1以降では問題があることがあるらしいのだけど、自分の環境では問題なし。

常用しているWindows PCで、Microsoft Edgeが落ちることが多い。いつの間にか静かに消えている。
背景として、このPCはHDDであるため、セキュリティソフトがCドライブをスキャンしているとEdgeの応答がすごく遅くなる。以前書いたように、Edgeのアプリケーションフォルダとプロファイルフォルダ(キャッシュフォルダ含む)をUSB 2.0接続のSSDに変更したところレスポンスが改善された(それでも遅いが)。

問題の原因はおそらくSSDに不良セクタが100個ほどあり、時々数が増えていること。Edgeが落ちたタイミングと不良セクタ増加のタイミングは全然一致していないが、不良セクタ判定されないものの読み書きでエラーとなっていた可能性がある。余っていた不良セクタがないSSDと入れ替えて、今の所安定して動いている感じ。

Microsoft Formsで作ったフォームを、Teamsのグループに移動することができる。グループのフォームにすると機能は増えるのだが、個人用フォームとは色々扱いが異なるので、そのメモ。

個人用としてのフォームでは、管理画面の応答タブの「Excelで開く」から応答の全てをExcelのファイルとしてダウンロードできる。しかし、グループのフォームでは「Excelで開く」で開かれるのはSharePoint上に作成されたファイルになる。

SharePoint上のExcelファイルに応答を自動で反映させることができるので、この機能を使ってフォームの回答状況をチェックするマクロを作ってみた。SharePoint上のExcelファイルをExcelで開き、内容を読み取るというもの。

SharePoint上に応答とリンクしたExcelファイルを作成して開き(ブラウザ内で開かれる)、共有ボタンで共有のためのURLを取得する。https://なんとかかんとか という普通のURLとなるが、グループ名やフォーム名が長いとExcelで開くのが難しくなる。パスが短ければWorkbooks.Openメソッドや Hyperlinks(1).Followメソッドで開くことができるが、長い場合はShellステートメントを使ってWindowsに開かせないといけない。取得したURLをExcelで開くようにShellステートメントに書くのがミソ。実行前にExcelのオプション→詳細設定でリンクの処理の「Officeファイルへのサポート対象ハイパーリンクをOfficeデスクトップアプリで開く」にチェックを入れておく。

で、以下のような文を実行するとExcelでSharePoint上のファイルを開くことができる。

Shell Excel.exeのフルパス SharePoint上のExcelファイルのURL

ここで、SharePoint上のExcelファイルのURLは共有ボタンで取得した文字列すべてを使う。

ShellステートメントでWindowsにSharePoint上のファイル開かせる場合、自分の環境では数秒時間がかかる。Workbooks.OpenやHyperlinks(1).Followで開く場合は、ファイルが開かれるまで処理が次に進まないが、ShellではWindowsにコマンドを発行したらファイルが開かれていなくても次に処理が進んでしまう。これではまともに動かないので、ファイルが開かれるまでVBAに待たせる必要がある。

そこで、Excelで開かれているブックの数が一つ増えるまで待つことにした。ただVBAでループを回しているだけだとWindowsに制御が返らず、ファイルが開かれないのでDoEventsでOSに制御を戻すようにする。

Dim NextWbCount as Long, CharDQ as String, ResponseFile as Workbook
CharDQ = Chr$(34)
NextWbCount = Workbooks.count + 1
' HLStrは共有ボタンで取得したURL
Shell CharDQ + Application.Path + "¥Excel.exe" + CharDQ + " " + CharDQ + HLStr + CharDQ
' Shellステートメントで開いたファイルが開くまで待つ
Do
    DoEvents
Loop Until Workbooks.count = NextWbCount

これでファイルは開かれるのだが、それで安心してはいけない。開いたファイルの内容が少し遅れて転送されてくるので、ファイルを開いたからといってVBAで即処理を始めると、空のファイルに対して処理をすることになってしまう。A列は応答に対する連番であり、A1セルは"ID"という文字列になるので、とりあえずA1セルが空欄でなくなるまで待つことにしてみる。このときもDoEventsでOSに制御を戻さないと、いつまで経っても内容が転送されてこないことになる。

Set ResponseFile = Workbooks(Workbooks.count)
With ResponseFile.Worksheets(1)
' 更新が反映されるまで待つ
Do
    DoEvents
Loop While .Cells(1, 1).Value = ""

条件判定は、Loop While IsEmpty(.Cells(1, 1)) でもいいかもしれない。

起動ディスクがHDDのかなり古いデスクトップPCを使っている。OSはWindows 10。起動ディスクがHDDなので色々遅いのは仕方がないのだが、Microsoft TeamsとMicrosoft Edgeは使う気をかなり削ぐ遅さ。

Microsoft Teams

ウインドウが邪魔なので、バックグラウンドで起動/ウインドウを閉じても終了しない設定で、用がないときはウインドウを閉じている。メンションされた通知が表示されたときに見に行くのだが、ウインドウが表示されるまで秒単位で待つ。わずか数秒なのだが、これが遅くてストレスになる。最小化してある他のアプリケーションのウインドウを再表示するぐらいのスピードで開いてくれるといいのだが。

ユーザープロファイルフォルダに有るAppData¥Local¥TeamsフォルダをUSB 2.0接続のSSDに移動して、元のフォルダがあったところに移動先のジャンクションを作成したところ、表示速度が劇的に速くなった。最小化したアプリケーションを再表示するぐらいに。これなら少し使う気になる。

Microsoft Edge

アンチウイルスソフトやバックアップソフトなどがCドライブをアクセスし始めると、とたんにレスポンスが悪くなる。スリープしている別のタブを表示させるのにも分単位で待たないといけない。最初はEdgeのプロファイルフォルダをUSB 2.0接続のSSDに移動して元の場所にジャンクションを張っておいたのだが、多少はましになったかな程度の効果。結局Edgeそのものが入っているProgram Files(x86)¥MicrosoftフォルダもSSDに移動してジャンクションを張った。これでかなりまともに動くようになった。

TeamsもEdgeもSSDのシステムで使うのを前提に作ってあるんじゃないかという気がする。

今回USB 2.0という遅いインターフェースながらSSDを使うことで早くなった。今どきの高速なインターフェースでSSDが搭載されたPCなら快適なんだろうな。

ネットワーク上の共有フォルダにあるディレクトリに1000, 1001, 1002, ....と4桁でナンバリングされたディレクトリがあり、これらの先頭に0を追加して5桁に変更した。

このディレクトリを専用に使うソフトの方は5文字名ディレクトリに対応させたが、各ディレクトリへのショートカットを使っている人から「ショートカットのリンクが切れた」との苦情が出た。多分ローカルドライブだったら変更後のリンク先を探してくれそうだが、ネットワーク上の共有フォルダのせいか追跡できなかったようだ。

そこで、5文字名の新しいディレクトリへのリンクを4文字名のジャンクションとして作るバッチファイルを作成した。ディレクトリ数が多いのと、複数階層になっているので、カレントディレクトリから作業を始めて下層まで再帰的に実行する。引き数はない。

@echo off
rem カレントディレクトリ以下のディレクトリ名を取得→%%dにフルパスで入る
for /d /r %%d in (*) do (call :CHNGJUNC %%d)
exit

:CHNGJUNC
rem フルパスの%%dからディレクトリ名だけ取り出す
rem %1はバッチファイルの引数ではなく、このサブルーチン呼出し時の引数
set str_in=%~n1
set str_five=%str_in%
set /a str_length=0
rem %%dに含まれるディレクトリ名の文字数を数える
:CHNGJUNCLOOP
  set str_in=%str_in:~1%
  set /a str_length+=1
if not "%str_in%"=="" (goto :CHNGJUNCLOOP)
rem ディレクトリ名が5文字のとき、かつ1文字目が0のとき、5文字名のディレクトリに対するジャンクションを4文字名で作成
if %str_length% equ 5 (
  if "%str_five:~0,1%"=="0" (mklink /J %~p1%str_five:~1% %~p1%str_five%)
)
exit /b

forやcallでのサブルーチン呼び出しは初めてだったのだが、forの中の環境変数の扱いや、callで呼び出したサブルーチンの引数の扱いにちょっと戸惑ってしまった。

Windows 10 2004に更新したらデスクトップPCに挿してあるBluetoothアダプタIO-DATA USB-BT40LEでApple MagicMouse(I)が使えなくなってしまった。Windowsの機能更新に伴う類似の不具合はネット上に山と報告されているが、ついに自分にも起こってしまった (^^;)

症状は、機能更新直後にペアリングの情報は持っているものの接続できない。アダプタをPCから外したり、色々いじっていると接続されることもあるのだが、すぐに切れる、切れたあと再接続できないという調子。

1909を使っているときにこのアダプタを使い始めたのだが、最初に添付されていたWindows 8.1用のドライバを間違って入れて使っていたのが原因かもしれない。ドライバは12.0.0.???というバージョン(一番下の数字は忘れた)。

最終解にたどり着くまで色々やったのだが、そこは省略。結局の所、Windows Updateカタログから最新版のドライバをダウンロードしてインストールした。

Windows UpdateカタログでBroadcom bluetoothで検索して
Broadcom Corporation - Bluetooth Controller - Broadcom Bluetooth 4.1 USB Windows 10 and Later Servicing Drivers for testing,Windows 10 Anniversary Update and Later Servicing Drivers Drivers (Other Hardware) 2016/08/31 12.0.1.1010 473 KBをダウンロード。このときアダプタ名の20702を含めて検索すると最新版が引っかかってこない。
どうやら最新の12.0.1.1010はUSB-BT40LEには対応していないようで、デバイスマネージャーでUSB-BT40LEのハードウエアIDを見て正しいドライバを選び直したところ、最初に見つけた12.0.1.750にたどり着いた。次のタイトル、変更日、サイズとなる。
　　Broadcom Corporation - Bluetooth Controller - Broadcom BCM20702 Bluetooth 4.0 USB Device
　　最終変更日時: 2015/09/22
　　サイズ: 2.1 MB
検索結果のリストには32bit版と64bit版が混在しているが、ぱっと見わからない。青字になっているタイトルをクリックすると詳細が表示されるので、アーキテクチャを確認してAMD64用をダウンロードする。32bit版(x86)はやたらたくさんあるのだが、64bit版(AMD64)は非常に数が少ない。

ダウンロードしたcabファイルはコマンドプロンプトで展開する。書式は次のもの。

expand <CAB FILE NAME> -F:* <DESTINATION>

コマンドプロンプトでcabファイルのあるフォルダへ移動し、展開先フォルダを作る。Cabファイル名もやたらと長いので、ファイル名を短いものに変えて構わない。例えば、AMD64.cabをcabファイルと同じ階層に作ったNEWフォルダ内へ展開する場合は

expand AMD64.cab -F:* NEW

デバイスマネージャーでUSB Bluetoothアダプタのプロパティから「ドライバ」タブ→更新を実行し、ソースを先程の展開先にして進めると、ダウンロードしたドライバがインストールされる。

安定して動作させるためにMagicMouseそのものやUSB BluetoothアダプタがつながっているUSBルートハブの「電源の管理」タブで「省電力のためWindowsがこのデバイスの電源をオフにすることを許可するの」チェックを外しておく（1909のときも設定してあったが）。

追加でネットワークアダプタの設定でBluetoothでのネットワークを無効にした。機能更新インストール前にはBluetoothネットワークは無効にしてあったのだが、機能更新のインストール後に有効になっていた。

今度は再接続もスムーズ。更新後のように数分で切れることは減ったが、半日ぐらいすると切れてしまう。よく見ていると、本格的にだめになる前に１〜２回ほど切れかかってもとに戻るような動きがあった。マウスが使えなくなったときに、Bluetoothサービスをコマンドプロンプトなどから再起動すると使えるようになることもわかった。そこで、次の対策。
サービスでBluetoothサービスの「回復」タブの内容の次のように変更してみた。矢印を付けたものが書き換えたところ。
「最初のエラー」：サービスを再起動する
「次のエラー」：サービスを再起動する
→「その後のエラー」：サービスを再起動する
→「エラーカウントのリセット」：1日後に行う
→「サービスの再起動」：1分後に行う
→「エラーで停止したときの操作を有効にする」：有効
これで、マウスが死んだなと思っても、１分以内に復活する確率が上がった。それでも1日に1回ぐらい、完全に回復しないことがある。そういうときはBluetoothアダプタをPCから外してサービスを再起動してアダプタを接続すると復活していた。

しかし、ここまでしないと使えないとは・・・。アダプタを使うなということか？

以前、Windows 10 64bit 1903のMBA 11"(2011)が起動中にブラック・アウトし、原因がディスプレイドライバにあったことを書いた。

先日Windows 10 2004にアップデートしたのだが、早速起動中にブラック・アウトしてくれた。前回と同様に、ディスプレイ周りがおかしいだけで、電源ボタンを1回突けば普通に終了している(っぽい)．

前回、セーフブートの設定をしておいたのだが、2004へのアップデートによってデフォルトのスタートアップ選択メニューが無効の設定に戻っていた orz

前回と同じように、起動時のWindowsロゴで電源強制切断を2回行い修復モードで立ち上げ、セーフモードでの起動へ持っていく。セーフモードでログイン後、早速起動時のメニューをlegacyに変更。

続いてディスプレイドライバを上書きインストールし再起動。またもブラックアウト orz　上書きじゃだめなのね・・・。

気を取り直してセーフモードで立ちあげ、デバイスマネージャーからディスプレイアダプターのプロパティを開いてデバイスの削除・ドライバのアンインストールを行う。通常モードで再起動し(ディスプレイドライバを入れていないのでセーフモードと同じ低解像度だが)、サインインしてからディスプレイドライバをインストール・再起動。ようやく使える状態になった。

このMBA11はWindows 7時代からトラブルが多く、その原因は当時使っていたアンチウイルスソフトが良くなかったり、gdi++(当時)の設定を色々変えて試しておかしなことになったりしたことだと思うのだが、クリーンインストールをせずに使っているのが良くないのだとは思う。もうそんなに使わないと思う機体なので、このままだましだまし使っていくつもり。

Windows 10を1909から2004に機能更新プログラムを当ててバージョンアップした。MS明朝とMSゴシックのバージョンがどちらも0.01上がっていたので、1909(フォントは1903と同じバージョン)と同じ手順でビットマップ削除版を作ろうとした。UniteTTFでttcファイルをttfに分割し、sbit.exeでビットマップデータの削除、UniteTTfでttfをttcに再結合。

sbit.exeでの処理が今までのバージョンのようにうまく行かず、処理の途中での一時ファイルが作成されない。エラーを無視して作業を進めてビットマップフォントを抜いたつもりのttcを作ってシステムにインストールすると、イベントビューアーとタスクスケジューラーが「スナップインのエラーがMMCにより検出された 」というようなエラーを出して起動できなくなった。キーボードカスタマイズソフトの鍵盤の執事くん(keyboardbuttler.exe)も起動できなくなった。

フォントをもとに戻したらいずれも問題なく起動できるようになった。このバージョンからフォントの内容が変わったのだろう。

普段使っているデスクトップPCはストレージがHDDなので応答がそれなりに遅い。

余っているあまり容量が大きくないSSDをIEEE1394a/b/USB2.0のインターフェースを持つケースに入れて接続し、テンポラリディレクトリをSSDに設定してみた。SATAに比べたら転送速度は遅いが、それでも小さなファイルの読み書きはHDDよりマシだろうと考えてのこと。PCには1394aのIFカードを差してあるので、1394aでつなぐことにした。

ブラウザやOfficeなどの応答は以前より良くなったように思う。が、HCL Notes 9.0.1が時々フリーズするようになった。

Notesはユーザ環境変数のTEMPを使うようなので、ユーザTEMPだけHDDに戻したらフリーズしなくなったように思う。

Windowsの仕様で、何かのタイミングでデータベースとの接続が切れるとNotesがタイムアウトを待たずにフリーズすることあるようで、ディスクアクセスでも同様に想定した時間内に応答がないとフリーズするのではなかろうか。

Windows 10でOneDriveが起動しないPCがあったので調べてみたら、グループポリシーでOneDriveを使用しないことになっていた。

ローカルグループポリシーエディターを起動
コンピューターの構成→管理用テンプレート→Windowsコンポーネント→OneDrive→「OneDriveをファイル記憶域として使用できないようにする」を「有効」→「未構成」に変更(ちゃんと動くPCでは未構成だったので)

OneDriveをスタートメニューから実行できた。