A partition table can be recreated without corrupting filesystem contents if you know the start sectors and sizes.

You can't if you can't even connect the disk to the computer without freezing the system. When a disk is detected, the first thing the kernel does is examine the partition structure. For this case, the kernel goes into an infinite loop in the driver, and the only recourse is pressing the reset button or forcing a power-off. Even disconnecting the drive won't break the loop.

I'm no expert on how kernels do what kernels do, but I have to believe the kernel(s) used by this OP have broken error handling, and some other kernel(s), older and/or newer, would avoid the freezing, allowing progress to be made. Assuming I only had one PC to try with, which is not the case, I'd boot a Knoppix CD, DVD or stick, and if that didn't work, I'd try a newer or older Knoppix. If no joy there, I'd find a live Linux that is not Debian-based and try again. Even systemrescuecd or something else of that ilk might be useful at least to clear the MBR sector.

I can confirm that SystemRescueCD locks up instantly when it sees the drive. Windows 7 doesn't lock up, but won't let you access the drive with any tool, and also refuses to shut down (have to force power-off) with the drive connected. (It wouldn't allow me to disconnect the drive from the VM either, so I don't know what would happen if you pulled the plug on a physical drive.)

Of course all of this is based on your problem really being with an infinite loop in the logical partitions.

How can you confirm what happens on OP's hardware? BilboBaggins is the OP.
Which tools were tried? Any low level tool should be able to do something as long as logged in in maintenance mode or as admin. If it was me booted to Windows, I'd be trying with DFSee (which I have a license for), and if it wouldn't do anything useful, I'd be back to trying DFSee on DOS, Linux or OS/2, and if those wouldn't work either, I'd either write the HD off as unsalvageable, or if desperate for something on it, be sending it to OnTrack or some data recovery specialist like it.

The scenario I described is independent of hardware.

Contrary to my previous post, it also does not appear to be a kernel problem. Close examination of the code in the check_partition() function shows that there are indeed sanity counters that prevent that loop from running forever.

CentOS 6 has no problem at all with that disk. You do end up with a lot of ghost partitions, but you can access the disk just fine.

When that disk is connected to a CentOS 7 system, the CPU does loop for a long time, with several instances of the OOM (Out Of Memory) killer dumping udevd processes, but it does eventually recover and allow access to the disk.

SystemRescueCD 4.8.0 actually will eventually boot with that disk connected. It just takes 15 to 20 minutes to do so. If you boot without that disk and connect it later, the system takes only a few minutes to recover (faster if you don't have the GUI environment running).

It seems to be a problem with systemd-udevd in newer systems. Systems without systemd don't seem to suffer.