Photoshop の立ち上げ不能事象追跡中止 [睡夢庵の電脳環境]
【 Photoshop の立ち上げ不能事象追跡中止(^^;)>】
Photoshop CS2 が起動出来なくなる問題もエクスプローラのネットワークに関わる問題同様どういうタイミングで様相が変わるのかが捕捉出来ずフラストレーションが溜った為暫く追ってみましたが、結局の所力足らず、捕捉出来ませんでした。
・ 起動不能 ⇒ ブザー（WindowsUpdate） ⇒ 起動可能
⇒ 数分経過後起動不能
・ 起動不能 ⇒ ブザー（WindowsUpdate） ⇒ 起動不能
⇒ 数分経過後起動可能
・ 起動可能 ⇒ ブザー（AdobeUpdate1回目） ⇒ 起動不能
⇒ ブザー（AdobeUpdate2回目）
AdobeUpdateは２フェーズ１セットみたい
・ 起動不能 ⇒ ブザー（SoftwareDistribution) ⇒ 起動可能
・ 起動不能 ⇒ ブザーならず ⇒ 起動可能
遣り方が悪いのかもしれませんが、以上の様に追っている３つの事象の何れでも確実にこの組み合わせならば起動可能/不能になるという物がないのです(TT;)
ランダムに Photoshop CS2 の起動確認をしていると、やはり「フォルダ監視」で見ている一般的な Windows Update や ベンダーアプリの更新チェック等以外にアプリケーションの互換性確認に影響を与えるモジュールを変更するフェーズが動いていると思わざるを得ない動作をしますので今の所原因者の特定は諦めです。
この過程で メインの更新やMicrosoft アプリケーションの更新に関してはその日時を知る術が分かった事で良しとして、追跡を放棄・・・
まぁ、「フォルダ監視」はそのまま続けますので、監視フォルダに加わった変更についての日時だけはログとして残しておく事にします。
で、また分からない事が１つ・・・ C:\Windows\Temp\ の下に tw-xxxx-xxxx-xxxxxxx.tmp という名称のフォルダが１８個？作成される事がありますが、これはいったい何が作っている？ 中身を見ようとするのですが、「フォルダ監視」のブザーがなった直後に見てもいずれも空。 「フォルダ監視」の１分のディレイの間にフォルダを作って何らかの作業が完了しているという事なのでしょうか。 で、このフォルダは複数回分溜って一気に消される事もあれば数分後に消される事もあるのですが、この時 Windows Update も SoftwareDistribution も動いていない事がある・・・
《フォルダ監視が捉えた WindowsUpdate.log 更新回数》
03/16 03/17 03/18 03/19 03/20 03/21 03/22
06:08 06:22 05:59 06:11 06:06 06:16 06:43
06:50 07:35 09:59 08:31 09:07 16:29 12:32
07:50 08:41 16:45 09:41 10:31 20:13 13:34
08:16 15:56 18:57 13:05 13:40 16:45
09:07 18:18 16:45 16:45 18:40
09:31 20:27 19:08 20:03 19:17
10:21 22:16 20:25
16:45
17:14
18:07
上記の様に毎日信じられない位変更が掛かっています。 もしネットワークが見えなくなるのがこの回数トグルしたらとても仕事には使えませんよね。
実際には完全なフリップフロップにはなっていないので使えてはいますが、Photoshop CS2 では作業中にエクスプローラ系のモジュールが変わるのかファイルの読み出し/書き込みを選択するとコントロールが戻らず、タスクマネージャーで Photoshop CS2 をキルしなけらばならないという状況が実際に発生しています。
ここのところアンダーグラウンドでの Windows Update が頻発していますので、何時落ちるか分からず、コマメに中途でファイルを書き出して措かねば作業が全部パーになってしまいます。
タスクマネージャーの表示で Chrome の バックグラウンドタスクが分離して単独表示される件も繰り返し再現しています。 この２つの再現頻度は非常に高いです。
尚、エクスプローラのネットワーク接続端末の消失に関しては、今の処直っているみたいですね。
《 ReportingEvents.log で分かる事》
SoftwareDistribution 配下に出来る ReportingEvents.log の中には「2018-12 x64 ベース システム用 Windows 10 Version 1809 の累積更新プログラム (KB4471332)」や「悪意のあるソフトウェアの削除ツール x64 - 2018 年 12 月 (KB890830)」といった文字列が含まれており、エディタで「累積」や「悪意」、「(KB」で検索を掛ければ各々の更新タイミングを知る事が出来る様です。
<例>
{8297355F-C396-44C2-B02B-5E1B3F901E60} 2018-12-12 05:57:47:601+0900 1 181 [AGENT_INSTALLING_STARTED] 101 {710A7A2C-D4D2-4F65-826D-5B2E7C98B1F6} 1 0 UpdateOrchestrator Success Content Install Installation Started: Windows has started installing the following update: 2018-12 x64 ベース システム用 Windows 10 Version 1809 の累積更新プログラム (KB4471332) V4FEJtAsOEic6KMD.1.1.5.1.2.0
まぁ、ReportingEvents.log の中で「メインストリーム」アップデートだけでなく、Microsoft.～で示される Microsoftアプリケーションの更新も把握出来る事が分かっただけでも収穫でしょうか(^^)
Microsoft.WindowsAlarms/Microsoft.Xbox～/Microsoft.MSPaint といった文字列が入っていますので、「Microsoft.」で検索を掛ければアプリ関係のアップデートが拾えます。
最近は Windows に限らず、アプリケーションも通知せずに更新を掛ける物が増えて来ています。 Opera や Chrome しかり・・・
フリーウェア/シェアウェアの多くは未だ起動時に新しいバージョンを紹介するものがほとんどですが、インターネットに常時接続するアプリケーション以外ではこれも要らぬお節介です。 この判断はユーザーに任せられるべきもの、常用するものであれば定期的に、問題があれば更新の有無を確認するでしょうからね。 アプリケーションに勝手にネットに繋いではほしくないというのが正直な所、これが情報漏洩のリスクの一つなのは間違いありません。
Android アプリ方が酷いですが、アプリの仕様/動作には関わりのない情報迄アクセス権付与を要求し拒否すると使わせないという物もありますから要注意です。
【追記】
Photoshop CS2 が最初のフレームが出たところでＷａｉｔに入り、タイムアウトで落ちるという現象は WindowsUpdate.log や ReportingEvents.log 、adobegc.log 等を更新するタイミングで状態が変化する訳ではないようです。
何も通知がない状態で起動出来る様になったり、突然サブウインドウの上下関係が狂ったり、書き出しでロックしたりといろいろな状況が発生し始めており、だんだん動作しない期間が長くなって来ています。
【追記 2019/03/28】
問題を起こしたタイミングに何かファイルが出来ていないかチェックしてみたところ、Photoshop CS2 の起動エラーに関する情報をストックしているファイルが見付かりました。 エクスプローラの検索ツールで検索文字列を入力する枠に「アクセス日時：今日」と入れてやると、今日更新されたフォルダ/ファイルが全て拾い上げられます。 エラーになった時間付近を見てみた所、C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_Photoshop.exe_c～というフォルダが出来、その中に Report.wer というテキストファイルが格納されており、この中にエラーの状況が記録されていました。（もう面倒なので先は追っていませんが） これはエラー毎にフォルダが作られている様です。
で、これより前になにかないか探してみましたが結構な行数で・・・フィールド幅が変えられないので文字列が皆見えずで諦めました。
障害モジュールの名前： Photoshop.exe
例外コード ： c000041d ＆ c0000005
例外オフセット ： 00aa0947
エラーのたびに上記例外コード毎のフォルダ２つが出来、Report.wer というファイルが１つ入っています。
関連があると思われる物は皆バーで繋がれたコードですので、それが何を指すが分かりません(^^;)
どこかにダウンロードしたファイルとそれを展開した物があるはずなのですが・・・エクスプローラの検索が時間範囲では出来ないみたいなので探す手立てが思いつきません。 まぁ、わかったとしても
多分この例外コードは下記の URL にある物の様ですが、見ても何のことやら(^^;)
URL : https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
【追記 2019/03/29 今日一日の推移】
《フォルダ監視のログファイルの一部》
黄色： Photoshop CS2 が起動出来なかった時
薄緑： Photoshop CS2 が起動出来た時
05:33 C:\Windows\WindowsUpdate.log
05:34 Photoshop CS2 Start NG
07:18 C:\Windows\WindowsUpdate.log
07:18 C:\Windows\Temp\tw-2a84～
07:18 C:\Windows\SoftwareDistribution\Re--- 07:29 にベル
07:19 Photoshop CS2 Start NG
07:49 C:\Windows\Temp\adobegc.log
07:49 C:\Windows\Temp\adobegc.log
07:54 Photoshop CS2 Start NG
08:20 Photoshop CS2 Start NG
08:25 C:\Windows\WindowsUpdate.log
08:26 Photoshop CS2 Start NG
08:25 C:\Windows\SoftwareDistribution\Re--- 08:35 にベル
08:35 Photoshop CS2 Start NG
10:01 Photoshop CS2 Start NG
10:08 C:\Windows\WindowsUpdate.log OK
10:08 C:\Windows\SoftwareDistribution\Re--- 10:19 にベル
10:22 Photoshop CS2 Start NG
11:06 Photoshop CS2 Start NG
12:32 Photoshop CS2 Start NG
13:30 C:\Windows\WindowsUpdate.log
13:31 Photoshop CS2 Start OK
13:30 C:\Windows\SoftwareDistribution\Re--- 13:41 にベル
13:42 Photoshop CS2 Start NG
13:49 C:\Windows\Temp\adobegc.log
13:49 C:\Windows\Temp\adobegc.log
17:29 C:\Windows\WindowsUpdate.log
15:30 Photoshop CS2 Start NG
19:18 C:\Windows\WindowsUpdate.log
17:24 Photoshop CS2 Start NG
19:49 C:\Windows\Temp\adobegc.log
19:49 C:\Windows\Temp\adobegc.log
19:58 Photoshop CS2 Start NG
21:58 C:\Windows\WindowsUpdate.log
21:58 Photoshop CS2 Start OK
22:02:58 Photoshop CS2 Start NG
21:58 C:\Windows\SoftwareDistribution\Re--- 22:08 にベル
22:13:23 Photoshop CS2 Start NG
2019/03/30 06:13 C:\Windows\WindowsUpdate.log
06:13:58 Photoshop CS2 Start NG
ReportingEvents.log の更新日付は WindowsUpdate.log と同じ時間になっていますが、実際にフォルダには１０分経過して書かれている様です。
Adobe の更新チェックはスタートとターミネートが別建てになっていて必ずセットで Log ファイルが出来ます。 ここの所 これでは可否のステータスチェンジは起きていませんので、やはり原因は Windows 側なのでしょう。
Log で追える物を見ているだけでは何が起きているのかつかめそうにありません。 これを見る限り起動可能な時間は非常に短い様です。
動かなくなるタイミングや状態が変化しますのでバックグラウンドのサービス層でモジュールの同期を取りながらアップデートをしているのではないかと思われます。 定期アップデートの様に再起動後に入れ替わるのではなくオンタイムで変更して行っているのでしょう。
なので、起動して使用中に起動不能な状況に至っても、起動されているアプリケーションの操作は出来、一度閉じて再起動するとダメという状態になるのであろうと推測出来ます。
ただ、Photoshop CS2 は使える時間が日に日に短くなって行く様な・・・それにタイムアウトエラーになる箇所が変わったのか落ちるまでの時間が非常に長くなり、Photoshop CS2 の大外のフレームに“応答なし”が出ることがあります。
２９日は結局一度も使えませんでした。
【追記 2019/04/01 Report.wer からの臭い】
3/28 には Sig 項目（表題部とでも）だけしかみていませんでしたが、後半部を見ると LoadedModule[n]= という実行モジュールのローディングシーケンスではないかという部分があります。 この最後に wer.dll という Windows Error Reporter というモジュールがローディングされ、これ以降に OsInfo[n].Key= というＯＳに関わる情報と思われるものが羅列され、“FriendlyEventName=動作が停止しました”という文字列が入っています。 その後ろには原因がアプリケーションのクラッシュであることとアプリケーションの名前とパスが入っています。
で、この前にロードされたモジュールが一番臭いという事になりますが、それは全て C:\Windows\System32\IME\shared\imecfm.dll というものになっていした。 どうもこれは Windows10 固有のＩＭＥ関連のモジュールの様です。
まぁ、プロセスはマルチで動いていますので、原因モジュールがこれだという事にはなりませんが・・・
ひょっとすると Photoshop CS2 が32ビットアプリケーションなのが関係しているかもしれません。 Windows7 では COMCTL32.dll がなくてこれをコールしているアプリケーションが起動出来ないという問題があったみたいです。
リストを見ると他の .dll は System32 というフォルダからロードされているのに、２種ある COMCTL32.dll だけが WinSxS というフォルダ配下のえらく長いフォルダ名からロードされています。 コケる直前にロードされるのがＩＭＥ関連のファイルですので、なんだかキナ臭い(^^;)
これであれば Windows7 で経験済みでしょうからすぐに収まりそうなものですがね～
Photoshop CS2 が起動出来なくなる問題もエクスプローラのネットワークに関わる問題同様どういうタイミングで様相が変わるのかが捕捉出来ずフラストレーションが溜った為暫く追ってみましたが、結局の所力足らず、捕捉出来ませんでした。
・ 起動不能 ⇒ ブザー（WindowsUpdate） ⇒ 起動可能
⇒ 数分経過後起動不能
・ 起動不能 ⇒ ブザー（WindowsUpdate） ⇒ 起動不能
⇒ 数分経過後起動可能
・ 起動可能 ⇒ ブザー（AdobeUpdate1回目） ⇒ 起動不能
⇒ ブザー（AdobeUpdate2回目）
AdobeUpdateは２フェーズ１セットみたい
・ 起動不能 ⇒ ブザー（SoftwareDistribution) ⇒ 起動可能
・ 起動不能 ⇒ ブザーならず ⇒ 起動可能
遣り方が悪いのかもしれませんが、以上の様に追っている３つの事象の何れでも確実にこの組み合わせならば起動可能/不能になるという物がないのです(TT;)
ランダムに Photoshop CS2 の起動確認をしていると、やはり「フォルダ監視」で見ている一般的な Windows Update や ベンダーアプリの更新チェック等以外にアプリケーションの互換性確認に影響を与えるモジュールを変更するフェーズが動いていると思わざるを得ない動作をしますので今の所原因者の特定は諦めです。
この過程で メインの更新やMicrosoft アプリケーションの更新に関してはその日時を知る術が分かった事で良しとして、追跡を放棄・・・
まぁ、「フォルダ監視」はそのまま続けますので、監視フォルダに加わった変更についての日時だけはログとして残しておく事にします。
で、また分からない事が１つ・・・ C:\Windows\Temp\ の下に tw-xxxx-xxxx-xxxxxxx.tmp という名称のフォルダが１８個？作成される事がありますが、これはいったい何が作っている？ 中身を見ようとするのですが、「フォルダ監視」のブザーがなった直後に見てもいずれも空。 「フォルダ監視」の１分のディレイの間にフォルダを作って何らかの作業が完了しているという事なのでしょうか。 で、このフォルダは複数回分溜って一気に消される事もあれば数分後に消される事もあるのですが、この時 Windows Update も SoftwareDistribution も動いていない事がある・・・
《フォルダ監視が捉えた WindowsUpdate.log 更新回数》
03/16 03/17 03/18 03/19 03/20 03/21 03/22
06:08 06:22 05:59 06:11 06:06 06:16 06:43
06:50 07:35 09:59 08:31 09:07 16:29 12:32
07:50 08:41 16:45 09:41 10:31 20:13 13:34
08:16 15:56 18:57 13:05 13:40 16:45
09:07 18:18 16:45 16:45 18:40
09:31 20:27 19:08 20:03 19:17
10:21 22:16 20:25
16:45
17:14
18:07
上記の様に毎日信じられない位変更が掛かっています。 もしネットワークが見えなくなるのがこの回数トグルしたらとても仕事には使えませんよね。
実際には完全なフリップフロップにはなっていないので使えてはいますが、Photoshop CS2 では作業中にエクスプローラ系のモジュールが変わるのかファイルの読み出し/書き込みを選択するとコントロールが戻らず、タスクマネージャーで Photoshop CS2 をキルしなけらばならないという状況が実際に発生しています。
ここのところアンダーグラウンドでの Windows Update が頻発していますので、何時落ちるか分からず、コマメに中途でファイルを書き出して措かねば作業が全部パーになってしまいます。
タスクマネージャーの表示で Chrome の バックグラウンドタスクが分離して単独表示される件も繰り返し再現しています。 この２つの再現頻度は非常に高いです。
尚、エクスプローラのネットワーク接続端末の消失に関しては、今の処直っているみたいですね。
《 ReportingEvents.log で分かる事》
SoftwareDistribution 配下に出来る ReportingEvents.log の中には「2018-12 x64 ベース システム用 Windows 10 Version 1809 の累積更新プログラム (KB4471332)」や「悪意のあるソフトウェアの削除ツール x64 - 2018 年 12 月 (KB890830)」といった文字列が含まれており、エディタで「累積」や「悪意」、「(KB」で検索を掛ければ各々の更新タイミングを知る事が出来る様です。
<例>
{8297355F-C396-44C2-B02B-5E1B3F901E60} 2018-12-12 05:57:47:601+0900 1 181 [AGENT_INSTALLING_STARTED] 101 {710A7A2C-D4D2-4F65-826D-5B2E7C98B1F6} 1 0 UpdateOrchestrator Success Content Install Installation Started: Windows has started installing the following update: 2018-12 x64 ベース システム用 Windows 10 Version 1809 の累積更新プログラム (KB4471332) V4FEJtAsOEic6KMD.1.1.5.1.2.0
まぁ、ReportingEvents.log の中で「メインストリーム」アップデートだけでなく、Microsoft.～で示される Microsoftアプリケーションの更新も把握出来る事が分かっただけでも収穫でしょうか(^^)
Microsoft.WindowsAlarms/Microsoft.Xbox～/Microsoft.MSPaint といった文字列が入っていますので、「Microsoft.」で検索を掛ければアプリ関係のアップデートが拾えます。
最近は Windows に限らず、アプリケーションも通知せずに更新を掛ける物が増えて来ています。 Opera や Chrome しかり・・・
フリーウェア/シェアウェアの多くは未だ起動時に新しいバージョンを紹介するものがほとんどですが、インターネットに常時接続するアプリケーション以外ではこれも要らぬお節介です。 この判断はユーザーに任せられるべきもの、常用するものであれば定期的に、問題があれば更新の有無を確認するでしょうからね。 アプリケーションに勝手にネットに繋いではほしくないというのが正直な所、これが情報漏洩のリスクの一つなのは間違いありません。
Android アプリ方が酷いですが、アプリの仕様/動作には関わりのない情報迄アクセス権付与を要求し拒否すると使わせないという物もありますから要注意です。
【追記】
Photoshop CS2 が最初のフレームが出たところでＷａｉｔに入り、タイムアウトで落ちるという現象は WindowsUpdate.log や ReportingEvents.log 、adobegc.log 等を更新するタイミングで状態が変化する訳ではないようです。
何も通知がない状態で起動出来る様になったり、突然サブウインドウの上下関係が狂ったり、書き出しでロックしたりといろいろな状況が発生し始めており、だんだん動作しない期間が長くなって来ています。
【追記 2019/03/28】
問題を起こしたタイミングに何かファイルが出来ていないかチェックしてみたところ、Photoshop CS2 の起動エラーに関する情報をストックしているファイルが見付かりました。 エクスプローラの検索ツールで検索文字列を入力する枠に「アクセス日時：今日」と入れてやると、今日更新されたフォルダ/ファイルが全て拾い上げられます。 エラーになった時間付近を見てみた所、C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_Photoshop.exe_c～というフォルダが出来、その中に Report.wer というテキストファイルが格納されており、この中にエラーの状況が記録されていました。（もう面倒なので先は追っていませんが） これはエラー毎にフォルダが作られている様です。
で、これより前になにかないか探してみましたが結構な行数で・・・フィールド幅が変えられないので文字列が皆見えずで諦めました。
障害モジュールの名前： Photoshop.exe
例外コード ： c000041d ＆ c0000005
例外オフセット ： 00aa0947
エラーのたびに上記例外コード毎のフォルダ２つが出来、Report.wer というファイルが１つ入っています。
関連があると思われる物は皆バーで繋がれたコードですので、それが何を指すが分かりません(^^;)
どこかにダウンロードしたファイルとそれを展開した物があるはずなのですが・・・エクスプローラの検索が時間範囲では出来ないみたいなので探す手立てが思いつきません。 まぁ、わかったとしても
多分この例外コードは下記の URL にある物の様ですが、見ても何のことやら(^^;)
URL : https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
【追記 2019/03/29 今日一日の推移】
《フォルダ監視のログファイルの一部》
黄色： Photoshop CS2 が起動出来なかった時
薄緑： Photoshop CS2 が起動出来た時
05:33 C:\Windows\WindowsUpdate.log
05:34 Photoshop CS2 Start NG
07:18 C:\Windows\WindowsUpdate.log
07:18 C:\Windows\Temp\tw-2a84～
07:18 C:\Windows\SoftwareDistribution\Re--- 07:29 にベル
07:19 Photoshop CS2 Start NG
07:49 C:\Windows\Temp\adobegc.log
07:49 C:\Windows\Temp\adobegc.log
07:54 Photoshop CS2 Start NG
08:20 Photoshop CS2 Start NG
08:25 C:\Windows\WindowsUpdate.log
08:26 Photoshop CS2 Start NG
08:25 C:\Windows\SoftwareDistribution\Re--- 08:35 にベル
08:35 Photoshop CS2 Start NG
10:01 Photoshop CS2 Start NG
10:08 C:\Windows\WindowsUpdate.log OK
10:08 C:\Windows\SoftwareDistribution\Re--- 10:19 にベル
10:22 Photoshop CS2 Start NG
11:06 Photoshop CS2 Start NG
12:32 Photoshop CS2 Start NG
13:30 C:\Windows\WindowsUpdate.log
13:31 Photoshop CS2 Start OK
13:30 C:\Windows\SoftwareDistribution\Re--- 13:41 にベル
13:42 Photoshop CS2 Start NG
13:49 C:\Windows\Temp\adobegc.log
13:49 C:\Windows\Temp\adobegc.log
17:29 C:\Windows\WindowsUpdate.log
15:30 Photoshop CS2 Start NG
19:18 C:\Windows\WindowsUpdate.log
17:24 Photoshop CS2 Start NG
19:49 C:\Windows\Temp\adobegc.log
19:49 C:\Windows\Temp\adobegc.log
19:58 Photoshop CS2 Start NG
21:58 C:\Windows\WindowsUpdate.log
21:58 Photoshop CS2 Start OK
22:02:58 Photoshop CS2 Start NG
21:58 C:\Windows\SoftwareDistribution\Re--- 22:08 にベル
22:13:23 Photoshop CS2 Start NG
2019/03/30 06:13 C:\Windows\WindowsUpdate.log
06:13:58 Photoshop CS2 Start NG
ReportingEvents.log の更新日付は WindowsUpdate.log と同じ時間になっていますが、実際にフォルダには１０分経過して書かれている様です。
Adobe の更新チェックはスタートとターミネートが別建てになっていて必ずセットで Log ファイルが出来ます。 ここの所 これでは可否のステータスチェンジは起きていませんので、やはり原因は Windows 側なのでしょう。
Log で追える物を見ているだけでは何が起きているのかつかめそうにありません。 これを見る限り起動可能な時間は非常に短い様です。
動かなくなるタイミングや状態が変化しますのでバックグラウンドのサービス層でモジュールの同期を取りながらアップデートをしているのではないかと思われます。 定期アップデートの様に再起動後に入れ替わるのではなくオンタイムで変更して行っているのでしょう。
なので、起動して使用中に起動不能な状況に至っても、起動されているアプリケーションの操作は出来、一度閉じて再起動するとダメという状態になるのであろうと推測出来ます。
ただ、Photoshop CS2 は使える時間が日に日に短くなって行く様な・・・それにタイムアウトエラーになる箇所が変わったのか落ちるまでの時間が非常に長くなり、Photoshop CS2 の大外のフレームに“応答なし”が出ることがあります。
２９日は結局一度も使えませんでした。
【追記 2019/04/01 Report.wer からの臭い】
3/28 には Sig 項目（表題部とでも）だけしかみていませんでしたが、後半部を見ると LoadedModule[n]= という実行モジュールのローディングシーケンスではないかという部分があります。 この最後に wer.dll という Windows Error Reporter というモジュールがローディングされ、これ以降に OsInfo[n].Key= というＯＳに関わる情報と思われるものが羅列され、“FriendlyEventName=動作が停止しました”という文字列が入っています。 その後ろには原因がアプリケーションのクラッシュであることとアプリケーションの名前とパスが入っています。
で、この前にロードされたモジュールが一番臭いという事になりますが、それは全て C:\Windows\System32\IME\shared\imecfm.dll というものになっていした。 どうもこれは Windows10 固有のＩＭＥ関連のモジュールの様です。
まぁ、プロセスはマルチで動いていますので、原因モジュールがこれだという事にはなりませんが・・・
ひょっとすると Photoshop CS2 が32ビットアプリケーションなのが関係しているかもしれません。 Windows7 では COMCTL32.dll がなくてこれをコールしているアプリケーションが起動出来ないという問題があったみたいです。
リストを見ると他の .dll は System32 というフォルダからロードされているのに、２種ある COMCTL32.dll だけが WinSxS というフォルダ配下のえらく長いフォルダ名からロードされています。 コケる直前にロードされるのがＩＭＥ関連のファイルですので、なんだかキナ臭い(^^;)
これであれば Windows7 で経験済みでしょうからすぐに収まりそうなものですがね～
2019年 インプレッサ 夏支度 [睡夢庵の足]
【2019年 インプレッサ 夏支度】
３月２４日タイヤを夏タイヤに履き替えに行ってきました。
今年はついに一度も雪を見ず。 家族３人で使っていますが、誰も雪には会わずです。
今年もスタッドレスとしての評価は出来ず・・・こうなるとスタッドレスは勿体ないという事になって来ます。
これからも暖かくなる方向でしょうから、次はオールシーズンでしょうかね～
さて、MICHERIN X-ICE 3+ と TURANZA の印象ですが・・・
X-ICE 3+ は最初の一皮剥ける迄の間が一番おいしかった様な気がします。
当初はグリップも排水特性も期待値以上で流石ミシュラン、それと 94H も伊達ではないなという感じでしたが一皮剥けた辺りから感覚的には急激に劣化した（スタッドレスタイヤらしくなった）様な気がします。 スタッドレスとしてのサイプがちゃんと機能しだしたせいなのか、横方向のグリップもやはり落ちた様に感じます。 今は乗り出しの時のような速度でカーブに突っ込むとブロックが潰れる感覚が手に伝わって来て・・・とはいってもそれは TURANZA と比較してであって、REVO GZ よりは高い領域での話。
今日の行き帰りで比較してみると、
・ 当初に比べサイプから出ているチーッという様な高周波ノイズが
特に荒れた舗装路で気になる様になった。
・ 踏面の硬度が上がったせいかスタッドレスのグニャリ感が出る速度が
落ち、スキール音が出る様になった。
・ バネ下が躍る様な感覚が出て来た。 これは TURANZA でも感じるので
バネ下に対してダンパーの減衰力が変化した？
・ ウエット/制動特性はまだスタッドレスにしては上等。
TURANZA T001 205/55R16 91V はインプレッサスポーツのシャーシにあっているのでしょう、静かで乗り心地もグリップ感も相変わらずいいですね。
空気圧を前後共 0.1 しているせいかもしれませんが、双方共少しコツコツとした突き上げを感じる様になっています。
この時だけバネ下が重い感じ、ダンパー類が熟れて来たせいで当たりが強くなったのかも・・・
ブリザック REVO GZ ではゴムの硬度が増えて行ったのか経年と共にグニャリ感は薄れて行きましたが、３シーズン後半からは制動特性やウエット特性は急激に劣化しました。 X-ICE 3+ はもともと硬度が高めなのでどういう変化を見せるかですね。
トレッド面はやはりスタッドレスです、硬軟差があるのか面全体が荒れています。 ただ前輪外側のエッジは約１ｃｍ弱擦れてはいますが、 REVO GZ の時の様にささくれ立って捲れる様に削れていない所にトレッド面の硬度差やゴムの質が表れていると共に速度記号差が窺えます。
《タイヤ名 ：MICHERIN X-ICE 3+ 205/55R16 94H XL》
☆ 2018年度
装着期間 ：2018/11/27～2019/03/24
積算距離 ：16,084km
走行距離 ： 2,411km X-ICE 3+ 積算距離： 5,546km
☆ 2017年度
装着期間 ：2017/11/02 購入装着～2018/03/29
積算距離 ：8,025km
走行距離 ：3,135km
初年度はグリップがいいのでちょっと苛め過ぎたみたいですね。 それと私が乗った距離も多い。 前後輪差が 0.5mm ありますから倍以上の消耗をした見たい(^^;)>
中央部の溝で見た場合、前後輪の差が右 -0.46 左 -0.46 でしたが、今年は前後入れ替えていますので差が右 +0.21 左 +0.46 と逆転している所を見ても最初の消耗の激しさが凄い・・・
今年の摩耗は前輪で -0.22/-0.27mm 後輪で +0.06/-0.17 になりますので、大人しく乗れば平均 0.2mm/年 位とみればよいのでは？ 0.1mm/1200kmとして考えると最も浅いスノーマーク位置が 2.90mm ですので寿命は後 35,000km 位という事になりそうです。
帰って来て溝に挟まっている石の除去とトレッド面のチェックをし、計測した後洗浄、陰干しして倉庫に収納です。
前輪にはほとんど石は挟まっていませんでしたが、後輪は結構挟まっていました。 でも BLIZZAK シリーズと比べるとサイプやピットが少ない分小さな石は少なかったです。 左後輪は道路の轍を左に避けて走るせいか大きめの石が挟まり、頭が摩耗しているものが結構ありました。 高周波音が強く感じたのはこのせいがあるかもしれません。
《タイヤ名 ：BRIGESTON TURANZA T001 205/55R16 91V》
☆ 2018年度
使用期間 ：2018/03/29～2018/11/27
積算距離 ：13,673km
走行距離 ： 5,648km TURANZA 積算距離 ：10,538km
《取外し時の状態》
☆ 2017年度
使用期間 ：2017/05/25納車～2017/11/02
積算距離 ：8,025km
走行距離 ：4,890km
《取外し時の状態》
前後輪を入れ替えて取り付けますので、
右側前輪 左側前輪
7.06 → 6.51 -0.55 6.90 → 6.50 -0.40
右側後輪 左側後輪
6.40 → 6.44 +0.04 6.42 → 6.63 +0.21
グルーブの底がフラットではなくＵ字型に近く、タイヤゲージのピンのトップはフラットなのでどうしても誤差が出てしまいます。
上記の値からは前輪使用で 0.5mm 後輪使用で 0.1mm と考え、１スパン２年当たり 0.6mm 消耗という事になりそうです。
スリップサイン迄は現時点で 5mm ありますので、この消耗具合であれば寿命は８年位という事になりそうです。 とすればサイドのゴムの状態で交換時期を決める事になりますね。
３月２４日タイヤを夏タイヤに履き替えに行ってきました。
今年はついに一度も雪を見ず。 家族３人で使っていますが、誰も雪には会わずです。
今年もスタッドレスとしての評価は出来ず・・・こうなるとスタッドレスは勿体ないという事になって来ます。
これからも暖かくなる方向でしょうから、次はオールシーズンでしょうかね～
さて、MICHERIN X-ICE 3+ と TURANZA の印象ですが・・・
X-ICE 3+ は最初の一皮剥ける迄の間が一番おいしかった様な気がします。
当初はグリップも排水特性も期待値以上で流石ミシュラン、それと 94H も伊達ではないなという感じでしたが一皮剥けた辺りから感覚的には急激に劣化した（スタッドレスタイヤらしくなった）様な気がします。 スタッドレスとしてのサイプがちゃんと機能しだしたせいなのか、横方向のグリップもやはり落ちた様に感じます。 今は乗り出しの時のような速度でカーブに突っ込むとブロックが潰れる感覚が手に伝わって来て・・・とはいってもそれは TURANZA と比較してであって、REVO GZ よりは高い領域での話。
今日の行き帰りで比較してみると、
・ 当初に比べサイプから出ているチーッという様な高周波ノイズが
特に荒れた舗装路で気になる様になった。
・ 踏面の硬度が上がったせいかスタッドレスのグニャリ感が出る速度が
落ち、スキール音が出る様になった。
・ バネ下が躍る様な感覚が出て来た。 これは TURANZA でも感じるので
バネ下に対してダンパーの減衰力が変化した？
・ ウエット/制動特性はまだスタッドレスにしては上等。
TURANZA T001 205/55R16 91V はインプレッサスポーツのシャーシにあっているのでしょう、静かで乗り心地もグリップ感も相変わらずいいですね。
空気圧を前後共 0.1 しているせいかもしれませんが、双方共少しコツコツとした突き上げを感じる様になっています。
この時だけバネ下が重い感じ、ダンパー類が熟れて来たせいで当たりが強くなったのかも・・・
ブリザック REVO GZ ではゴムの硬度が増えて行ったのか経年と共にグニャリ感は薄れて行きましたが、３シーズン後半からは制動特性やウエット特性は急激に劣化しました。 X-ICE 3+ はもともと硬度が高めなのでどういう変化を見せるかですね。
トレッド面はやはりスタッドレスです、硬軟差があるのか面全体が荒れています。 ただ前輪外側のエッジは約１ｃｍ弱擦れてはいますが、 REVO GZ の時の様にささくれ立って捲れる様に削れていない所にトレッド面の硬度差やゴムの質が表れていると共に速度記号差が窺えます。
《タイヤ名 ：MICHERIN X-ICE 3+ 205/55R16 94H XL》
☆ 2018年度
装着期間 ：2018/11/27～2019/03/24
積算距離 ：16,084km
走行距離 ： 2,411km X-ICE 3+ 積算距離： 5,546km
| 右 | 左 | |||||
| 位置 | 深さ | 硬度 | 深さ | 硬度 | ||
| 中央全深さ | 7.61 | 60 | 7.56 | 60 | ||
| 前 | 円周溝 | 外側スノー | 3.12 | ～65 | 2.90 | ～65 |
| 中央スリップ | 6.05 | 6.07 | ||||
| 内側スノー | 3.08 | 2.96 | ||||
| 中央全深さ | 7.40 | 63 | 7.17 | 63 | ||
| 後 | 円周溝 | 外側スノー | 2.53 | ～66 | 2.64 | ～65 |
| 中央スリップ | 5.68 | 5.58 | ||||
| 内側スノー | 2.53 | 2.57 | ||||
☆ 2017年度
装着期間 ：2017/11/02 購入装着～2018/03/29
積算距離 ：8,025km
走行距離 ：3,135km
| 右 | 左 | |||||
| 位置 | 深さ | 硬度 | 深さ | 硬度 | ||
| 中央全深さ | 7.34 | 60 | 7.34 | 60 | ||
| 前 | 円周溝 | 外側スノー | 2.75 | ～62 | 2.80 | ～62 |
| 中央スリップ | 5.76 | 5.61 | ||||
| 内側スノー | 2.80 | 2.90 | ||||
| 中央全深さ | 7.83 | 55 | 7.83 | 55 | ||
| 後 | 円周溝 | 外側スノー | 3.55 | ～60 | 3.37 | ～60 |
| 中央スリップ | 6.23 | 6.23 | ||||
| 内側スノー | 3.60 | 3.55 | ||||
初年度はグリップがいいのでちょっと苛め過ぎたみたいですね。 それと私が乗った距離も多い。 前後輪差が 0.5mm ありますから倍以上の消耗をした見たい(^^;)>
中央部の溝で見た場合、前後輪の差が右 -0.46 左 -0.46 でしたが、今年は前後入れ替えていますので差が右 +0.21 左 +0.46 と逆転している所を見ても最初の消耗の激しさが凄い・・・
今年の摩耗は前輪で -0.22/-0.27mm 後輪で +0.06/-0.17 になりますので、大人しく乗れば平均 0.2mm/年 位とみればよいのでは？ 0.1mm/1200kmとして考えると最も浅いスノーマーク位置が 2.90mm ですので寿命は後 35,000km 位という事になりそうです。
帰って来て溝に挟まっている石の除去とトレッド面のチェックをし、計測した後洗浄、陰干しして倉庫に収納です。
前輪にはほとんど石は挟まっていませんでしたが、後輪は結構挟まっていました。 でも BLIZZAK シリーズと比べるとサイプやピットが少ない分小さな石は少なかったです。 左後輪は道路の轍を左に避けて走るせいか大きめの石が挟まり、頭が摩耗しているものが結構ありました。 高周波音が強く感じたのはこのせいがあるかもしれません。
《タイヤ名 ：BRIGESTON TURANZA T001 205/55R16 91V》
☆ 2018年度
使用期間 ：2018/03/29～2018/11/27
積算距離 ：13,673km
走行距離 ： 5,648km TURANZA 積算距離 ：10,538km
《取外し時の状態》
| 位置 | 右 | 左 | ||||
| 深さ | 硬度 | 深さ | 硬度 | |||
| 前 | アウター側横溝 | 4.58 | 63 | 4.31 | 63 | |
| 円周溝 | 外側 | 6.32 | 6.55 | |||
| 中央 | 6.51 | 6.50 | ||||
| 内側 | 6.34 | 6.42 | ||||
| 後 | アウター側横溝 | 4.68 | 63 | 4.58 | 63 | |
| 円周溝 | 外側 | 6.39 | 6.63 | |||
| 中央 | 6.44 | 6.63 | ||||
| 内側 | 6.32 | 6.40 | ||||
☆ 2017年度
使用期間 ：2017/05/25納車～2017/11/02
積算距離 ：8,025km
走行距離 ：4,890km
《取外し時の状態》
| 位置 | 右 | 左 | ||||
| 深さ | 硬度 | 深さ | 硬度 | |||
| 前 | アウター側横溝 | 4.25 | 63 | 4.35 | 63 | |
| 円周溝 | 外側 | 6.39 | 6.39 | |||
| 中央 | 6.40 | 6.42 | ||||
| 内側 | 6.43 | 6.40 | ||||
| 後 | アウター側横溝 | 4.86 | 63 | 4.88 | 63 | |
| 円周溝 | 外側 | 6.62 | 6.67 | |||
| 中央 | 7.06 | 6.90 | ||||
| 内側 | 6.81 | 6.84 | ||||
前後輪を入れ替えて取り付けますので、
右側前輪 左側前輪
7.06 → 6.51 -0.55 6.90 → 6.50 -0.40
右側後輪 左側後輪
6.40 → 6.44 +0.04 6.42 → 6.63 +0.21
グルーブの底がフラットではなくＵ字型に近く、タイヤゲージのピンのトップはフラットなのでどうしても誤差が出てしまいます。
上記の値からは前輪使用で 0.5mm 後輪使用で 0.1mm と考え、１スパン２年当たり 0.6mm 消耗という事になりそうです。
スリップサイン迄は現時点で 5mm ありますので、この消耗具合であれば寿命は８年位という事になりそうです。 とすればサイドのゴムの状態で交換時期を決める事になりますね。
追伸 Google Chrome の Software Reporter Tool [睡夢庵の電脳環境]
【追伸 Google Chrome の Software Reporter Tool 】
Google Chrome の Software Reporter Tool に関して今まで SwReporter 配下の実行モジュールを気にしていましたが、Google フォルダ配下には Software Reporter Tool とフォルダがあり、実行ログや結果はどうもこの中に収められている様です。
この中には
・ software_reporter_tool.log 実行状況の記録？
・ software_reporter_tool-crashpad.log 各バージョンの実行可否記録
バージョン毎の実行日を記録
・ software_reporter_tool-sandbox.log 実行結果の記録？
の３つが出来ており、多分ここにある reports というフォルダに結果が納められるのではないかと思います。
私のケースでは、いつも見ても空でしたので、ブロックに成功しているのかレポートが送られてしまい消去されたのかいずれかでしょう。
今のところ
・ 02/22-38.191.200
・ 03/07-38.193.200
・ 03/15-39.194.200
・ 03/21-39.195.200
の４つは連続してブロック出来たみたいです。
現在の所フォルダ監視という手法で SwReporter 配下をチェックしていますが、より確実な方法があるにはあるのですが・・・
プログラムの実行を出来なくする方法もありますが、これは新しいフォルダが作られこの中にプログラムが入る為効果なし。
もう１つは C:\Users\USERNAME\AppData\Local\Google\Chrome\User Data\SwReporter\ の中身のアクセスを出来なくしてしまう方法です。
これは SwReporter のアクセス権を変えてしまう方法なので、ユーザーからは削除出来ないフォルダ/ファイルを作ってしまうはずなので実行を躊躇しています。
完全にこれを殺すにはこれしかないのでしょうが・・・
この方法については下記のサイトに解説があります。
URL : https://www.ghacks.net/2018/01/20/how-to-block-the-chrome-software-reporter-tool-software_reporter_tool-exe/
やるかやらぬかは貴方次第(^^;)>
Google Chrome の Software Reporter Tool に関して今まで SwReporter 配下の実行モジュールを気にしていましたが、Google フォルダ配下には Software Reporter Tool とフォルダがあり、実行ログや結果はどうもこの中に収められている様です。
この中には
・ software_reporter_tool.log 実行状況の記録？
・ software_reporter_tool-crashpad.log 各バージョンの実行可否記録
バージョン毎の実行日を記録
・ software_reporter_tool-sandbox.log 実行結果の記録？
の３つが出来ており、多分ここにある reports というフォルダに結果が納められるのではないかと思います。
私のケースでは、いつも見ても空でしたので、ブロックに成功しているのかレポートが送られてしまい消去されたのかいずれかでしょう。
今のところ
・ 02/22-38.191.200
・ 03/07-38.193.200
・ 03/15-39.194.200
・ 03/21-39.195.200
の４つは連続してブロック出来たみたいです。
現在の所フォルダ監視という手法で SwReporter 配下をチェックしていますが、より確実な方法があるにはあるのですが・・・
プログラムの実行を出来なくする方法もありますが、これは新しいフォルダが作られこの中にプログラムが入る為効果なし。
もう１つは C:\Users\USERNAME\AppData\Local\Google\Chrome\User Data\SwReporter\ の中身のアクセスを出来なくしてしまう方法です。
これは SwReporter のアクセス権を変えてしまう方法なので、ユーザーからは削除出来ないフォルダ/ファイルを作ってしまうはずなので実行を躊躇しています。
完全にこれを殺すにはこれしかないのでしょうが・・・
この方法については下記のサイトに解説があります。
URL : https://www.ghacks.net/2018/01/20/how-to-block-the-chrome-software-reporter-tool-software_reporter_tool-exe/
やるかやらぬかは貴方次第(^^;)>
ＮＵＲＯ？ 我が家のインターネット環境 [睡夢庵の電脳環境]
【ＮＵＲＯ？ 我が家のインターネット環境】
最近ＮＵＲＯの高速ネットワークのサービス地域も広がって来たようで、ネットや Youtube 上で話題になり始めたみたいですね。
で、ちょっと自宅のネットワークの状態をチェックしてみる事にしました。
あまり速度が出ていない様であれば切り替えを検討してみるか。 で、郵便番号を入れてっと・・・あちゃ～まだ申し込めないとさ。
申し込める人、羨ましいな～
繋がるようになったら切り替えようか・・・
それと先月でしたか、Asahi-net に接続して使用していた所ドンと切れてしまうという事故がありました。 プロバイダーに関しては工事/アップデート/障害等で接続が切れ、暫く復旧しない事があって困った経験から２つのプロバイダーと契約したままにしています。
《現在迄の接続/プロバイダー契約》
インターネット接続契約： インターネットはカプラーの時代から使用
電話回線モデム接続 ～2003?迄
Ｂフレッツ ～2010迄
フレッツ光ネクスト ファミリーギガライン
プロバイダー契約
使用プロバイダー推移 ASC ⇒ IIJ4U ⇒ so-net
Nifty ⇒ Bigrobe ⇒ asahi-net
so-net ： 家族を含むメールおよびブログ用として 1996.05から使用
asahi-net ： ホームページ用とその為のメール他 1998.12から使用
とＦＴＰ用途
初期はプロバイダーの選択肢も余りありませんでしたし、当時は会社ではネットを使っていませんでしたので、社用を含め目的別に当時お付き合いがあったチャンネルで複数と契約していました。
プロバイダーの選択は当時の東京地区のバックボーンに対しての接続回線容量が大きく、必要とするサービスがある所を選びました。
Asahi-net は当時としてはバックボーンへの接続も多く、ホームページの容量が大きく FTP と共用で使えた事、So-net は Sinfony/InfoSphere 経由で JPIX/KDDI/NSPIXP2 に繋がっており、それぞれの回線容量も大きくバイパス経路を幾つも持っていた事とブログが使い易く容量も大きかったが決め手でした。
バックボーンへの回線容量が少ないプロバイダーやホームページサービスを選ぶと極端に速度が変化して作業に支障が出ますので、当時はこれが最優先でした。
利用料金：
フレッツ光ネクスト ファミリーギガライン ￥5,400-
同上 ２年割継続 －￥700-
So-net ￥1,200-
asahi-net ￥1,000-
合計 ￥6,900-
ＦＴＰを諦めてクラウドサービスに置き換え、ホームページやこのブログを止めてメールをキャリアメールに切り替えればいいのでしょうが、登録しているメールアドレスを変えなければならない所やこれがＩＤになっている所が結構な数があって・・・わたしだけならですがプロバイダーのメールアドレスを使っているのが３名４アドレスなのでちょっとね～ で、プロバイダー契約はそのままにせざるを得ないですね。
《ネットワーク接続機器の数》
以前はＰＣの数も４台と少なかったですし、ＤＨＣＰ割り当てと固定ＩＰが混在出来たコレガのルーターを使っていたので、私のホームページを触るＰＣのＩＰを固定して asahi-net に繋ぎ、他はDHCP割り当てでメイン側の so-net に繋いでいました。
しかし、コレガのルーターが壊れ、ヤマハのＮＶＲ-５００に変えたらこの混在が出来なかった為、固定化を躊躇している内に接続する台数があれよあれよという間に増えてしまい、また色々あって機器の管理は夫々に任せる事にしたので２プロバイダーに分配して接続する設定は諦めて手動でどちらかに接続していました。
今回ちょっとダウンが長かったので、また双方常時接続に戻しています。 こうしておけば今回の様に全く繋がらない状態になれば自動的に切り替わるはず・・・
で、今はヤマハのＤＨＣＰサービス頼り
Wi-Fi ルーターは IP アドレスを固定し、各々に接続する機器の Mac アドレスを設定して接続を制限しています。
現在自宅のネットワークに接続されている機器は
・ 有線ルーター １台
・ スイッチングハブ ２台
・ 無線ルータ ３台
-------------------------------
・ デスクトップＰＣ ３台
・ ノートＰＣ ５台
・ タブレット ２台
・ スマホ ３台
・ 複合機 １台
・ ＴＶ ５台
最大端末台数 １９台
これに息子が帰ってくると最大３台使いますから・・・(^^;)
昼間は上記の内７～１０台が繋がっています。
《ネットワーク接続》
ONU━NVR-500━┳━━━━━━━━Panasonic MX3/Windows8.1
┃
┣LSW4-GT-5NS ┳━i7-7000/Windows10
┃ ┣━(E6850/WindowsXP)
┃ ┣━Toshiba REGZA 43C310X
┃ ┗━Archer C9 ━━━━━━┳━TAB4 8 Plus
┃ ┗━iPhone
┃
┣WSR-2533DHP ┳━iPhone6
┃ ┣━iPhone7
┃ ┗━複合機
┃
┗LSW8-GT-8DS ┳━Fujitsu Notebook
┣━NEC Notebook
┣━Toshiba TV
┣━Panasonic TV
┣━Panasonic TV
┣━メディアコンセント DMC10F1
┗━WHR-G301N ━━━┳━Windows7 PC
水色：有線ルーター ┣━Dynabook
緑色：スイッチングハブ ┣━Macbook Pro
黄色：無線ルーター ┗━Labvie Tab
《回線接続速度評価》
回線 ： フレッツ光ネクスト ファミリーギガライン
プロバイダー： So-net
ブラウザ ： Firefox ＆ speedtest.net ＆ OPEN Project
計測日 ： 2019/03/12
MX3/Windows8.1 有線(10:56) 633/632Mbps
i7-7700/Windows10 有線(11:02) 611/682Mbps
2017.05-2019.03 間のベスト 671/682Mbps
ワースト 297/334Mbps
i7-7700 で 368/513Mbpsの時
i7-7700 と MX3で同時に実施しても 合計 419/507Mbps
TAB4 8 Plus Archer C9-5G(11:04) 226/237Mbps
Archer C9-4G(11:12) 45/40Mbps
WSR-2533DHP-5G(11:19) 101/83Mbps
WSR-2533DHP-4G(11:16) 26/33Mbps
《信号レベルと回線速度》
Archer C9 との直線距離 約２ｍ 5G：-43～-48dBm（433Mbps)
4G：-43～-47dBm
WSR-2533DHP との直線距離 約７ｍ 5G：-78～-82dBm（32-120Mbps）
4G：-62～-63dBm（72Mbps）
計測アプリ：上記は Keuwlsoft WiFi Analyserによる RSSI値 目視結果
TAB4 8 Plus がシングルですので最大 433Mbps、Archer との間は最大速度で接続はされていますが、実質は半分位になるみたいです。
信号レベルの揺れを見ているとすぐ傍ですので当たり前と言えばですが Archer C9 の方が安定しています。 WSR-2533DHP は間に複数の壁を挟んでいるせいもあるしょうがレベルの揺れが大きいですし、5G では時に完全に切れてしまい端末側が回線を切り替えてしまうという現象も出ていました。
《考察》
現状ではＮＵＲＯサービス提供区域外ですので、フレッツ光⇒ＮＵＲＯ光の切り替えは残念ながら出来ませんが・・・
☆ 速度面
現状は有線接続テストしてみた範囲ではダウン側も最低でも 300Mbps 以上出ていますし、ほとんどの場合 400Mbps 以上ですのでこれだけの数を繋いだ状態でも遅いと感じる事はありません。 アップ側はほぼ 500Mbps以上。
Fing でみて他にデスクトップ１台、ノートブック３台、タブレット２台、ＴＶ１台が接続されている状態で上記の速度が出ています。 これは asahi-net 経由でも変わりませんので速度については現状に不満はありません。 アップロード側には速度は要りませんし。
Youtube 等で輪っかが回ったりでスムーズに再生出来ない物は、ダウンローダで確認すると送出側が kbps 台と遅いのでこの改善は望めませんし・・・
となれば現段階ではこの面からは切り替える必要性はありません。
☆ 内部ネットワーク＆ハード面
一応ルーター・スイッチングハブもＧＢ対応のもので構成していますが、端末間転送では 100Mbps を超える事はほとんどありませんし、インターネット間でも実効でＧＢが必要な作業は私の手元にはありませんので現状で問題はありません。
ただ、フレッツ情報サイトとの接続が現状のハードウェアの組み合わせと環境設定ではどうも実現出来ないのがネック・・・ルーターではサイトに繋がっているのですが回線テストを通ってくれずメンバー登録に行けません。 この為ＮＴＴとの遣り取りが電話以外なく、いつも混雑が酷くて１０分待っても繋がらない(TT;)。 なので浮気してみたくなっています。
☆ 費用面
ＮＵＲＯ光に切り替えても費用的には安くなりません。
というのは、使用しているプロバイダーのサービスがＮＵＲＯでは提供されていない様なので、現状のプロバイダー契約は切る訳にも行かず・・・
現在のキャンペーン中に契約出来れば儲けものになるのですが、サービス未提供地域ですので・・・
☆ 付帯するサービスに関して
ＮＵＲＯ関連のサイトでは提供されるサービスに関するほしい情報が見当たりません。
プロバイダーの代わりも果たすのであれば、最低メール位はあるのかとか・・・
他のプロバイダーを使ってもよいのかなど・・・
他の複数プロバイダーと同時に接続し、ＮＵＲＯのプロバイダー/セキュリティチェックをバイパスする様な設定が出来るかですね。
と言った感じで現状のＮＵＲＯのサイトの説明ではわたしの様に時代物を色々引き摺っている者はちょっと踏ん切りはつきません。(^^;)
Youtube でみると１Ｇ近く出てホクホクという報告もありますが、こうなってくるとサービス提供側が質を維持する為にＩＰ毎の接続速度を制限せざるを得なくなって来るでしょうね。
最近ＮＵＲＯの高速ネットワークのサービス地域も広がって来たようで、ネットや Youtube 上で話題になり始めたみたいですね。
で、ちょっと自宅のネットワークの状態をチェックしてみる事にしました。
あまり速度が出ていない様であれば切り替えを検討してみるか。 で、郵便番号を入れてっと・・・あちゃ～まだ申し込めないとさ。
申し込める人、羨ましいな～
繋がるようになったら切り替えようか・・・
それと先月でしたか、Asahi-net に接続して使用していた所ドンと切れてしまうという事故がありました。 プロバイダーに関しては工事/アップデート/障害等で接続が切れ、暫く復旧しない事があって困った経験から２つのプロバイダーと契約したままにしています。
《現在迄の接続/プロバイダー契約》
インターネット接続契約： インターネットはカプラーの時代から使用
電話回線モデム接続 ～2003?迄
Ｂフレッツ ～2010迄
フレッツ光ネクスト ファミリーギガライン
プロバイダー契約
使用プロバイダー推移 ASC ⇒ IIJ4U ⇒ so-net
Nifty ⇒ Bigrobe ⇒ asahi-net
so-net ： 家族を含むメールおよびブログ用として 1996.05から使用
asahi-net ： ホームページ用とその為のメール他 1998.12から使用
とＦＴＰ用途
初期はプロバイダーの選択肢も余りありませんでしたし、当時は会社ではネットを使っていませんでしたので、社用を含め目的別に当時お付き合いがあったチャンネルで複数と契約していました。
プロバイダーの選択は当時の東京地区のバックボーンに対しての接続回線容量が大きく、必要とするサービスがある所を選びました。
Asahi-net は当時としてはバックボーンへの接続も多く、ホームページの容量が大きく FTP と共用で使えた事、So-net は Sinfony/InfoSphere 経由で JPIX/KDDI/NSPIXP2 に繋がっており、それぞれの回線容量も大きくバイパス経路を幾つも持っていた事とブログが使い易く容量も大きかったが決め手でした。
バックボーンへの回線容量が少ないプロバイダーやホームページサービスを選ぶと極端に速度が変化して作業に支障が出ますので、当時はこれが最優先でした。
利用料金：
フレッツ光ネクスト ファミリーギガライン ￥5,400-
同上 ２年割継続 －￥700-
So-net ￥1,200-
asahi-net ￥1,000-
合計 ￥6,900-
ＦＴＰを諦めてクラウドサービスに置き換え、ホームページやこのブログを止めてメールをキャリアメールに切り替えればいいのでしょうが、登録しているメールアドレスを変えなければならない所やこれがＩＤになっている所が結構な数があって・・・わたしだけならですがプロバイダーのメールアドレスを使っているのが３名４アドレスなのでちょっとね～ で、プロバイダー契約はそのままにせざるを得ないですね。
《ネットワーク接続機器の数》
以前はＰＣの数も４台と少なかったですし、ＤＨＣＰ割り当てと固定ＩＰが混在出来たコレガのルーターを使っていたので、私のホームページを触るＰＣのＩＰを固定して asahi-net に繋ぎ、他はDHCP割り当てでメイン側の so-net に繋いでいました。
しかし、コレガのルーターが壊れ、ヤマハのＮＶＲ-５００に変えたらこの混在が出来なかった為、固定化を躊躇している内に接続する台数があれよあれよという間に増えてしまい、また色々あって機器の管理は夫々に任せる事にしたので２プロバイダーに分配して接続する設定は諦めて手動でどちらかに接続していました。
今回ちょっとダウンが長かったので、また双方常時接続に戻しています。 こうしておけば今回の様に全く繋がらない状態になれば自動的に切り替わるはず・・・
で、今はヤマハのＤＨＣＰサービス頼り
Wi-Fi ルーターは IP アドレスを固定し、各々に接続する機器の Mac アドレスを設定して接続を制限しています。
現在自宅のネットワークに接続されている機器は
・ 有線ルーター １台
・ スイッチングハブ ２台
・ 無線ルータ ３台
-------------------------------
・ デスクトップＰＣ ３台
・ ノートＰＣ ５台
・ タブレット ２台
・ スマホ ３台
・ 複合機 １台
・ ＴＶ ５台
最大端末台数 １９台
これに息子が帰ってくると最大３台使いますから・・・(^^;)
昼間は上記の内７～１０台が繋がっています。
《ネットワーク接続》
ONU━NVR-500━┳━━━━━━━━Panasonic MX3/Windows8.1
┃
┣LSW4-GT-5NS ┳━i7-7000/Windows10
┃ ┣━(E6850/WindowsXP)
┃ ┣━Toshiba REGZA 43C310X
┃ ┗━Archer C9 ━━━━━━┳━TAB4 8 Plus
┃ ┗━iPhone
┃
┣WSR-2533DHP ┳━iPhone6
┃ ┣━iPhone7
┃ ┗━複合機
┃
┗LSW8-GT-8DS ┳━Fujitsu Notebook
┣━NEC Notebook
┣━Toshiba TV
┣━Panasonic TV
┣━Panasonic TV
┣━メディアコンセント DMC10F1
┗━WHR-G301N ━━━┳━Windows7 PC
水色：有線ルーター ┣━Dynabook
緑色：スイッチングハブ ┣━Macbook Pro
黄色：無線ルーター ┗━Labvie Tab
《回線接続速度評価》
回線 ： フレッツ光ネクスト ファミリーギガライン
プロバイダー： So-net
ブラウザ ： Firefox ＆ speedtest.net ＆ OPEN Project
計測日 ： 2019/03/12
MX3/Windows8.1 有線(10:56) 633/632Mbps
i7-7700/Windows10 有線(11:02) 611/682Mbps
2017.05-2019.03 間のベスト 671/682Mbps
ワースト 297/334Mbps
i7-7700 で 368/513Mbpsの時
i7-7700 と MX3で同時に実施しても 合計 419/507Mbps
TAB4 8 Plus Archer C9-5G(11:04) 226/237Mbps
Archer C9-4G(11:12) 45/40Mbps
WSR-2533DHP-5G(11:19) 101/83Mbps
WSR-2533DHP-4G(11:16) 26/33Mbps
《信号レベルと回線速度》
Archer C9 との直線距離 約２ｍ 5G：-43～-48dBm（433Mbps)
4G：-43～-47dBm
WSR-2533DHP との直線距離 約７ｍ 5G：-78～-82dBm（32-120Mbps）
4G：-62～-63dBm（72Mbps）
計測アプリ：上記は Keuwlsoft WiFi Analyserによる RSSI値 目視結果
TAB4 8 Plus がシングルですので最大 433Mbps、Archer との間は最大速度で接続はされていますが、実質は半分位になるみたいです。
信号レベルの揺れを見ているとすぐ傍ですので当たり前と言えばですが Archer C9 の方が安定しています。 WSR-2533DHP は間に複数の壁を挟んでいるせいもあるしょうがレベルの揺れが大きいですし、5G では時に完全に切れてしまい端末側が回線を切り替えてしまうという現象も出ていました。
《考察》
現状ではＮＵＲＯサービス提供区域外ですので、フレッツ光⇒ＮＵＲＯ光の切り替えは残念ながら出来ませんが・・・
☆ 速度面
現状は有線接続テストしてみた範囲ではダウン側も最低でも 300Mbps 以上出ていますし、ほとんどの場合 400Mbps 以上ですのでこれだけの数を繋いだ状態でも遅いと感じる事はありません。 アップ側はほぼ 500Mbps以上。
Fing でみて他にデスクトップ１台、ノートブック３台、タブレット２台、ＴＶ１台が接続されている状態で上記の速度が出ています。 これは asahi-net 経由でも変わりませんので速度については現状に不満はありません。 アップロード側には速度は要りませんし。
Youtube 等で輪っかが回ったりでスムーズに再生出来ない物は、ダウンローダで確認すると送出側が kbps 台と遅いのでこの改善は望めませんし・・・
となれば現段階ではこの面からは切り替える必要性はありません。
☆ 内部ネットワーク＆ハード面
一応ルーター・スイッチングハブもＧＢ対応のもので構成していますが、端末間転送では 100Mbps を超える事はほとんどありませんし、インターネット間でも実効でＧＢが必要な作業は私の手元にはありませんので現状で問題はありません。
ただ、フレッツ情報サイトとの接続が現状のハードウェアの組み合わせと環境設定ではどうも実現出来ないのがネック・・・ルーターではサイトに繋がっているのですが回線テストを通ってくれずメンバー登録に行けません。 この為ＮＴＴとの遣り取りが電話以外なく、いつも混雑が酷くて１０分待っても繋がらない(TT;)。 なので浮気してみたくなっています。
☆ 費用面
ＮＵＲＯ光に切り替えても費用的には安くなりません。
というのは、使用しているプロバイダーのサービスがＮＵＲＯでは提供されていない様なので、現状のプロバイダー契約は切る訳にも行かず・・・
現在のキャンペーン中に契約出来れば儲けものになるのですが、サービス未提供地域ですので・・・
☆ 付帯するサービスに関して
ＮＵＲＯ関連のサイトでは提供されるサービスに関するほしい情報が見当たりません。
プロバイダーの代わりも果たすのであれば、最低メール位はあるのかとか・・・
他のプロバイダーを使ってもよいのかなど・・・
他の複数プロバイダーと同時に接続し、ＮＵＲＯのプロバイダー/セキュリティチェックをバイパスする様な設定が出来るかですね。
と言った感じで現状のＮＵＲＯのサイトの説明ではわたしの様に時代物を色々引き摺っている者はちょっと踏ん切りはつきません。(^^;)
Youtube でみると１Ｇ近く出てホクホクという報告もありますが、こうなってくるとサービス提供側が質を維持する為にＩＰ毎の接続速度を制限せざるを得なくなって来るでしょうね。
Windows Update どうにかなりませんかね～ [睡夢庵の電脳環境]
【 Windows Update どうにかなりませんかね～ 】
従来はマンスリーアップデート以外のアップデートも殆どはＫＢ番号付きで同列にレポートされていましたが、Windows10/8.1 共にマンスリーアップデート以外はほとんどアンダーグラウンドで行われる様になってしまいました。 それも頻繁に。
昨日はエクスプローラのモジュールの一部が変わった様で突如アプリケーションレベルでのファイルコピー動作が途中でダウンしてしまいました。 で、その後は Windows10/8.1 共に相手が見えなくなってしまいました。 再起動してみましたが、ダメ・・・。
その直後、「フォルダー監視」のブザーが鳴ったので確認してみると、変更があったのは WindowsUpdate.log とレポートして来ていました。 で、再度ネットワークを見てみますと Windows8.1 からは見える様になっていました。 でも Windows10 側には１台も出ていません。
Windows10 だけだと思っていましたがどうもそうではない様で、今月のマンスリーアップデートでは双方のネットワークマネージメントは一体どうなっているのでしょうかね。 こんな状態では企業では使えないでしょう。 ひょっとすると Windows Server 2019 との間なら問題は起きてないから良いとでも？
個人や中小ではわざわざ Server OS なんて入れずにネットワークを構成しますよね。 その場合サーバー代りに使うＰＣのドライブを共有設定し、各ＰＣは全てパスワードログオンという設定にして、ルーターの設定をＤＨＣＰのＩＰアドレス範囲を設定し、Ｍａｃアドレスでブロックする様にして勝手に端末を接続出来ない様にする事で済ますでしょう。
サーバー/端末間の相互参照ではエクスプローラのモジュールが使われますので、これが安定していなくては始まりませんが、Windows10 が加わってからはどうも安定しません。
今迄のトラブルはエクスプローラもしくはアプリケーションのファイル選択でアクセス出来なくなる位でしたが、今回は既にコピー動作をしている接続が切れてしまいましたので、ちょっと重症なトラブルの発生です。
Windows10 絡みのエクスプローラのトラブルは皆直らず繰り返し再発していますし、その復旧に酷い時には１日以上掛かっています。
これは今までは纏めて掛けていた一般的な細かなアップデートをバックグラウンドにして直ちに修正する様にし、対応速度を上げようとしたのかもしれませんが、これでは逆効果になったのでは？ それも最も重要なファイルマネージメントの基幹であるエクスプローラの表に出る部分で再発を繰り返す様では・・・
因みに各ＯＳのサポート期限は
メインストリーム終了日 延長サポいート終了日
Windows7 2015/01/13 2020/01/14
Windows8.1 2018/01/09 2023/01/11
Windows10 2020/10/13 2025/10/14
Windows のサポート期限は上記の通りですから、Windows7 も含め延長サポート終了迄相互の交換性は保証されなければならないはずですよね。
従来はマンスリーアップデート以外のアップデートも殆どはＫＢ番号付きで同列にレポートされていましたが、Windows10/8.1 共にマンスリーアップデート以外はほとんどアンダーグラウンドで行われる様になってしまいました。 それも頻繁に。
昨日はエクスプローラのモジュールの一部が変わった様で突如アプリケーションレベルでのファイルコピー動作が途中でダウンしてしまいました。 で、その後は Windows10/8.1 共に相手が見えなくなってしまいました。 再起動してみましたが、ダメ・・・。
その直後、「フォルダー監視」のブザーが鳴ったので確認してみると、変更があったのは WindowsUpdate.log とレポートして来ていました。 で、再度ネットワークを見てみますと Windows8.1 からは見える様になっていました。 でも Windows10 側には１台も出ていません。
Windows10 だけだと思っていましたがどうもそうではない様で、今月のマンスリーアップデートでは双方のネットワークマネージメントは一体どうなっているのでしょうかね。 こんな状態では企業では使えないでしょう。 ひょっとすると Windows Server 2019 との間なら問題は起きてないから良いとでも？
個人や中小ではわざわざ Server OS なんて入れずにネットワークを構成しますよね。 その場合サーバー代りに使うＰＣのドライブを共有設定し、各ＰＣは全てパスワードログオンという設定にして、ルーターの設定をＤＨＣＰのＩＰアドレス範囲を設定し、Ｍａｃアドレスでブロックする様にして勝手に端末を接続出来ない様にする事で済ますでしょう。
サーバー/端末間の相互参照ではエクスプローラのモジュールが使われますので、これが安定していなくては始まりませんが、Windows10 が加わってからはどうも安定しません。
今迄のトラブルはエクスプローラもしくはアプリケーションのファイル選択でアクセス出来なくなる位でしたが、今回は既にコピー動作をしている接続が切れてしまいましたので、ちょっと重症なトラブルの発生です。
Windows10 絡みのエクスプローラのトラブルは皆直らず繰り返し再発していますし、その復旧に酷い時には１日以上掛かっています。
これは今までは纏めて掛けていた一般的な細かなアップデートをバックグラウンドにして直ちに修正する様にし、対応速度を上げようとしたのかもしれませんが、これでは逆効果になったのでは？ それも最も重要なファイルマネージメントの基幹であるエクスプローラの表に出る部分で再発を繰り返す様では・・・
因みに各ＯＳのサポート期限は
メインストリーム終了日 延長サポいート終了日
Windows7 2015/01/13 2020/01/14
Windows8.1 2018/01/09 2023/01/11
Windows10 2020/10/13 2025/10/14
Windows のサポート期限は上記の通りですから、Windows7 も含め延長サポート終了迄相互の交換性は保証されなければならないはずですよね。
Adobe Photoshop CS2 が開けなくなる理由はこれ？ [睡夢庵の電脳環境]
【 Adobe Photoshop CS2 が開けなくなる理由はこれ？ 】
---申し訳ありません、これは間違いの様です。---
現在 Adobe の更新確認と２つの Windows のアップデートを追っていますが、これ以外にも Windows10 の変更が行われているのではないかという疑いが生じています。
というのは
★ Photoshop CS2 起動不能
－ ブザー/アイコンフリック ⇒ C:\Windows\Temp\adobegc.log 書き換え
★ Photoshop CS2 起動不能
－ ブザー/アイコンフリック ⇒ C:\Windows\Temp\adobegc.log 書き換え
★ Photoshop CS2 起動不能
約１時間半後
－ ブザー/アイコンフリック ⇒ C:\Windows\WindowsUpdate.log 書き換え
★ Photoshop CS2 起動不能
約２時間後
★ Photoshop CS2 起動不能
－ ブザー/アイコンフリック ⇒ C:\Windows\Temp\adobegc.log 書き換え
－ ブザー/アイコンフリック ⇒ C:\Windows\Temp\adobegc.log 書き換え
★ Photoshop CS2 起動不能
約２時間経過
－ ブザー/アイコンフリック ⇒ C:\Windows\WindowsUpdate.log 書き換え
☆ Photoshop CS2 起動可能
約５分経過
★ Photoshop CS2 起動不能
といった様にログされるタイミング以外の部分で、起動可能/不能とステータスが変化する状態が複数回発生しています。
各ログの書式と意味する所が分かりませんので、動作内容が分からずでサチッちゃってます。(^^;)>
モジュールをリリースして暫くして再ロードするという可能性を考えるとこのレベルで追う事自体が無意味の様な気がしてきました。
何らかの方法で使えるタイミングを知る方法がないかと追ってみましたが、うまく行きそうにありません。
Photoshop CS2 は動作保証外ですから、現状の様に使えるタイミングが生じるのであれば使うという所で諦めるしかなさそうですね。
----------------------------------------------------------------------
Adobe Photoshop CS2 が開けなるタイミングが Windows のアンダーグラウンドアップデートに関わりなく発生する様な気がして・・・
というのも朝１番の起動直後に起動できないのを確認して、朝食後確認したら今度は起動出来るという事が２度続きました。
で、Windows 配下を日付で検索してみた所 Temp フォルダの中に adbegc.log というファイルがあり、この更新日付が席を外していた間の時間に合致していました。
この中を見てみますと以下の様な記述部があます。
これを見ると６時間のウエイトタイマーをセットして作業を終えている事が分かります。
で、次の行では丁度６時間後にチェックとアップデートのイベントが起動されています。
03/03/19 12:47:25:238 | [INFO] | | | | AGSService | | | 4576 | Thread Finished ...
03/03/19 12:47:26:253 | [INFO] | | | | AGSService | | | 4576 | CreateEvent Done
03/03/19 12:47:26:253 | [INFO] | | | | AGSService | | | 4576 | CreateTimerQueue Done
03/03/19 12:47:26:253 | [INFO] | | | | AGSService | | | 4576 | CreateTimerQueueTimer Done
03/03/19 12:47:26:254 | [INFO] | | | | AGSService | | | 4576 | Call timer routine in 6 hrs...
03/03/19 18:47:26:267 | [INFO] | | | | AGSService | | | 2620 | Retrieving ptr
03/03/19 18:47:26:269 | [INFO] | | | | AGSService | | | 2620 | The wait timed out.
03/03/19 18:47:26:269 | [INFO] | | | | AGSService | | | 4576 | WaitForSingleObject Done
03/03/19 18:47:26:270 | [INFO] | | | | AGSService | | | 4576 | DeleteTimerQueue Done
03/03/19 18:47:26:270 | [INFO] | | | | AGSService | | | 2620 | AdobeGCData folder already exists, validating permissions
３月４日はＰＣ自体は 05:24 に起動していますので、このイベントがなぜ 07:59 に起動されているのかは不明ですが(^^;)>
03/03/19 18:47:27:282 | [INFO] | | | | AGSService | | | 2620 | Thread Finished ...
03/03/19 18:47:28:298 | [INFO] | | | | AGSService | | | 2620 | CreateEvent Done
03/03/19 18:47:28:298 | [INFO] | | | | AGSService | | | 2620 | CreateTimerQueue Done
03/03/19 18:47:28:298 | [INFO] | | | | AGSService | | | 2620 | CreateTimerQueueTimer Done
03/03/19 18:47:28:298 | [INFO] | | | | AGSService | | | 2620 | Call timer routine in 6 hrs...
03/04/19 07:59:32:111 | [INFO] | | | | AGSService | | | 9060 | Retrieving ptr
03/04/19 07:59:32:113 | [INFO] | | | | AGSService | | | 9060 | The wait timed out.
03/04/19 07:59:32:113 | [INFO] | | | | AGSService | | | 2620 | WaitForSingleObject Done
03/04/19 07:59:32:113 | [INFO] | | | | AGSService | | | 2620 | DeleteTimerQueue Done
03/04/19 07:59:32:113 | [INFO] | | | | AGSService | | | 9060 | AdobeGCData folder already exists, validating permissions
03/04/19 07:59:32:114 | [INFO] | | | | AGSService | | | 9060 | Validating permissions of AdobeGCData folder
03/04/19 07:59:32:114 | [INFO] | | | | AGSService | | | 9060 | Successfully fetched length of security descriptor
03/04/19 07:59:32:114 | [INFO] | | | | AGSService | | | 9060 | Successfully fetched security descriptor
03/04/19 07:59:32:114 | [INFO] | | | | AGSService | | | 9060 | Successfully fetched DACL from security descriptor
03/04/19 07:59:32:114 | [INFO] | | | | AGSService | | | 9060 | Valid Permissions found
03/04/19 07:59:32:114 | [INFO] | | | | AGSService | | | 9060 | Successfully created/fetched AdobeGCData Folder
03/04/19 07:59:32:114 | [INFO] | | | | AGSService | | | 9060 | Thread ...
03/04/19 07:59:32:115 | [INFO] | | | | AGSService | | | 11480 | Thread inside...
03/04/19 07:59:32:115 | [INFO] | | | | AGSService | | | 11480 | Thread calling CFU...
03/04/19 07:59:32:117 | [INFO] | | | | AdobeGCUpdater | | | 11480 | ***********AdobeGC Updater library invoked = 6.2.0.190 ************
03/04/19 07:59:32:117 | [INFO] | | | | AdobeGCUpdaterCFU | | | 11480 | Perform WF started
03/04/19 07:59:32:117 | [INFO] | | | | AdobeGCUpdaterCFU | | | 11480 | Perform WF completed
03/04/19 07:59:32:117 | [INFO] | | | | AdobeGCUpdater | | | 11480 | ***********AdobeGC Updater library End*******************
これからすると Photoshop CS2 が起動出来たり出来なかったりというのは Windows10 のアップデートによる物ではなく Adobe の更新チェックプログラム絡みの様です。 Adobe 自身で？とちょっと疑問符が付きますが、ログの状況からは・・・
使えている間にアップデートサービスを止めるか？ Frash や Acrobat のアップデート迄止まっちゃう事になるのでこれは出来ないし。
これはハラハラ・・・何時使えなくなるか(^^;)
最近はこのブログ用に画像をシュリンクするのに使う位になってしまいましたので、月額ウン千円？を出して迄は・・・です。 それにネット/クラウドプロセッシングは可能な限り遣りなくない(^^;)
【2019/03/14 追記】 Windows Update サチっちゃってる？
2019/03/13 もアンダーグラウンドのアップデートが多数走りました。
2019/03/13 05:38 更新されました 1KB 2019/03/13 05:38 C:\Windows\WindowsUpdate.log
2019/03/13 13:37 更新されました 1KB 2019/03/13 13:37 C:\Windows\WindowsUpdate.log
2019/03/13 13:47 更新されました 952KB 2019/03/13 13:37 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/13 14:03 更新されました 1KB 2019/03/13 14:03 C:\Windows\WindowsUpdate.log
2019/03/13 14:07 更新されました 960KB 2019/03/13 14:06 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/13 14:07 更新されました 1KB 2019/03/13 14:07 C:\Windows\WindowsUpdate.log
2019/03/13 14:10 更新されました 961KB 2019/03/13 14:07 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/13 14:10 更新されました 1KB 2019/03/13 14:09 C:\Windows\WindowsUpdate.log
2019/03/13 14:39 更新されました 1KB 2019/03/13 14:39 C:\Windows\WindowsUpdate.log
2019/03/13 14:55 更新されました 1KB 2019/03/13 14:55 C:\Windows\WindowsUpdate.log
2019/03/13 15:38 更新されました 1KB 2019/03/13 15:38 C:\Windows\WindowsUpdate.log
2019/03/13 16:02 更新されました 962KB 2019/03/13 15:38 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/13 16:45 更新されました 1KB 2019/03/13 16:45 C:\Windows\WindowsUpdate.log
2019/03/13 17:00 更新されました 1KB 2019/03/13 17:00 C:\Windows\WindowsUpdate.log
2019/03/13 19:44 更新されました 963KB 2019/03/13 19:33 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/14 06:15 更新されました 1KB 2019/03/14 06:15 C:\Windows\WindowsUpdate.log
2019/03/14 06:25 更新されました 964KB 2019/03/14 06:15 C:\Windows\SoftwareDistribution\ReportingEvents.log
一番参ったのがエクスプローラーで Windows8.1 から Windows10 が見えたり見えなくなったりを繰り返したことですね。 相互のバックアップはアプリ側にフルパスが設定されている為ちゃんと動作しますが、Photoshop 等のアプリから直接参照しようとするとダメ・・・
同様の状態が Windows8.1 側でもおきているのでしょうかね？
今日朝一番で早速です。 一体どうなる事やら・・・
そうそう、昨日Windows8.1 の方も マンスリーアップデートが掛かりました。 こちらのアップデートはチェックしていませんのでどちらに責任があるのかですが・・・気付くのはいつも Windows10 側のアップデート後、見えなくなるのは Windows10 だけですし、Windows10 側からも見えていないのはエクスプローラ絡みだけ、フルパスで指定すれば見えるという・・・
---申し訳ありません、これは間違いの様です。---
現在 Adobe の更新確認と２つの Windows のアップデートを追っていますが、これ以外にも Windows10 の変更が行われているのではないかという疑いが生じています。
というのは
★ Photoshop CS2 起動不能
－ ブザー/アイコンフリック ⇒ C:\Windows\Temp\adobegc.log 書き換え
★ Photoshop CS2 起動不能
－ ブザー/アイコンフリック ⇒ C:\Windows\Temp\adobegc.log 書き換え
★ Photoshop CS2 起動不能
約１時間半後
－ ブザー/アイコンフリック ⇒ C:\Windows\WindowsUpdate.log 書き換え
★ Photoshop CS2 起動不能
約２時間後
★ Photoshop CS2 起動不能
－ ブザー/アイコンフリック ⇒ C:\Windows\Temp\adobegc.log 書き換え
－ ブザー/アイコンフリック ⇒ C:\Windows\Temp\adobegc.log 書き換え
★ Photoshop CS2 起動不能
約２時間経過
－ ブザー/アイコンフリック ⇒ C:\Windows\WindowsUpdate.log 書き換え
☆ Photoshop CS2 起動可能
約５分経過
★ Photoshop CS2 起動不能
といった様にログされるタイミング以外の部分で、起動可能/不能とステータスが変化する状態が複数回発生しています。
各ログの書式と意味する所が分かりませんので、動作内容が分からずでサチッちゃってます。(^^;)>
モジュールをリリースして暫くして再ロードするという可能性を考えるとこのレベルで追う事自体が無意味の様な気がしてきました。
何らかの方法で使えるタイミングを知る方法がないかと追ってみましたが、うまく行きそうにありません。
Photoshop CS2 は動作保証外ですから、現状の様に使えるタイミングが生じるのであれば使うという所で諦めるしかなさそうですね。
----------------------------------------------------------------------
Adobe Photoshop CS2 が開けなるタイミングが Windows のアンダーグラウンドアップデートに関わりなく発生する様な気がして・・・
というのも朝１番の起動直後に起動できないのを確認して、朝食後確認したら今度は起動出来るという事が２度続きました。
で、Windows 配下を日付で検索してみた所 Temp フォルダの中に adbegc.log というファイルがあり、この更新日付が席を外していた間の時間に合致していました。
この中を見てみますと以下の様な記述部があます。
これを見ると６時間のウエイトタイマーをセットして作業を終えている事が分かります。
で、次の行では丁度６時間後にチェックとアップデートのイベントが起動されています。
03/03/19 12:47:25:238 | [INFO] | | | | AGSService | | | 4576 | Thread Finished ...
03/03/19 12:47:26:253 | [INFO] | | | | AGSService | | | 4576 | CreateEvent Done
03/03/19 12:47:26:253 | [INFO] | | | | AGSService | | | 4576 | CreateTimerQueue Done
03/03/19 12:47:26:253 | [INFO] | | | | AGSService | | | 4576 | CreateTimerQueueTimer Done
03/03/19 12:47:26:254 | [INFO] | | | | AGSService | | | 4576 | Call timer routine in 6 hrs...
03/03/19 18:47:26:267 | [INFO] | | | | AGSService | | | 2620 | Retrieving ptr
03/03/19 18:47:26:269 | [INFO] | | | | AGSService | | | 2620 | The wait timed out.
03/03/19 18:47:26:269 | [INFO] | | | | AGSService | | | 4576 | WaitForSingleObject Done
03/03/19 18:47:26:270 | [INFO] | | | | AGSService | | | 4576 | DeleteTimerQueue Done
03/03/19 18:47:26:270 | [INFO] | | | | AGSService | | | 2620 | AdobeGCData folder already exists, validating permissions
３月４日はＰＣ自体は 05:24 に起動していますので、このイベントがなぜ 07:59 に起動されているのかは不明ですが(^^;)>
03/03/19 18:47:27:282 | [INFO] | | | | AGSService | | | 2620 | Thread Finished ...
03/03/19 18:47:28:298 | [INFO] | | | | AGSService | | | 2620 | CreateEvent Done
03/03/19 18:47:28:298 | [INFO] | | | | AGSService | | | 2620 | CreateTimerQueue Done
03/03/19 18:47:28:298 | [INFO] | | | | AGSService | | | 2620 | CreateTimerQueueTimer Done
03/03/19 18:47:28:298 | [INFO] | | | | AGSService | | | 2620 | Call timer routine in 6 hrs...
03/04/19 07:59:32:111 | [INFO] | | | | AGSService | | | 9060 | Retrieving ptr
03/04/19 07:59:32:113 | [INFO] | | | | AGSService | | | 9060 | The wait timed out.
03/04/19 07:59:32:113 | [INFO] | | | | AGSService | | | 2620 | WaitForSingleObject Done
03/04/19 07:59:32:113 | [INFO] | | | | AGSService | | | 2620 | DeleteTimerQueue Done
03/04/19 07:59:32:113 | [INFO] | | | | AGSService | | | 9060 | AdobeGCData folder already exists, validating permissions
03/04/19 07:59:32:114 | [INFO] | | | | AGSService | | | 9060 | Validating permissions of AdobeGCData folder
03/04/19 07:59:32:114 | [INFO] | | | | AGSService | | | 9060 | Successfully fetched length of security descriptor
03/04/19 07:59:32:114 | [INFO] | | | | AGSService | | | 9060 | Successfully fetched security descriptor
03/04/19 07:59:32:114 | [INFO] | | | | AGSService | | | 9060 | Successfully fetched DACL from security descriptor
03/04/19 07:59:32:114 | [INFO] | | | | AGSService | | | 9060 | Valid Permissions found
03/04/19 07:59:32:114 | [INFO] | | | | AGSService | | | 9060 | Successfully created/fetched AdobeGCData Folder
03/04/19 07:59:32:114 | [INFO] | | | | AGSService | | | 9060 | Thread ...
03/04/19 07:59:32:115 | [INFO] | | | | AGSService | | | 11480 | Thread inside...
03/04/19 07:59:32:115 | [INFO] | | | | AGSService | | | 11480 | Thread calling CFU...
03/04/19 07:59:32:117 | [INFO] | | | | AdobeGCUpdater | | | 11480 | ***********AdobeGC Updater library invoked = 6.2.0.190 ************
03/04/19 07:59:32:117 | [INFO] | | | | AdobeGCUpdaterCFU | | | 11480 | Perform WF started
03/04/19 07:59:32:117 | [INFO] | | | | AdobeGCUpdaterCFU | | | 11480 | Perform WF completed
03/04/19 07:59:32:117 | [INFO] | | | | AdobeGCUpdater | | | 11480 | ***********AdobeGC Updater library End*******************
これからすると Photoshop CS2 が起動出来たり出来なかったりというのは Windows10 のアップデートによる物ではなく Adobe の更新チェックプログラム絡みの様です。 Adobe 自身で？とちょっと疑問符が付きますが、ログの状況からは・・・
使えている間にアップデートサービスを止めるか？ Frash や Acrobat のアップデート迄止まっちゃう事になるのでこれは出来ないし。
これはハラハラ・・・何時使えなくなるか(^^;)
最近はこのブログ用に画像をシュリンクするのに使う位になってしまいましたので、月額ウン千円？を出して迄は・・・です。 それにネット/クラウドプロセッシングは可能な限り遣りなくない(^^;)
【2019/03/14 追記】 Windows Update サチっちゃってる？
2019/03/13 もアンダーグラウンドのアップデートが多数走りました。
2019/03/13 05:38 更新されました 1KB 2019/03/13 05:38 C:\Windows\WindowsUpdate.log
2019/03/13 13:37 更新されました 1KB 2019/03/13 13:37 C:\Windows\WindowsUpdate.log
2019/03/13 13:47 更新されました 952KB 2019/03/13 13:37 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/13 14:03 更新されました 1KB 2019/03/13 14:03 C:\Windows\WindowsUpdate.log
2019/03/13 14:07 更新されました 960KB 2019/03/13 14:06 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/13 14:07 更新されました 1KB 2019/03/13 14:07 C:\Windows\WindowsUpdate.log
2019/03/13 14:10 更新されました 961KB 2019/03/13 14:07 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/13 14:10 更新されました 1KB 2019/03/13 14:09 C:\Windows\WindowsUpdate.log
2019/03/13 14:39 更新されました 1KB 2019/03/13 14:39 C:\Windows\WindowsUpdate.log
2019/03/13 14:55 更新されました 1KB 2019/03/13 14:55 C:\Windows\WindowsUpdate.log
2019/03/13 15:38 更新されました 1KB 2019/03/13 15:38 C:\Windows\WindowsUpdate.log
2019/03/13 16:02 更新されました 962KB 2019/03/13 15:38 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/13 16:45 更新されました 1KB 2019/03/13 16:45 C:\Windows\WindowsUpdate.log
2019/03/13 17:00 更新されました 1KB 2019/03/13 17:00 C:\Windows\WindowsUpdate.log
2019/03/13 19:44 更新されました 963KB 2019/03/13 19:33 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/14 06:15 更新されました 1KB 2019/03/14 06:15 C:\Windows\WindowsUpdate.log
2019/03/14 06:25 更新されました 964KB 2019/03/14 06:15 C:\Windows\SoftwareDistribution\ReportingEvents.log
一番参ったのがエクスプローラーで Windows8.1 から Windows10 が見えたり見えなくなったりを繰り返したことですね。 相互のバックアップはアプリ側にフルパスが設定されている為ちゃんと動作しますが、Photoshop 等のアプリから直接参照しようとするとダメ・・・
同様の状態が Windows8.1 側でもおきているのでしょうかね？
今日朝一番で早速です。 一体どうなる事やら・・・
そうそう、昨日Windows8.1 の方も マンスリーアップデートが掛かりました。 こちらのアップデートはチェックしていませんのでどちらに責任があるのかですが・・・気付くのはいつも Windows10 側のアップデート後、見えなくなるのは Windows10 だけですし、Windows10 側からも見えていないのはエクスプローラ絡みだけ、フルパスで指定すれば見えるという・・・
一体今日は何事？ [睡夢庵の電脳環境]
【一体今日は何事？】
2019/03/12 今日は朝から２種類のアップデートが掛かり続けています。
現在はフォルダ/ファイルの更新があったら「ベル」がなる様に設定していますので、遅くとも１分後にはアップデートがあった事が分かるはずなのですが・・・
で、「フォルダ監視」が捉えた更新は
2019/03/12 06:07 更新されました 1KB 2019/03/12 06:06 C:\Windows\WindowsUpdate.log
2019/03/12 09:27 更新されました 1KB 2019/03/12 09:26 C:\Windows\WindowsUpdate.log
2019/03/12 10:23 更新されました 945KB 2019/03/12 09:27 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/12 10:34 更新されました 1KB 2019/03/12 10:34 C:\Windows\WindowsUpdate.log
2019/03/12 13:15 更新されました 1KB 2019/03/12 13:15 C:\Windows\WindowsUpdate.log
2019/03/12 13:25 更新されました 946KB 2019/03/12 13:15 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/12 15:43 更新されました 1KB 2019/03/12 15:42 C:\Windows\WindowsUpdate.log
2019/03/12 15:53 更新されました 949KB 2019/03/12 15:42 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/12 16:04 更新されました 1KB 2019/03/12 16:04 C:\Windows\WindowsUpdate.log
2019/03/12 16:14 更新されました 951KB 2019/03/12 16:04 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/12 16:46 更新されました 1KB 2019/03/12 16:46 C:\Windows\WindowsUpdate.log
2019/03/12 17:52 更新されました 1KB 2019/03/12 17:52 C:\Windows\WindowsUpdate.log
WindowsUpdate.log は更新日時の１分後にログされていますが、ReportingEvents.log は何故か更新日付の１分後にはログされません。
このログでは 09:27 の分が 10:23 分にログされています。 「操作中には表示しない」という設定がありましたのでこのせいか思い、オフにしてみましたがその直後は直った様に見えたのですが、このリストを見ると直ってはいません。 ひょっとしたらこの間このファイル若しくはフォルダがアクセス禁止になっている？
そこで「Powershell」で「Get-WindowsUpdateLog」を実行してみた処今日は 2324 行に亘る変更が加わっていました。
３月度のマンスリーアップデート後ではここまででトータル 5492 行のリストがありました。
ただ、これはプロセスの記述になっていますので、書式を知らないとどこにインストールされたモジュールが記述されているか分かりません。 また、モジュール名も我々にとっては意味をなさない文字列で示されているみたいですので内容は？です。
先のファイルの更新時間とフォルダ監視が捉える時間との差は、ファイルの更新時間はアップデートの終了時間でスタンプされるが、「フォルダ監視」が捉える時間は、この回に起動された全てのサービスがシャットダウンされ、アップデートサービスが終了した時間になっている様で、時間差が出てしまう様です。 ここ迄はファイルが書かれていないのでしょう。
で、これらのアンダーグラウンドの更新は「設定」から見る「更新とセキュリティ」にある更新履歴には一切記述されません。
2019/03/12 今日は朝から２種類のアップデートが掛かり続けています。
現在はフォルダ/ファイルの更新があったら「ベル」がなる様に設定していますので、遅くとも１分後にはアップデートがあった事が分かるはずなのですが・・・
で、「フォルダ監視」が捉えた更新は
2019/03/12 06:07 更新されました 1KB 2019/03/12 06:06 C:\Windows\WindowsUpdate.log
2019/03/12 09:27 更新されました 1KB 2019/03/12 09:26 C:\Windows\WindowsUpdate.log
2019/03/12 10:23 更新されました 945KB 2019/03/12 09:27 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/12 10:34 更新されました 1KB 2019/03/12 10:34 C:\Windows\WindowsUpdate.log
2019/03/12 13:15 更新されました 1KB 2019/03/12 13:15 C:\Windows\WindowsUpdate.log
2019/03/12 13:25 更新されました 946KB 2019/03/12 13:15 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/12 15:43 更新されました 1KB 2019/03/12 15:42 C:\Windows\WindowsUpdate.log
2019/03/12 15:53 更新されました 949KB 2019/03/12 15:42 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/12 16:04 更新されました 1KB 2019/03/12 16:04 C:\Windows\WindowsUpdate.log
2019/03/12 16:14 更新されました 951KB 2019/03/12 16:04 C:\Windows\SoftwareDistribution\ReportingEvents.log
2019/03/12 16:46 更新されました 1KB 2019/03/12 16:46 C:\Windows\WindowsUpdate.log
2019/03/12 17:52 更新されました 1KB 2019/03/12 17:52 C:\Windows\WindowsUpdate.log
WindowsUpdate.log は更新日時の１分後にログされていますが、ReportingEvents.log は何故か更新日付の１分後にはログされません。
このログでは 09:27 の分が 10:23 分にログされています。 「操作中には表示しない」という設定がありましたのでこのせいか思い、オフにしてみましたがその直後は直った様に見えたのですが、このリストを見ると直ってはいません。 ひょっとしたらこの間このファイル若しくはフォルダがアクセス禁止になっている？
そこで「Powershell」で「Get-WindowsUpdateLog」を実行してみた処今日は 2324 行に亘る変更が加わっていました。
３月度のマンスリーアップデート後ではここまででトータル 5492 行のリストがありました。
ただ、これはプロセスの記述になっていますので、書式を知らないとどこにインストールされたモジュールが記述されているか分かりません。 また、モジュール名も我々にとっては意味をなさない文字列で示されているみたいですので内容は？です。
先のファイルの更新時間とフォルダ監視が捉える時間との差は、ファイルの更新時間はアップデートの終了時間でスタンプされるが、「フォルダ監視」が捉える時間は、この回に起動された全てのサービスがシャットダウンされ、アップデートサービスが終了した時間になっている様で、時間差が出てしまう様です。 ここ迄はファイルが書かれていないのでしょう。
で、これらのアンダーグラウンドの更新は「設定」から見る「更新とセキュリティ」にある更新履歴には一切記述されません。
３月度 Windows10 アップデート でもダメだ・・・ [睡夢庵の電脳環境]
【３月度 Windows10 アップデート でもダメだ・・・】
３月６日今月の定期アップデートが掛かりましたが、私が引っ掛かっている所はどれも収まらない様です。
先月（2019/02/21 報告）と同じトラブルが再発しています。 ちょっと好い加減にしてと言いたくなります。
OSがデカくなり過ぎたみたいですね、管理限界を超えた(^^;)？
アップデートの確認の為、Windows 配下の SoftwareDistribution フォルダの ReportingEvents.log を「メモ帳」で開いてアップデートの内容を確認しようとした所カーソルの「I」が４倍サイズになりました。 「Libre Office」等では気にならなかったので「秀丸」だけでの問題かと思っていましたが、Microsoft 自身のエディタ「メモ帳」でも発生・・・
ん？ 「メモ帳」の動きがおかしい・・・横を広げ様とすると引っ掛かる。 「秀丸」では？・・・スムーズに動く・・・高々１５００行位でこんなになるヘビーになるの？ バグか？
録音もダメみたいですね～システムのステレオミキサーも選べない・・・ドライバーが変わっていないので仕方がないですが。
Windows の「設定」から「Windows Update」の「更新履歴を表示する」では月度のアップデートとオープンになっている分しか見る事が出来ませんが、SoftwareDistribution フォルダの ReportingEvents.log ファイルを見るとアンダーグラウンドで行われているアップデートを知る事が出来ます。
先に「Chrome の software reporter tool の止め方 追補」で使った「フォルダ監視」を使えば、ReportingEvents.log に登録されるアップデートが行われたタイミングで知る事が可能になります。
Chrome は「フォルダ」に変更が加わったらという条件ですが、これを上記の「ファイル」に変更が加わったらという設定をしてやればこのファイルにログされる変更があればその時点で分かる様に出来ます。
設定例は以下の通り。
下の赤枠部分は「監視フォルダの設定」で行い、上の赤枠部分は「対象ファイルの設定」で「フォルダ毎に設定する」で表示されるポップアップの中で行います。
<フォルダ毎に設定する>ボタンを押して出るポップアップを重ねて表示していますのでちょっと分かり辛いかな。
音を鳴らすのは五月蠅いので避けていたのですが、タスクバーアイコンの赤点滅位では気付きませんでした。
「一覧画面の設定」次のサウンドファイルを再生するをチェックして、システムの .wab ファイルを指定してやれば色々な音で知らせる事が可能ですので、これしかないですね。
この場合は該当のフォルダを開くという機能とトレードになっており、「プログラム起動設定」の変更ファイル検知時にプログラムを起動するのチェックを外しておかねばなりません。（前回の例ではここでエクスプローラを起動する様設定しています。）
なので、タスクバーアイコンをクリックしても該当フォルダは開かずプログラムが用意する一覧画面しか開きませんので、手操作でフォルダを開いてやる必要が出て来ます。
【追記】
ログファイルの記録時間が１０分ズレる事が多いので？？
まさかと思い、“一覧画面の操作中は表示しない”のチェックを外して見たところちゃんと１分後にログされる様になったみたいです。
ディレイが１分というのはちょっと長いですが・・・
３月６日今月の定期アップデートが掛かりましたが、私が引っ掛かっている所はどれも収まらない様です。
先月（2019/02/21 報告）と同じトラブルが再発しています。 ちょっと好い加減にしてと言いたくなります。
OSがデカくなり過ぎたみたいですね、管理限界を超えた(^^;)？
アップデートの確認の為、Windows 配下の SoftwareDistribution フォルダの ReportingEvents.log を「メモ帳」で開いてアップデートの内容を確認しようとした所カーソルの「I」が４倍サイズになりました。 「Libre Office」等では気にならなかったので「秀丸」だけでの問題かと思っていましたが、Microsoft 自身のエディタ「メモ帳」でも発生・・・
ん？ 「メモ帳」の動きがおかしい・・・横を広げ様とすると引っ掛かる。 「秀丸」では？・・・スムーズに動く・・・高々１５００行位でこんなになるヘビーになるの？ バグか？
録音もダメみたいですね～システムのステレオミキサーも選べない・・・ドライバーが変わっていないので仕方がないですが。
Windows の「設定」から「Windows Update」の「更新履歴を表示する」では月度のアップデートとオープンになっている分しか見る事が出来ませんが、SoftwareDistribution フォルダの ReportingEvents.log ファイルを見るとアンダーグラウンドで行われているアップデートを知る事が出来ます。
先に「Chrome の software reporter tool の止め方 追補」で使った「フォルダ監視」を使えば、ReportingEvents.log に登録されるアップデートが行われたタイミングで知る事が可能になります。
Chrome は「フォルダ」に変更が加わったらという条件ですが、これを上記の「ファイル」に変更が加わったらという設定をしてやればこのファイルにログされる変更があればその時点で分かる様に出来ます。
設定例は以下の通り。
下の赤枠部分は「監視フォルダの設定」で行い、上の赤枠部分は「対象ファイルの設定」で「フォルダ毎に設定する」で表示されるポップアップの中で行います。
<フォルダ毎に設定する>ボタンを押して出るポップアップを重ねて表示していますのでちょっと分かり辛いかな。
音を鳴らすのは五月蠅いので避けていたのですが、タスクバーアイコンの赤点滅位では気付きませんでした。
「一覧画面の設定」次のサウンドファイルを再生するをチェックして、システムの .wab ファイルを指定してやれば色々な音で知らせる事が可能ですので、これしかないですね。
この場合は該当のフォルダを開くという機能とトレードになっており、「プログラム起動設定」の変更ファイル検知時にプログラムを起動するのチェックを外しておかねばなりません。（前回の例ではここでエクスプローラを起動する様設定しています。）
なので、タスクバーアイコンをクリックしても該当フォルダは開かずプログラムが用意する一覧画面しか開きませんので、手操作でフォルダを開いてやる必要が出て来ます。
【追記】
ログファイルの記録時間が１０分ズレる事が多いので？？
まさかと思い、“一覧画面の操作中は表示しない”のチェックを外して見たところちゃんと１分後にログされる様になったみたいです。
ディレイが１分というのはちょっと長いですが・・・
花粉症の季節が・・・グシュン [睡夢庵 日々徒然]
【花粉症の季節が・・・グシュン】
２月末迄は朝と就寝前に「パブロンゴールドＡ細粒」を半包づつでなんとか症状を抑えられていました。
３月に入って鼻の中の爛れが段々酷くなってムズムズ感が出、鼻の孔の方へ出る洟の量が増えて来ていました。
一昨日買い物に車でちょっと出掛けた所、帰って来た途端クシャミ連発と洟タラ～リ・・・その内目の周りが痒くなり眼も充血・・・慌ててアルガード点眼(^^;)
そして昨日朝、デッキに出ようとしてツッカケをずらした所写真の通り・・・
ここ数日の雨の間に溜まった花粉とカーボン汚れです。 空気汚れも酷くなって来ているみたいですね。
今も「ａｉｒｍｏｎ」で室内のＰＭ２.５と１０をチェックしていますが、そろそろサッシを開けての換気が出来なくなります。
二酸化炭素濃度は下がりませんが廊下側のドアを開けて廊下を通して換気をする以外ありません。
なかなか１０００ｐｐｍ以下にはなってくれませんが仕方なしです(^^;)
因みに室内は昼間空気清浄器を掛けっぱなしですので、
ＰＭ２.５ ＰＭ１０ μｇ/ｍ3
昼間 １０～１８ ３～１０ 空気清浄機運転中
起床時 １８～２５ １５～２０ 就寝中は空気清浄機停止
今屋外を計測しようとしてサッシを開けっ放しでデッキに出て計測してみた所
ＰＭ２.５ ＰＭ１０ μｇ/ｍ3
屋内（直前） １３ ７
デッキ上 ４２ ４０ （屋外計測）
屋内（直後） ２７ ２４ 覿面クシャミと洟が・・・
同 １１ ３ ナノイーショット運転後
昨日昼から６時間おきに半包、朝・昼・晩・就寝前の４回に切り替えましたが、鼻腔から鼻孔奥迄痒い様な熱い様なチリチリ感が消えなくなってしまいました。
ご同類お互い辛いですね～
２月末迄は朝と就寝前に「パブロンゴールドＡ細粒」を半包づつでなんとか症状を抑えられていました。
３月に入って鼻の中の爛れが段々酷くなってムズムズ感が出、鼻の孔の方へ出る洟の量が増えて来ていました。
一昨日買い物に車でちょっと出掛けた所、帰って来た途端クシャミ連発と洟タラ～リ・・・その内目の周りが痒くなり眼も充血・・・慌ててアルガード点眼(^^;)
そして昨日朝、デッキに出ようとしてツッカケをずらした所写真の通り・・・
ここ数日の雨の間に溜まった花粉とカーボン汚れです。 空気汚れも酷くなって来ているみたいですね。
今も「ａｉｒｍｏｎ」で室内のＰＭ２.５と１０をチェックしていますが、そろそろサッシを開けての換気が出来なくなります。
二酸化炭素濃度は下がりませんが廊下側のドアを開けて廊下を通して換気をする以外ありません。
なかなか１０００ｐｐｍ以下にはなってくれませんが仕方なしです(^^;)
因みに室内は昼間空気清浄器を掛けっぱなしですので、
ＰＭ２.５ ＰＭ１０ μｇ/ｍ3
昼間 １０～１８ ３～１０ 空気清浄機運転中
起床時 １８～２５ １５～２０ 就寝中は空気清浄機停止
今屋外を計測しようとしてサッシを開けっ放しでデッキに出て計測してみた所
ＰＭ２.５ ＰＭ１０ μｇ/ｍ3
屋内（直前） １３ ７
デッキ上 ４２ ４０ （屋外計測）
屋内（直後） ２７ ２４ 覿面クシャミと洟が・・・
同 １１ ３ ナノイーショット運転後
昨日昼から６時間おきに半包、朝・昼・晩・就寝前の４回に切り替えましたが、鼻腔から鼻孔奥迄痒い様な熱い様なチリチリ感が消えなくなってしまいました。
ご同類お互い辛いですね～
スマートブレスレットＶ１０とアプリの問題点 [便利グッズ？紹介]
【スマートブレスレットＶ１０とアプリの問題点】
yoiyasu という所が扱っているスマートブレスレットＶ１０とＨ ＢａｎｄⅡ というアプリの組み合わせで使っていますが、正直なところ前機種のＶ７ＳとＨ Ｂａｎｄ との組み合わせの方が精度が高い様です。
アプリのアップデートがある度に逆に精度が落ちている様で少々ゲンナリしています。 色々使い勝手を上げようとしているのでしょうが、私の様にこの種の物を使う方の一般的パターンとは少し異なる者には合わなくなって来ています。
どこがか？
《睡眠時間計測精度が落ちた》
私の就寝サイクルは 就床 ： 21:30 ～23:00 起床 ： 4:00～5:30
問題点１ 01:00 頃迄に一度起きてトイレに行くとこれが就寝として
扱われる為、それまでの睡眠時間が無視されてしまい
計測結果が意味を失う。
１５％位は就寝直前に薬を飲み、９時台に寝ているのでこれ位の
確率で使えないデータになる。
問題点２ トイレ起床を捕捉しない事態が起き始めた。
Ｖ０７Ｓを使っていた時にはなかったと思う。
問題点３ 起床が早いと８時位迄の間、デスクワークをしている間が２度寝
扱いになってしまう。
Ｖ０７Ｓの初期にはなかったが昨年半ば位から頻発する様に
なっているので、アプリ側の問題か。
Ｈ ＢａｎｄⅡでは６時以前に起きるとほぼ１００％この現象を
起こす為個別表示で追わねばならない。 酷い時は３度寝(^^;)>
問題点３についてはそれぞれが分割して記録されているので正味の睡眠時間が
分かるが、問題点１についてはトイレ迄の記録が消えるので使えないデータに
なってしまう。
《心拍計/血圧計》
Ｖ１０は双方共に狭い範囲でしか計測値が動かないので現状では意味のある
計測値が得られてはいない。 計測時間幅の中の平均値としても疑問な値。
Ｖ０７Ｓは手首血圧計の計測値とは差はあるもののそれなりの変動を示す。
いずれにせよ双方共にこの値は何かの判断基準に出来るレベルの精度はない。
以下の図は同じ日のＶ０７ＳとＶ１０の示したデータです。
V10 はもう暫く使ってみますが現状より改善せねば使えません。
V07S はいよいよバッテリーがダメになり、１日に２度充電しなければならなくなって来ましたのでもう完全にお釈迦です。 それにベルトの先端部の輪っか（取り落とし防止用）が千切れそうになっています。
値段が値段なので致し方ないのかもしれませんが、最近の結構な値段のスマホ等もそうですがバッテリーを交換出来なくして使い捨てにし新しく買わそうというサモシイ発想(^^)・・・アップルが最初じゃなかった？ これもアップル嫌いの原因の一つ。
そしてこれ、２年ももたない代物。 交換用バンドを買おうかと思っていましたがバッテリーがへたってはです(^^;)
それとアプリのＨ Ｂａｎｄは主機能部分で弁別能力が更新される度に劣化しているみたいです。
V10 は２０１８年の後期型の様で同じアプリで動作する V16 という物が2019年版として出ている様です。
ただ、未だ２０１９年型が出揃ってはいない様ですので暫く様子を見て再度検討してみようと思っています。
上記の機能部分については何れも今の考え方では精度の向上は期待出来そうにありません。
睡眠に関しては、就床と起床を手操作でも設定出来る様にする方が確実に精度が出ますので、自動検知に加えて手動設定を追加する方が検知ロジックを弄繰り回すよりも賢明ではないでしょうかね(^^)
yoiyasu という所が扱っているスマートブレスレットＶ１０とＨ ＢａｎｄⅡ というアプリの組み合わせで使っていますが、正直なところ前機種のＶ７ＳとＨ Ｂａｎｄ との組み合わせの方が精度が高い様です。
アプリのアップデートがある度に逆に精度が落ちている様で少々ゲンナリしています。 色々使い勝手を上げようとしているのでしょうが、私の様にこの種の物を使う方の一般的パターンとは少し異なる者には合わなくなって来ています。
どこがか？
《睡眠時間計測精度が落ちた》
私の就寝サイクルは 就床 ： 21:30 ～23:00 起床 ： 4:00～5:30
問題点１ 01:00 頃迄に一度起きてトイレに行くとこれが就寝として
扱われる為、それまでの睡眠時間が無視されてしまい
計測結果が意味を失う。
１５％位は就寝直前に薬を飲み、９時台に寝ているのでこれ位の
確率で使えないデータになる。
問題点２ トイレ起床を捕捉しない事態が起き始めた。
Ｖ０７Ｓを使っていた時にはなかったと思う。
問題点３ 起床が早いと８時位迄の間、デスクワークをしている間が２度寝
扱いになってしまう。
Ｖ０７Ｓの初期にはなかったが昨年半ば位から頻発する様に
なっているので、アプリ側の問題か。
Ｈ ＢａｎｄⅡでは６時以前に起きるとほぼ１００％この現象を
起こす為個別表示で追わねばならない。 酷い時は３度寝(^^;)>
問題点３についてはそれぞれが分割して記録されているので正味の睡眠時間が
分かるが、問題点１についてはトイレ迄の記録が消えるので使えないデータに
なってしまう。
《心拍計/血圧計》
Ｖ１０は双方共に狭い範囲でしか計測値が動かないので現状では意味のある
計測値が得られてはいない。 計測時間幅の中の平均値としても疑問な値。
Ｖ０７Ｓは手首血圧計の計測値とは差はあるもののそれなりの変動を示す。
いずれにせよ双方共にこの値は何かの判断基準に出来るレベルの精度はない。
以下の図は同じ日のＶ０７ＳとＶ１０の示したデータです。
| 
|
| V10 HOME表示 | V07S HOME表示 |
| 
|
| V10 睡眠（実質部） | V07S 睡眠 |
| V10 では6:05-7:35が ２度寝扱いになっている。 起床時間が4:30-5:45位 なのでこれ以降8:00迄を ２度寝扱いする確率が 徐々に増え４割以上に なっている。 下の２図はトイレ起きを誤認 した時のもので V10 の就寝は トイレから帰って布団に 入った時になっている。 V07S はトイレ起きを捕捉して おらず、後ろの覚醒は起きては いないもの |
| V10 睡眠（誤検知） | |
| 
|
| V10 トイレ起き誤認 | 同日V07Sのデータ |
| 
|
| V10 心拍数 | V07S 心拍数 |
| 
|
| V10 血圧 | V07S 血圧 |
V10 はもう暫く使ってみますが現状より改善せねば使えません。
V07S はいよいよバッテリーがダメになり、１日に２度充電しなければならなくなって来ましたのでもう完全にお釈迦です。 それにベルトの先端部の輪っか（取り落とし防止用）が千切れそうになっています。
値段が値段なので致し方ないのかもしれませんが、最近の結構な値段のスマホ等もそうですがバッテリーを交換出来なくして使い捨てにし新しく買わそうというサモシイ発想(^^)・・・アップルが最初じゃなかった？ これもアップル嫌いの原因の一つ。
そしてこれ、２年ももたない代物。 交換用バンドを買おうかと思っていましたがバッテリーがへたってはです(^^;)
それとアプリのＨ Ｂａｎｄは主機能部分で弁別能力が更新される度に劣化しているみたいです。
V10 は２０１８年の後期型の様で同じアプリで動作する V16 という物が2019年版として出ている様です。
ただ、未だ２０１９年型が出揃ってはいない様ですので暫く様子を見て再度検討してみようと思っています。
上記の機能部分については何れも今の考え方では精度の向上は期待出来そうにありません。
睡眠に関しては、就床と起床を手操作でも設定出来る様にする方が確実に精度が出ますので、自動検知に加えて手動設定を追加する方が検知ロジックを弄繰り回すよりも賢明ではないでしょうかね(^^)
