LoginSignup
7
4

More than 1 year has passed since last update.

保存されたデータは1024文字に切り捨てられました。(復旧済)

Last updated at Posted at 2019-08-26

環境

Windows10

トラブル発生

慢心でした。Windows、慣れたつもりでいたのです。
初歩的なミスを犯しました。
良く理解していないのに、コピペしたコマンドを実行してはなりませんでした。

救済があります、そのコマンドプロンプトを閉じずに読んでください。

具体的に何が起きたか

環境変数、いちいち"システムの詳細"をコントロールパネルから開いて設定するのすごくめんどくさい。
なのでコマンド憶えてちゃちゃっとコマンドプロンプトから設定しちゃおう、そう思いました。

setx PATH "%PATH%;$環境変数に設定したいパス"

見つけました。多くの場所でこのコマンドが紹介されています。
信頼している記事投稿サイトにも紹介されていました。
寝不足のせいもありますが、油断していました。

このコマンドですが、絶対に実行してはなりません

でないと、こうなります。

C:\WINDOWS\system32>setx Path "%PATH%;$環境変数に設定したいパス"

警告: 保存されたデータは 1024 文字に切り捨てられました。

成功: 指定した値は保存されました。

C:\WINDOWS\system32>

成功してないですよね。大失敗ですよね。
警告するくらいならなんでいったん止まってくれないんですか。

「システムの詳細設定」から恐る恐る確認したところ、バラバラ殺人の現場。

被害者はほかにもいます。これシリアルキラーですよね。
これまで隠れた被害は多かったでしょうし、この先も被害が出そうです。
http://www.codalabo.com/code/archives/31

また、某質問サイトにてこのコマンドを回答している方がいて、真に受けた質問者の方がそれを実行していたりしていました。
質問者の方の最後の一言は、例のエラーメッセージが出たという報告でした。
回答者になるときは気を付けようと思います。

環境変数たくさん(1024文字以上)登録していて、めんどくさがりな方、たくさんいらっしゃると思います。
むしろ、コマンドで環境変数を登録しようとする方であればこそ、たくさんの環境変数を登録している人が多いのではないでしょうか。

なので投稿しました。
恥ずかしい失敗なのであまり気が進みませんが被害拡大予防+被害回復支援のためです。備忘録でもあります。

解決法

レジストリに環境変数の実体が存在しています。
今回はユーザー環境変数の設定だったので、"コンピューター\HKEY_CURRENT_USER\Environment"にあるPathというキーの値がその実体です。

普段から レジストリのバックアップを取ったり、システムの復元ポイントを作っているなら、こうしたデータをバックアップから持ってきて回復することができます。
バックアップから復旧する方法についてはネットに沢山転がっています。
手間はそんなにかからないはずです。

私は、レジストリのバックアップなんて、半年前に取ったキリです。
復元ポイントも、パフォーマンスのために作っていませんでした。

バックアップをしっかり取ってらっしゃる方は、そうした記事を読むのもアリかと思います。
それで解決することもあるかと思います。
ただ、個人的には後述するリスクがあるため、そうしたバックアップからの復元はおすすめしません。
バックアップがある方にも、私含めバックアップを取っていない方向けの復元方法をおすすめします。

他の記事を読めではあんまりなので、本章ではこれ以降、バックアップからの復元方法についても軽く書いておきます。
では、これ以降はバックアップ取っていない方、バックアップがあるけれど推奨方法を試す方は読む必要がありませんので、ここをクリックして、次の章へと飛んでいただければと思います。


下記のバックアップからの復元方法を実行する場合には、特に留意していただきたい点があります。
それは私が知っている方法は、環境変数だけでなく他のレジストリも全てバックアップ日時のそれへと復旧する方法だということです。
つまり、環境変数以外にも影響があります。
例えば、インストールしたアプリが作ったレジストリキーが消えてしまい、アプリの動作不良が発生する恐れがあります。
自己責任でお願いします。

それでもバックアップを活用したいという方は、後述しますが、レジストリのバックアップを復元する前にもう一度バックアップを取ることをお勧めしています。
一応、 例のコマンドプロンプトを閉じずに 行った方が良いかもしれません。
そうすれば後から気が変わった時に、バックアップを取っていなかった方向けの復旧手順も試すことができます。
では、下記にバックアップを用いた復元法を書きます。

  1. Win + rから起動した「ファイル名を指定して実行」ランチャーの入力欄に、regeditと入力してEnterキーを押します。
  2. 起動したレジストリエディタ上でAlt + fキーを押してファイルメニューを開き、その中からインポートを選択します。
  3. ファイル選択のダイアログが出ます。
  4. バックアップファイルを選択すればインポートが開始されますが、 慎重に復元したいならそれより先に、先ほど開いたファイルメニューからエクスポートを選択して現状のレジストリをバックアップした後に、インポートを開始することをおすすめします。そうすればインポート後に不具合が起きても、今バックアップしたものをインポートしなおすことができます。

以上、インポートが完了すれば環境変数がバックアップ日時のものに戻っているはずです。

それでどうしたか

現場の保全のために閉じずにいたコマンドプロンプトが役に立ちました。
結論申し上げますと、例の殺人コマンドを実行したプロンプトで

echo %PATH%

これを実行してください。
可哀そうなPathさんの在りし日の姿、思い出せましたでしょうか。泣けますね。
出力されたパスを一個ずつ、丁寧に「システムの詳細設定」から設定してあげてください。
今度こそ手放してはなりません。
念のため、コマンドプロンプトの出力を 「メモ帳などにバックアップ」 してから、設定したほうが良いでしょう。
上記のコマンドの代わりに、

echo %PATH:;= @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ %

とすると多少はコピペしやすくなったりします。
ちなみにこれは環境変数を出力するコマンドであって、環境変数を書き換えるコマンドではありません。
トラウマになっていると思いますが、安心していただければと思います。

これで回復できました。
これの仕組みはそんなに難しいものではありません。コマンドプロンプトのインスタンスとかの話になります。
どこで読んだか忘れましたが、ググれば目につくネットメディアの記事に仕組みの解説があった気がします。

(また、このあと別の新たな問題が発生したので、その時のこと、解決に至るまでのこと等、後日投稿しようかなと思っています。この新たな問題については多くの方が言及してるので必要ない気もしますが。
キーワードは「2048文字」です。
追記(2022/7/8):結局投稿しませんでした。恥ずかしながら今では何を書こうとしたのか思い出せません。 )

これからはレジストリとか大事な部分のバックアップを意識して、バッチファイルを走らせます。

コマンドプロンプトを閉じてしまった方へ

私には以上の方法で精いっぱいです。
以上の方法はご飯食べてリラックスした時の思い付きでした。

これ以降は、私がそれを思いつくまでに色々考えたりしたことです。
正直、読むのは非推奨です。
私の場合、解決の候補や周辺知識となるキーワードにたどり着くまでに時間がかかったりすること多いです。
なので、そういった私のような方々のため、あるいは未来の自分のために書き残しました。

もし活用する自信がある方は、キーワードだけ拾って使っていただけたらと思います。
なぜなら、そもそもこの分野の知識が無いので間違った言葉を選んだり、勘違いしていることも沢山あるからです。
真に受けないという前提で。では書きます。

蛇足 : レジストリの復元について

最初は、レジストリのバックアップをとっていないことを何度も確認しました。

最後のバックアップ以降、色々遊んでいました。
環境変数にはたくさんのパスが登録され、それなりに便利になっていて(かつ、散らかっていましたが)、諦めきれませんでした。

レジストリの実体があればファイル復元ソフトとかで何とかなるかもしれないと思いました。
しかし、少し調べてみると、その望みが薄くなっていきました。
なぜなら、C:\Windows\System32\configに存在したハイブファイル(レジストリの実体?)が、Windows10のとあるバージョンへのアップデート以降は使われておらず、バックアップも取られないようになったそうだからです。

それでも、HDDのどこかに残骸が残っている可能性はないか、考えました。
しかし、復元ソフトで確実に見つけられる保証はありません。
むしろ復元ソフトが激しく動くせいでデータ消えることもあるんじゃないかとも思いました。

環境変数のコマンドはデータを上書きをしたはずです。
しかし、ドライバのメモリマッピングの方法次第では、物理的には上書きされていない可能性を思いつきました。
場合によってはカーネルモードでなくともそれにアクセスできるのではないか、とも思いました。
マッピングの仕組み次第で、それを利用してHDDのお目当てのアドレスへの参照を手に入れられるのではないかと。

ネットからデバイスドライバやらHALやらの情報にたどり着きました。
あと、MFTとか、関係しそうな技術も見つけました。
持っていたヘネパタ本とかインサイドWidowsなど引き出して読みました。
Linuxのカーネルやデバイスドライバのことも調べてみようかと思っていました。
あと、HDDメーカの資料とか、復元ソフト作っている方々の記事とか。

そうして低レイヤの知識に触れている最中、疲れてご飯を食べてる最中に前述したコマンドプロンプトのインスタンスを利用することを思いついたのです。
それで解決してしまったので、ここで見たことの多くは忘れました。

以上です、私が調べたことは。

最後に

トラウマになりました。

これから先、環境変数いじるときは
https://qiita.com/jeyei/items/2c385e4e0488a5fa2591#4
にある「環境変数の設定ダイアログを開く優良手順」つかいます。これは参考になると思います。

後日談

この投稿をしてしばらくの間は先に挙げた「優良手順」で満足してしまいました。

しかし、ネットに転がっているシェルスクリプトやバッチファイルにも環境変数を弄るコマンドが含まれていることがあります。
初歩的なことですが、自分の理解していないコマンドを実行することにはリスクがあります。

しかし現実に、それらを有効活用せずにPC使うのは難しいでしょう。
自分がいくら気を付けても、そうしたコマンドの実行を防ぐのは難しく、また、一律に防げば様々なソフトウェアの実行が不可能になります。
現代的PC生活においては常にリスクを犯していることを意識したほうがよいようです。

そのため、散々言われていることですが、やはり大切なものはバックアップを取ることが重要だと思います。
レジストリについてはバックアップを定期的に取るためのフリーソフトがある(自作バッチよりも信頼できる、長く多くの人に使われ信頼性が高いものがあります)ので、そうしたものを使うべきでしょう。

大切なものが何かについては今回の失敗で一つ知ることができました。

スペックに余裕のあるパソコンが多い今時においては、最初から仮想PCをメインとして使っていれば、フルシステムバックアップが容易だったりします。

あるいは、何かリスクを犯しそうなスクリプトを使うときはサンドボックス上で動かしてから、普段使いしている環境でそのスクリプトを動かすとかいう方法もあります。
ちなみに私は幾度か同じような失敗を繰り返してからその方法を取ることが多くなりました。
(サンドボックスはWindows10とかでは標準機能としてあるうえ、Sandboxieなどのフリーソフトでも簡単に導入できます。)

7
4
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
4