Disappearing GUI Elements in Visual Studio 2005

For some reason after updating to Visual Studio 2005, the Exception Window no longer had the "Break on Unhandled Exception" column (or whatever it's called).

Here is a link explaining how to get it back.

Resizing a RAID1 system partition.

Scenario: I have a Linux server (running Gentoo) with 2x 80 GB drives in a software RAID1 configuration that is used as the system drives to boot the server. I wanted to upgrade the drives and swap in some bigger 160 GB drives I had laying around. So, how to do it?

PS! Command syntax is for example only and is not necessarily correct nor complete.

1. Make sure grub is installed on both drives so the system will still boot if one drive is missing.
2. Fail all partitions from one of the drives: mdadm --manage /dev/md3 --fail /dev/hdc3
3. Remove the drive from the array: mdadm --manage /dev/md3 --remove /dev/hdc3
4. Shutdown server, and replace the drive with a bigger one.
5. After reboot, create the same number of partitions that was on the old drive. Each partition must be at least as big as the one it is replacing.
6. Add the new partitions to the array: mdadm --manage /dev/md3 --add /dev/hdc3
7. Let them fester.. i mean rebuild. You can check the status by: cat /proc/mdstat
8. Once finished rebuilding, repeat step 2-7 for the other drive.
9. I now had an identical array to the one on the old drives, except i have space to resize the filesystem to make use of any extra space on the new partition scheme.
10. First we need to make the array partition make use of all the available storage on the harddrive partitions: mdadm --grow /dev/md3 --size=max
11. Online resizing doesn't work for mounted filesystems, and the system disks can't be unmounted while in use. So, reboot into a rescue CD. I chose gParted.
12. Then re-created the raid array with the second drive missing. mdadm --create /dev/md3 --level=1 --raid-devices=2 /dev/hdc3 missing
13. Ran fsck -n /dev/md3
14. Removed the journaling from my ext3 filesystem (making it into an ext2 fs basically): tune2fs -O ^has_journal /dev/md3
15. Ran e2fsck -f /dev/md3
16. Ran resize2fs /dev/md3 and waited a fair amount of time.
17. Once more ran fsck -n /dev/md3
18. Before re-enabling the journaling: tune2fs -j /dev/md3
19. Just to be sure, i rebooted into gParted once more, and created the array again just as in step 12.
20. I then added the second drive to the array: mdadm --manage /dev/md3 --add /dev/hda3
21. Sat back and watched: watch -n 1 'cat /proc/mdstat' for a long time while the second drive got rebuildt with the new filesystem size.

As a last step, I edited /etc/mdadm.conf on the system disk before I rebooted. Not really sure if it was needed, but didn't hurt.
Before I edited the file it did not contain any settings. I basically just added definitions for the arrays i have on my system disks, and listed the partitions to use for each of them.

Update:
You might wonder why I did not add both drives to the array BEFORE I resized the file system. And yes, you can indeed do this. It would probably even be faster! But: REMEBER TO MAKE A BACKUP! With my approach I had the second drive as a backup in case something went boom on the first drive.