Definitely partition order (or more exactly drive letter assignment to volumes) depends on the OS booted (on DOS/Windows), this is perfectly normal and is not at all connected with the issue at hand.
In a nutshell every time a Windows NT system is booted checks Disk Signature and the volume offset against the HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices Registry key and (if the Disk Signature+Volume offset is not found) it assigns a new one (according to a set of rules) that normally remains "sticky" until tjere are changes in the disks or volume connected.
For the C: driveletter (that is the first driveletter assigned) and for all the other ones on a disk that is the only disk connected at the time of installing/booting this setting is very "static" a it is the boot (and in your case of the second disk also the system volume (and though it can be changed it is not ever automatically changed).
So the behaviour you describe is normal and perfectly reasonable/repeateable, etc. since it is unrelated it isn't worth the (lengthy) detailed explanation of how it works.
The dd for windows is pretty much unuseful (as it relies in the same understructure of Tiny Hexer, HDHacker, etc. i.e. the Window HAL and disk driver).
If you want to try the dd in grub4dos you need first to create an empty (filled with 00's) file, 512 bytes in size OR find a sector that is surely already all 00's to use as source.
Good candidates (sectors that are already all 00's) are sectors LBA 1-62 of the same disk.
I.e. boot to grub4dos, press "c" to get to command line. then:
1) make sure that you know which disk it is, i.e. run
2) let's say that the disk is (hd1), you should be able to recognize it by the number and size/type of partition,
3) make SURE that the chosen source sector is actually 00's, i.e.
cat --hex (hd1)1+1
cat --hex (hd1)2+1
etc. and confirm visually that it is all 00's
4) let's say that (hd1)1+1 is all 00's, now you have to dd it to sectors 75 and 146785914, i.e.
dd if=(hd1)1+1 of=(hd1)75+1 bs=512 count=1
dd if=(hd1)1+1 of=(hd1)146785914+1 bs=512 count=1
Will it work?
Most probably not.
The error is on the disk and you cannot avoid it.
Now, "bad" sectors may be either "bad" or "weak", while actually "bad" sectors are normally NOT recoverable, "weak" ones can in some cases be restored by overwriting them several times or "exercising" them (there are tools capable of this).
But this is not a case of a "normally bad" sector (and not that of a "weak" one) since even the WDC tool cannot fix/exclude it (by re-mapping it in the internal G-list).
Though there may be (or there are) tools/methods capable of manually modify the G-list they are complex, error prone, and definitely outside the use of a non-professional (it is simply not worth it in this case).
The only sensible thing to do in this case would be to image the disk, restore the image to a brand new disk and throw the disk away.
BUT since you seem like having nothing to loose, there i still the possibility of slightly resizing shrinking the two volumes as to move the "bad" sectors away from the $Boot area.
BUT, BUT, due also to the "queer" positioning of other filesystem mandatory files on those two filesystems this is easier said than done, particularly it would be (relatively) easier for the first volume and (relatively) harder for the second one (because the $MFTmirr is in the way).
If you are game for this, I would gladly try and assist you.