VAIO Pro 13のブルースクリーン → バッテリーオフボタンで復活？

突然、画面が固まって「VESMgrsub.exe」がエラーとか何だとか出てきて、最後にはブルースクリーンになって再起動。

再起動直前のブルースクリーンには「CRITICAL_PROCESS_DIED」というダイイングメッセージ。調べても意味がわからない。

仕方なく再インストールしてみた。また出た。

もう一度、再インストール。今度はSSDを完全にフォーマットし直して。

そしたら、しばらくは大丈夫っぽかった。

…ついさっきまで。

家から持ち出すためにスリープにして、職場で電源を入れたら、ブルースクリーンの嵐。再起動しても5分ともたずにブルースクリーン。

システムの回復で数日戻してもダメ。ってことはレジストリとかの問題じゃない。まぁ、それは前にも試してるからわかってるけど。

…もしかして。

再起動とかシャットダウンとかしてるけど、結局Windows8/8.1って、UEFIがらみでちゃんと電源落としてることにならないんだよね。

だから、本当に電源を落とすというかリセットするなら、ノートパソコンの場合電池を抜かないといけない。

ところがVAIO Proは電池が内蔵。抜けない。

その代わり「バッテリーオフボタン」を押せばいいのかな？

とりあえず、シャットダウンして、ひっくり返して、シートバッテリー外して…

ポチッとな。

シートバッテリーつけ直して、ひっくり返して、電源スイッチ押して…

おや。

どうも、直ったっぽい？

少なくとも、起動直後にブルースクリーンが出ることはなくなった。

う～む。

そりゃ、そういう目的で用意されたボタンだから、押してみるってのは有りだと思うよ。

でもね、ちょっと想像がつかないよ、CRITICAL_PROCESS_DIEDと言われてバッテリーオフってのは。

とにかく、今後は覚えておきましょう…何かあったら、とりあえずバッテリーオフボタン。再インストールの前にバッテリーオフボタン。

WindowsとMendeley・謎と恐怖のジャンクション

あかん。もうダメだ。諦めるしかない。

Mendeleyの制限（ある意味バグ？）であるところの、

「"%USERPROFILE%\AppData\Local\Mendeley Ltd\Mendeley Desktop\Downloaded"にダウンロードしたファイルをFile Organizerで移動したければ、移動先のフォルダは同じパーティション内になければならない。」

という問題について。

そもそも、いろいろな手段で入手したPDFファイルをMendeleyがFile Organizerを使って一箇所にまとめてくれる、ってのがありがたいのだが、上記の制限（バグ？）があるためにいろいろ困っている。

My Documentsとか、あれこれのデータファイルをシステムパーティション（ドライブ）から独立させるためにいろいろやってんのに、WindowsのあるCドライブからDドライブにFile Oranizerがファイルを移動してくれない。

でも、Dドライブにフォルダを作って、Cドライブのどっかからジャンクションを張っちゃえばいいんじゃない？んで、File Organizerにはジャンクションの方を指定すれば見た目は同じパーティションになるでしょ？

…そう、「一見」うまくいったように見えた。

しかし。

ジャンクションを通して実体ファイルにアクセスするとき、どうやらファイル名の扱い、特にUTF文字に難があるような気がする。具体的には、実体ファイルを同じパーティションに置くようにしたときには問題ないのに、ジャンクションを通して別パーティションに置くようにした場合にはファイル名がぶっ壊れてしまうものがある。ファイル自体は壊れていないが、ファイル名がおかしくなるのでMendeleyからはアクセスできなくなる。

そういうファイルには「õ」だとか「Á」だとかという文字が入っている。

ってことは、やっぱりWindows的に、ジャンクションを介するとファイル名の文字コードがうまく渡されない危険があるってことにならないかな？Mendeleyのファイル処理との関連もあるのかもしれんけど。

で、これまでいろいろ困ってたことって、この問題が関わってるんじゃないかな？と。なんかね、Windowsの内部的にはUTF-16LEなのに、表面的というかファイルのやりとりとかをする時にはUTF-8でやってるような気がするんだけど。その辺でうまくいかないとかって、自分の理解度じゃ追い込めないし改善・回避方法も皆目見当がつかない。

だとしたら、もう諦めるしかない。同じパーティションのどこかに実体のフォルダを作り、そこをFile Organizerの移動先を指定する以外に方法はない。

なんか釈然としないけど、仕方ないな…

WindowsのコマンドプロンプトでUnicodeのファイル名を扱うためのバッチファイルをどうたらこうたら。

とりあえず目的は果たしたんだけど、イマイチまだわかってない感じがする。

でも、一応備忘録としてメモしておこう。

まずは復習。

Windowsのコマンドプロンプト（cmd.exe）でウムラウトやアクサンのついた文字を使いたかったら、コマンドプロンプトを開いた後にもう一度cmd.exeを「/u」オプションをつけて実行する。

たとえば、そういう文字のついたファイルを含むたくさんのファイルをいっぺんに処理するため、バッチファイルを作る。まずはディレクトリ内の全ファイル名を取得してみよう。

dir /b > DirList.txt

これでカレントディレクトリのファイル名がDirList.txtに1行1ファイルで出力される。

このファイルを開くと、その文字コードはUTF-16LE（BOM無し）になっている。

さて、このファイルをあれこれして、バッチファイルを作ったとしよう。

バッチファイルをそのままUTF-16LE（BOM無し）で保存すると、なんとこれが動かない。バッチファイルの最初の1文字をコマンドとして処理しようとして、「そんなコマンドないよ」と文句を言ってくる。

で、このバッチファイルをどうすればいいかというと…UTF-8（BOM無し）で保存する。内容は全く同じ、でもこっちじゃないと動かない。

そして、更に、このファイルをコマンドプロンプトでそのまま実行すればいいのか、というと…

コマンドプロンプトのコードページを切り替えないといけないんだな。じゃないとウムラウトなどは「半角カタカナ」になっちゃう。

chcp 65001

これでコマンドプロンプトの表示がUTF-8（BOM無し）になる。やっと作ったファイルが実行できる。

いやいや、なんとめんどくさい。

特に訳がわからないのが、dirコマンドで出力されるファイル名をリダイレクトしてファイルに流し込むとUTF-16LE（BOM無し）になるくせに、コマンドプロンプトのコードページは1200（UTF-16LE）に切り替えようとするとエラーになっちゃうもんだから65001（UTF-8）にせざるを得なくて、すると実行するためのバッチファイルの形式はUTF-8にしなくちゃいけない、と。

なんで統一してくれないんだろう。なんでcmd.exeを最初っからUTF-8にしてくれないんだろう。なんでdirコマンドはUTF-16を吐き出すんだろう。

まったくわからない。

でも、一応はやりたいことができるようになった。