Windowsの最近のブログ記事

ほんの 2日前に"Windows 10 の「勝手に再起動」を止める"というエントリーを書いたばかりなんだけど・・・

今夜、勝手に再起動された!!

22時くらいから寝落ちして、夜中の 2時に目が覚めたので実際に何時に再起動したのかはわからないが、多分、アクティブ時間の終了する 24時なのだろう・・・
つまりローカルグループポリシーエディター(pgedit.msc)で設定した「スケジュールされた自動更新のインストールで、ログオンしているユーザーがいる場合には自動的に再起動しない」を有効・・・は Windows 10 によって無視されてしまったということだ。

どこまでもゲスな OS め・・・。そもそも Microsoft は「もう!Windows はセキュリティが甘いって散々悪口言われて悲しい!あ、そうだ、Windows Update のあと強制再起動しちゃお!そしたら危ない状態で放置されることがなくなるから、皆『さすが Windows』って呼ぶようになるぞ!」という小学生が考えるような論理でこの仕様を決めたのだろう。あるいは、仕様を決める権限をもったじいさんが呆け始めてるか・・・

それくらい「勝手に再起動する OS」という存在はヤバい。ありえない。「しつこく再起動を促す」は「あり」。「勝手に再起動」は「ない」。「いや、ありでしょう?」と言うエンジニアは思慮の足りない馬鹿である。

というわけで更に調べてみると、上記の「自動に再起動しない」の設定の説明に「更新を有効にするには、コンピューターを再起動する必要があります」とあった。
あれ?(^^; 確かに「有効」に設定後、再起動はしていない。これ、Windows Update の「更新」のことだと思ったんだけど、「自動に再起動しない」の設定を「更新」したときのことなんかな?(^^;
まあ、そうであれば今夜勝手に再起動されたので、次回以降はこんなこともなくなるだろう。

20200614_windows2.jpg

それともうひとつ。
「[自動更新を構成する]ポリシーが無効になっている場合は、このポリシーは効果はありません」とある。「自動更新を構成する」はなんの設定もしていない「未構成」状態だった。「未構成も駄目」なときは「無効または未構成」と説明されるので「無効になっている場合」という説明であれば「未構成」は関係ない気もするが・・・

一応、これも「有効」にし、「自動ダウンロードしインストールを通知」にしておいた。
先程、「いくつかの更新プログラムが必要です。インストールするには、このメッセージを選択してください。」のメッセージが出たから、この設定は PC を再起動しなくても大丈夫なんだろう。

さて、これでどうなるか?
まあ、今のところ「インストールを止めている」状態だから再起動はないけど・・・
これで更に再起動するようなら、Dell に「おたくのパソコン、変じゃない?」と言うてみるか(笑)

さっさと調べて対応すればよかったのだが、なんとなくほったらかしにしてて二度も痛い目にあった「Windows 10 での Windows Update 後の勝手に再起動問題」。

今年の 3月頃、やっと Windows 10 Pro を導入したんだけど、こいつ、「再起動しますか?」と聞くこともなく勝手に再起動しちゃうのね。「アクティブ時間」外であれば。(ちなみに俺は 6:00~24:00 をアクティブ時間に指定している)

俺は自宅でプログラムを作るのが仕事で、特に仕事の時間を決めているわけではなく、いや、「ビールは 18時以降」と決めてるけど、ビールを飲んだあともプログラミングは続けて、「できるところまでやって寝落ち」が基本なのだ。
そのため、参照している資料は開きっぱなしだし、テキストエディタで入力したメモが未保存のまま、いや、時にはプログラムソースもまだ保存しないまま気を失っていることもある(笑)

Windows 7 の場合は、「今すぐ再起動するか?」と確認があり、「する」を選ばないかぎり(ほっておけば)再起動はされなかったからよかった。ところが、Windows 10 の場合は「アクティブ時間であれば返事がなくても再起動する」のである。

・・・って、多分、みんな何年も前から Windows 10 だから知ってるよね。俺がやっと今頃になって 10にしただけでね(笑)

で、二度も「記憶を頼りに再ソースコーディング」という苦労を経て(^^;、やっと「勝手に再起動、止めなきゃ」となったのである。なぜなら、昨日から「アクティブ時間外になったら再起動するぞ」という脅しが表示されるようになったからである(^^;

20200611_windows_update.jpg

で、騙されちゃうのが、Windows 10 って右ボタンクリックで開く「設定」の中に Windows Update って項目あるじゃん。なので、ここを重点的に調べていたのだがわからん。騙された。間違っていた・・・(^^;
「勝手に再起動を止める」には gpedit.msc(ローカルグループポリシーエディター)を起動し、左ペインから「コンピューターの構成」→「管理用テンプレート」→「Windowsコンポーネント」→「Windows Update」を選択。で、右側のペインから「スケジュールされた自動更新のインストールで、ログオンしているユーザーがいる場合には自動的に再起動しない」を選択し、これを「有効」にするのだ。

これで、大丈夫なはず。
とりあえず、昨夜は再起動は行われなかった。
しかし、「操作を複雑にする」ことが「安全」だという間違った認識をしている Microsoft 製品だ。どんなドンデン返しがあるかもわからず、まだ不安である(笑)

<追記>
駄目だった・・・。詳細は"Windows10 の「勝手に再起動」は実行された"にて。
以前このブログでも何度かエントリーを書いた SONY RC-S380 で FeliCa カードを読み込んだ情報を Python で利用する話。

Windows 7 Professional で開発をしてたんだけど、今回、環境を Windows 10 Pro に移した。

その際、ちょっと Windows 7 の時何をやったかすっかり忘れてて、うろ覚えでセットアップして「プチはまり」をしたので環境構築についてメモっておく(^^;

ちなみに、Python 3.8.3 はすでにインストールされている。

1.WinUSB ドライバのインストール

https://zadig.akeo.ie/ からダウンロードした zadig-2.5.exe を使って WinUSB のインストールを行う。

RC-S380 を Windows 10 に接続したときに自動でインストールされた sonynfcport100c(v1.5.7.2)を WinUSB(v6.1.7600.16385)に Replace する。

・・・が、これ、本当に必要だったのか?Windows 7 のときには必要だったが、Windows 10 だと sonynfcport100c ドライバがインストールされているので、WinUSB ドライバを入れる必要があるのかどうなのか?

もし、このページを見てセットアップをしようと思っている人は、一度、この作業無しで RC-S380 が読めるか試してみてほしい。俺は面倒臭いので試さないけど(笑)

2.pip のバージョンアップ

必須ではないが、モジュールのインストールの度にワーニングが出るのでバージョンアップしておく。

コマンドプロンプトで、
python -m pip install --upgrade pip

3.nfcpy モジュールのインストール

コマンドプロンプトで、
pip3 install nfcpy

libusb1  1.8
ndeflib  0.3.3
nfcpy    1.0.3
pip      20.1.1
pyDes    2.0.1
pyserial 3.4
などがインストールされる。

4.libusb-1.0.dllのインストール

から最新版ダウンロード。
今日時点の最新版は、

ダウンロード後、展開したファイルを、Windows システムフォルダにコピー。

・64bit版
展開場所\MS64\dll\libusb-1.0.dll → C:\Windows\System32 にコピー

・32bit版
展開場所\MS32\dll\libusb-1.0.dll → C:\Windows\SysWOW64 にコピー

余談だが、64bit プログラムを格納する場所が System32 だとか、このわかりづらい構成はどうにかならんものか?(^^;>Windows

以上で、Windows 10 でも、Python プログラムの中から FeliCa カードが読めるはずだ。

ちなみに、作成したプログラムの中で HTTP プロトコルを使ってサーバにカード情報を飛ばしているので、requests モジュールも pip でインストールしないといけないのだが、これは、まあ、俺独自の話なので(笑)

いつも持ち歩いている Macbook Pro には VMware Fusion の上で Windows 7 を動かしていて、そこで使っている Microsoft Office は 2003 である。

お客さんの中に、昔うちで Access と Excel を使って作ったシステムの利用者さんがいらっしゃり、そのバージョンがずっと 2003 のままで動いているので、メンテナンス用に残しているのだ。

しかし、他のお客さんから Excel で資料をもらうと、最近は大概 .xlsx ファイルである。無理やりな方法はなくもないが、基本的に Excel 2003 では開けないので、Excel だけ 2010 を入れている。

で、Macbook はこんな感じなのだが、自宅で仕事で使っている PC は(2、3台あるが)全部 Microsoft Office 2013 である。
そのため、自宅では .xls ファイルも 2013 で開くので、それで上書き保存などしてしまうと(マクロなどが含まれていると特に)、.xls ファイルなのに 2003 ではエラーが出て開けなくなってしまうのである。

そこで、Macbook でも .xls ファイルの起動ソフトを Excel 2010 にしたいのだが、これがうまくいかない。

Microsoft Office の「バージョンの異なる Office が同じレジストリエントリを利用する」という謎仕様のためである。

例えば「ファイルを開くプログラムの選択」で「参照」ボタンを押し、「C:\Program Files\Microsoft Office\Office14\EXCEL.EXE」を指定しても、選ばれている Excel のリンクを変更することはできない。EXCEL.EXE はあくまで最初にインストールした EXCEL.EXE が正(レジストリに登録されている)なのである。

で、コマンドプロンプトで、

"C:\Program Files\Microsoft Office\OFFICE14\EXCEL.EXE" /regserver

と実行すると、2010 に規定の EXCEL が切り替わるはずなんだけど、「最初に Office 2003 をインストール→ Excel 2010 だけ更にインストール」という入れ方の場合は駄目なのか、全然切り替わらなかった・・・

まあ、先に Excel 2010 を立ち上げて、それから .xls ファイルを開けばいいんだけど、面倒くさいんでねえ。ファイルをダブルクリックで、ちゃんと Excel 2010 が起動するようにしたいわ・・・

方法を御存知の識者の方がいらっしゃたら、ぜひご教示を。
Windows 7 Home + MS Aceess 2003 というレガシーな環境で、新元号「令和」対応をしないといけないんだけど、VB モジュールで

Format("令和01年05月01日", "yyyy/mm/dd")

こんな風に Format 関数の結果をセットしてみても、2019/05/01 が返ってこない(Null になる)。

Windows の開発環境に詳しい方に聞いてみると、サポートの切れている MS Access 2003 でも、Format 関数は OS のレジストリを見るので、 OS がサポートされていれば大丈夫。ただし、まだ「令和」関係の Windows Update は提供されていないとのことだった。

そうか、もう「令和」関係の Update は出てて、Office 2003 系はサポート外だから駄目って話なのかと思ってた。
そうか、そうか、まだ Update が出てないだけなのね。

「とりあえず手動でレジストリに令和の情報を登録すれば正しく Format 関数も動きますよ」ということだったので、ググってみると、


こういうページがあった。

その中に書いてあるとおり、コマンドプロンプト画面で、

REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras /v "2019 05 01" /t REG_SZ /d "令和_令_Reiwa_R"

を実行。「この操作を正しく終了しました。」のメッセージを確認後、念の為 MS Access 2003 の画面を再起動。
見事、Format("令和01年05月01日", "yyyy/mm/dd") で 2019/05/01 が返ってくることを確認した。

マウスが使えないと復活作業もしづらいんで、新たに PS/2接続のマウスを買ったり(家にひとつくらいあると思ってたんだけど見つからず(^^;;)と無駄な出費もしたが、やっと復活しホっとしている。

まあ、ショートカットキー調べてマウス無しで作業する面倒臭さを考えたら、そりゃマウス買った方がええからのお。金で解決じゃ。(ま、1,100円だけど(笑))

20190314_usb.JPG
結局、日本 ASUS のサイトから、ASUSTeK H81M-E 用の最新の USB ドライバを落としてきてインストールしたらすぐ復活した。

もしかしたら、前回、H81M-E 用のドライバ(オーディオとか、ネットワークとか)をまとめてインストールし直したのだが、その時、USB コントローラのドライバのインストールを途中で終わらせちゃったのかもしれない。
インストーラの動きを見ていると、先に古いドライバを削除していたので、ここで何らかの理由で終わらせちゃったとか。(記憶にはないが(^^;)

とりあえず、USB 接続している HDD や DVD ドライブが接続されたので、USB ポートは無事復活した様子。リブートしてみたけど大丈夫みたい。まだ、USB マウスは接続してみていない。
このまま PS/2 マウスでもいいんだけど、残念ながらホイールが反応せんのよね(^^; HID準拠じゃないんかいな?

<追記>
何をしたわけでもなく、ただ Windows を再起動したら、なぜかホイールが使えるようになった。
まあ、それがまさに Windows なんだけど、なんだかなあ(^^;
また自宅 Windows 機の障害である。
発生したのは、ASUSTeK H81M-E をベースに組んだ microATX 機だ。Windows 7 Professional が載っている。

Windows Update のために再起動したら、一切マウスが反応しなくなった。
正確には、USB I/F(インタフェース)が全て死んでいる。だから USB 接続のマウスも一切使えないわけだ。

ちなみに、このマシンのキーボードは PS/2接続なので使える。レガシーでよかった(笑)

20190310_asus_bios.JPG最初、ハードウェア的な問題かと思ったのだが、UEFI BIOS 画面ではマウスも USB 接続した外付け DVD ドライブも生きている。

その後、Windows が起動している最中に USB I/F が全部死んじゃう感じ。
外付け DVD ドライブのランプが未接続のオレンジ色に変わるのでわかる。

背後の 6箇所の I/F も、フロントの 2箇所の I/F も USB は全滅である。

昨夜は状況確認で終わってしまったが、まずは Windows の修復を試みて(DVDからインストーラは起動するし、マウスも使えるはずである)、それがダメなら、PS/2マウスを入手して、ASUS関係のドライバの入れ直しかな?(←このドライバ関係が一番怪しいと思ってる)

早く安定して自宅仕事が出来る状態にしないと・・・(^^;;

しかし、ほんま、Windows というのは面倒くさい OS だ(^^;;
Windows バックアップも、Acronis Backup のディスク単位のバックアップも失敗してしまうサーバがあった。

Acronis Backup で OS のインストールされているディスクをバックアップ対象に指定しても、「バックアップに失敗しました バックアップ対象に指定した項目が見つかりませんでした」となる。ディスクを認識しない様子。

Acronis のサポートとメールでやり取りしながら原因を調べると、「Windows が GPT パーティションのサイズを誤って認識している。具体的には、パーティション情報の『論理境界』の情報(論理ドライブのサイズ)が、物理ディスクの大きさの範囲外になっている」とのこと。

誤認識した原因は不明。
Windows インストール時に特に変わった操作はしていないし、そもそも、何らかの操作で OS に GPT パーティションのサイズを誤認させたり、あとで手動で値を変更したりは不可能。そんなことができたら大問題だ(^^;。そのため、Windows の(ドライバ等の)バグが一番怪しいと個人的には思うのだが・・・

ということで、残念ながら Windows 再インストール案件。

Windows インストーラが起動したところで(使用言語を決める画面とかで)、「Shift + F10キー」でコマンド入力画面を起動し、DiskPart ツールを使い、手動で GPT ディスクに変換してやる。

> diskpart

DISKPART> list disk

  Disk ###  Status        Size     Free     Dyn Gpt
  --------  ------------  -------  -------  --- ---
  Disk 0    Online         1862GB       0B       *

DISKPART> select disk 0

Disk 0 is now the selected disk.

DISKPART> clean

DiskPart successed in cleaning the disk.

DISKPART> convert gpt

DiskPart successfuly converted the selected disk to GPT format.

DISKPART> exit

と、ここまで手動で操作し、Windows のインストールを続ける。

これで、今度は Windows は正しく GPT パーティションの情報を認識してくれたので、Acronis Backup でのディスク単位イメージバックアップも成功するようになった。

・・・が、Windows 再インストールしか手段がないとか・・・やれやれ・・・
Windows 7 Professional SP1 で Electron の開発環境を作成する。

Mac OS X のときと一緒で、まずはもっとも重要なプログラム実行エンジンである Node.js のインストール。

Node.js のダウンロードサイトから、


最新のインストール用プログラムを落としてくる。2019/01/04 現在では、node-v10.15.0-x64.msi が安定版の最新バージョンだった。

インストール方法は書かない。MSI ファイルを実行して、あとは指示に従うだけ。某社のソフトみたいにこっそり McAfee を入れたりしようとはしないので安心しとけ(笑)
「Finish」ボタンを押して終わり。

コマンドプロンプトで、node を実行しても、

>node -v
'node' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。

だったものが、ちゃんと、

>node -v
v10.15.0

このように実行される。(インストール後、)

次に、Electronのインストール。
Electron は Node.js のパッケージの一つなので、パッケージ管理コマンドでインストールを行う。

ところで、Mac OS X ではグローバルインストールを行ったのだが、それだと Electron の Update を行った時などに、動かないプロジェクトが出てくる可能性があるそうだ。
(バージョン依存の機能なんか使ってる場合だな)

というわけで、さきにプロジェクトを作って、そこにローカルインストールすることにする。このプロジェクトで使われるだけの Electron だ。

今回は個別案件管理システムを作りたいので、kobetsu という名前で作ろう。

>mkdir \Users\shinoda\electron\kobetsu

>cd \Users\shinoda\electron\kobetsu

>npm init
This utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.

See `npm help json` for definitive documentation on these fields
and exactly what they do.

Use `npm install <pkg>` afterwards to install a package and
save it as a dependency in the package.json file.

Press ^C at any time to quit.
package name: (kobetsu)
version: (1.0.0)
description: 個別案件管理
entry point: (index.js)
test command:
git repository:
keywords:
author: shinoda
license: (ISC)
About to write to C:\Users\shinoda\electron\kobetsu\package.
json:

{
  "name": "kobetsu",
  "version": "1.0.0",
  "description": "個別案件管理",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "shinoda",
  "license": "ISC"
}


Is this OK? (yes)

ちゃんと package.json が出来上がっているかな?

>ls -la
total 1
drwxr-xr-x 2 shinoda Administrators   0 Jan  4 11:16 .
drwxr-xr-x 3 shinoda Administrators   0 Jan  4 11:14 ..
-rw-r--r-- 1 shinoda Administrators 228 Jan  4 11:16 package.json

ばっちり。では、Electron のローカルインストールを行う。

>npm install --save-dev electron

> electron@4.0.0 postinstall C:\Users\shinoda\electron\kobetsu\node_modules\electron
> node install.js

Downloading tmp-11268-1-SHASUMS256.txt-4.0.0
[============================================>] 100.0% of 4.74 kB (4.74 kB/s)
npm notice created a lockfile as package-lock.json. You should commit this file.

npm WARN kobetsu@1.0.0 No repository field.

+ electron@4.0.0
added 145 packages from 127 contributors and audited 201 packages in 99.081s
found 0 vulnerabilities

以上で、インストールは終了。

Mac OS X のときと同様の index.js と index.html を作成して実行してみる。
ちなみに、ローカルインストールした Electron はプロジェクトのディレクトリの下の .\node_modules\.bin\electron に実行体は存在する。

実行時は(現在、プロジェクトのディレクトリにいるとして)、

>.\node_modules\.bin\electron .

と指定する。

20190104_electron.jpg

このように、Mac OS X 版同様に表示される。

ばっちりである。
今日は朝から自宅の Windows 7 機をお掃除。
最近起動に時間がかかるようになったので、自動起動するサービスの停止と、スタートアップに登録されているアプリケーション(実際はショートカットだけど)の削除。

メモリの使用量もちょっとは減るだろうが、そもそも俺、Google Chrome が常に30タブくらい開いてるもんで(^^;、Chrome が使ってるメモリ量だけで 16GB中の 6~7GBを占める有様(^^;
サービス止めて、何MBか使われていたメモリを解放したところで意味なし(笑)
あくまで、少しでも起動時間が早くなってくれれば。

削除(停止)したサービスとアプリは以下のとおり。一応、メモっとく。

<標準サービス>
ASRock IO Monitor Service
Capture Device Service

<拡張サービス>
Cryptographic Services
Diagnostics Tracking Service
HP CUE デバイス ディスカバリ サービス
Microsoft IME Dictionary Update
Net Driver HPZ12
Remote Access Connection Manager
Telephony
Windows Firewall

<ログインユーザスタートアップ>
Facebook Gameroom
バッファロー らくらくアップデートツール

<全ユーザスタートアップ>
Adobe Gamma
HP Digital Imaging Monitor
TotalMedia BackUp & Recorder Monitor
TotalMedia Server

このアーカイブについて

このページには、過去に書かれたブログ記事のうちWindowsカテゴリに属しているものが含まれています。

前のカテゴリはUNIXやLinuxです。

次のカテゴリはデータベースです。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。


月別 アーカイブ

電気ウナギ的○○ mobile ver.

携帯版「電気ウナギ的○○」はこちら