The bootinfo script isn't reporting some important details, maybe because you have installed syslinux MBR's rather than grub ones. If you are getting grub-rescue that may not be an operational problem, but it hinders diagnosing this problem.
In particular, under these circumstances, it would be handy to get grub to tell us the root and prefix settings it is using with the
set command and to learn grub's view of which drive is which by using
ls from the grub-rescue prompt and seeing which hard disk it describes. (Since you are eventually booting Windows, and Windows is on disk 2, that may be a signal that the way you are booting is telling grub that your disk 2 is hd0.) In any case I think there is a mismatch between the prefix and grub's understanding of which drive is which.
I've also had trouble with putting grub on drive b--it's a bit tricky.
I believe that seeing the grub-rescue prompt is a sign that the MBR is loading the next sector of grub, and that sector is loading the grub core.img.
The next, and failing, step would be to load the menu, environment, and modules from the directory described by the prefix setting. If the prefix is wrong, or if what grub thinks is hd0 and hd1 doesn't match grub's assumptions when assigning the prefix I believe you will get the problem you are seeing. With my BIOS whatever disk I boot from becomes my grub hd0. Perhaps upgrading your BIOS affected this one way or the other.
The repair, however, would be to boot your Ubuntu using the live CD, and, while running your Ubuntu system, reinstall grub, installing it to the drive you want to use for booting. Be careful about where grub installs its working directory (usually /boot/grub).
Before booting run the bootinfoscript to print out the prefix and other information in case there is still a mismatch between drive order and the prefix. There can be a device.map file that can either help or cause problems.
Once you get past this point grub now uses UUID's to find partitions, so which drive is which is no longer relevant.