おっしゃる通り、あまり電源を入れないほうがいいです。
一発で終わらせるのが理想なので、そのための準備をしてから一気にやってしまいたい。

カックンカックンいうのは嫌ですね。
状況が変化している、つまり再現性がない時点で、ハードウェアの問題である可能性が極めて高いです。

問題が発生した時の基本的考え方として、できる限り問題点を単純に分割してテストすべきです。
つまり、外付けハードディスクであれば、分解して内蔵ハードディスクを取り出し、マザーボードとSATAで接続して動作確認します。
手近にデスクトップパソコンがないと、接続しようにもできないかもしれませんが、これは必須の作業です。
外付けハードディスクとして用いられている基板の影響の排除、
また、SATAという外部記憶装置本来の接続規格でマザーボードと直結することで、パソコンにとってシンプルな動作をさせます。

分解方法は、こちらのサイトが参考になるかと。
筐体は同じと思われますので。

当然、メーカーの保証はなくなりますが、
中のデータかハードディスク本体、どちらが重要かで判断してください。

SATAでの接続ができたら、必要なデータの退避を最優先します。
普通にアクセスできないようなら、素直にファイナルデータ等を使ったほうがいいと思います。
現時点、ハードディスクが正常動作しているようには思えないので。

ハードディスクの状態確認方法としては、「CrystalDiskInfo」を使ってSMART情報を確認します。
当サイトではこのへんにそれっぽいことを書いてあります。
SMART情報のチェックだけなら、ほとんど負荷はかかりません。

USB-SATAブリッジが壊れてるだけだといいんですけどね。

デスクトップパソコンがない状態で、当該ハードディスクをどうやって取り付けたのかがよくわかりません。

でも、Windowsは起動時に接続されている記憶装置を自動的にマウントしにいくので、そこでコケてるんだろうなとは思います。
ファイルシステムを認識できないんでしょうね。
先回も書きましたが、ハードウェアの問題、つまり物理障害の可能性が高いですし、
追記内容から推測するに、内蔵ハードディスク自体の問題でほぼ確定だと思います。

ファイナルデータでは、パーティションを探しません。
パーティションを認識できていればそれでいいんですが、論理構造を認識できない現状がある以上、ファイルを抽出できるかどうかにかかっています。
つまり、完全な意味での復旧は不可能と考えており、データの欠損があってもファイルを復元できるかどうかというところです。

ファイナルデータの操作としては、
「ファイルの復元」→「フォーマットした場合」→ディスク自体を選択（ドライブではない）
で、「検索」します。
それでもファイルが見つからないかもしれません。

理想的には、同容量以上のハードディスクをもう1台用意し、エラーを無視してディスククローンを作ってしまいます。
そこから、物理的には正常動作するクローンディスクに対して論理的な復旧作業を行います。
ディスククローンの作成には、Linuxのddコマンドを使います。
たとえばコピー元をhda、コピー先をhdbとして、
dd if=/dev/hda of=/dev/hdb conv=noerror,sync bs=4096
とか。

しかし、ハードディスクが動いてくれなければ結局データは抽出できません。
操作を間違うとデータが吹っ飛ぶので、調べても意味がわからなければやめといたほうがいいです。

モノが壊れてたら、部品交換しなきゃどうにもなりません。
個人でやるにはこのへんが限度だと思います。