I did not know that the size of the image file would be the same, sorry.
However. The file system in the image file has become smaller. The last 7 GB are present, but unused by now - df will tell.

$ sudo mount -o loop HP.shrinkme.img /mnt
$ df

The error at restore using dd should not matter here. If you really want to be sure and write it again:

$ sudo ntfsclone -f -o /dev/sdb1 HP.shrinkme.img

The file system should be in a mountable condition. Probably it isn't ... .

Did you try to mount /dev/sdb1 ?
If you want back the shrinked 7GB HDD space, you still need to:

$ sudo ntfsresize -x /dev/sdb1

HDD situation:
There is the "master boot record" (mbr) and "partition start sector 2048" from the new installation, and the file system from the old installation (different mbr and "partition start sector 63") to fit the image size to the HDD space. I'm not aware of all implicit issues.
The disk itself will likely not boot. grub form the other disk may or may not be able to help ($ sudo update-grub).

Does the first version of the win7-install-cd the start-at-sector-63 partitioning? Think so, but not 100% sure. Probably, if you have such a install-cd, it may recreate the partition as before.
I'm not used to read chkdsk output.

Or just use the new installation and copy back all the files form the mounted image.

@guuml.dev1: Thanks for the reply (yes, long ago). There are "ä,ö,ü,ß". [AltGr] is onyl working, if xrdp uses an appropriate keymap too.

Update - a cleaner way to set a default keymap for xrdp:
Initially loaded is /etc/xrdp/km-00000000.ini. The file is not existing, so a link or copy can be made without interfering the installation. The issue occurred again on a new PC.
In my case:

$ sudo cp -a /etc/xrdp/km-00000407.ini /etc/xrdp/km-00000000.ini

After logging in, it is still a "us" or "en" keymap, but switching to "de" now fully works.

$ setxkbmap de

Thanks for posting the file size.

Testing:
Just dd'ed a small 100M partition using bs=13M to have a "fractional block count". Sizes of image-file and device are equal. Also tried dd with "bs=15M" and "bs=512", and pure cat. All image files are identical. On daedalus and on chimaera. No errors at all during creation and restore.

The main question is now:
Why is the image-file (104864062464 bytes) bigger than the partiton (104862842880 bytes)? How is this possible?

The partititon must have been shrinked after creating the backup image.
I don't see any other possibility.

EDIT:
fdisk -lbefore the reinstalltion of windows would be informative.
Older (windows-)partition schema start at sector 63 (not sector 2048) and there is a gap of 398 sectors (or 0.2 MB) between sda1 and sda2. This is 1.2 MB potential addional space for sda1. The image file is 1.1 MB bigger than sda1.

Did you use the appropriate "virtualbox-guest-additions-iso"?
It contains some graphic drivers for the guest-OS (and other stuff). Not sure whether this will cure "crappy graphics".

Then ... What is the business model behind that campagne?

You got me completely wrong! I'll try again.

The main point is: Would you pay for having more search options?

API access means you can use (in this case) the google seach engine directly in your own program or web side. This allows more search parameters and costs real money. No idea how much they are asking for, nor how much I would want to pay for that. Yandex, Bing and others are offering the same services. This has nothing to with profiling or using their web side directly.

On youtube, they doubled the amount of ads, along with the offer to have it ad-free for 10 bugs a month. Same technique may apply for the search.

Beeing naked in front of google and hoping they will deliver better results then is not an option for me. Google has become as evil as its compeditors. At least they delverd some useful and working software (the revolutionary search in the early 2000, maps, earth, and more I forgot).

Advanced search is canceled everywhere. It's a shame.

The architecture of an Knoppix-stick (or iso) is quite interesting in that regard. 
The root file system is on a compressed ISO image - 4.5GB for the DVD-image - read only file system is the point.
If thee is space on the USB-stick, it is possible to have a home directory for files and optionally the overlay-fs can be stored (default is in the RAM until reboot). So can have security updates or even install additional programs.

So: You could combine a read-only-root-fs without encryption with an encrypted overlay-fs for system updates.

(Overlay: Ralph posted yesterday about an overlay file system here https://dev1galaxy.org/viewtopic.php?pid=41386#p41386  Awesome! I was totally unaware of that and am still flashed).

Interesting, you archived what I wanted at the time, but could not get.

Sorry, I did not ment to spread confuision.

EDIT:
Tested on Chimaera, it depends on 'recommended install'.

# apt install wine --no-install-recommends

does not install wine32, while

# apt install wine --install-recommends
# apt install wine64 --install-recommends

does, if i386 architecture is added.

As far as I remember

# dpkg --add-architecture i386
# apt install wine 

installed both, wine64 and wine32.
Indeet, it was impossible to get only wine64 without wine32 (trying to get away without i386-architecture).

EDIT: caution! My memory seems to trick me!
EDIT2: the above is true with apt's defaults or namely # apt install wine --install-recommends

Did you try to copy the URL form the network-portal-login-page visible in Chimaera's Firefox and re-use it in Daedalus?

Thanks for the input, guys.

Probably it's not as bad as I thought in the first place. De-deprecation seems somewhat likely and gnu-which was included.
Still don't like it when "they" mess around with the basic tool set.

Best solution (EDIT:), but bad public relation.