After a lot of random googling, it looks like this behavior is actually "by design"

Timers using System.Threading.Timer will terminate upon an exception, no matter what you do with it, see here

There appear to be a couple of other options I can try although they use System.Timers.Timer and I'm not sure that's in NETMF and not in a position to look right now

Can you give me a quick example of that by chance? I've done threads before so thats fine, just the blocking and manualreset that I've never heard of before. Also, thanks heaps for all the help!

I think what I'll do is just kill the 30 second timer and call the UploadData routine directly from my main loop, which has been completely empty until now with a Thread.Sleep(Timeout.Infinite) so I'll throw a while loop there with a Thread.Sleep(30000) and just call UploadData from there.

That should hopefully sort out the timer being killed issue and I should be able to catch the damn errors

I'm exceedingly doubtful you could do this with a netduino at any sort of decent speed.

Initially you need to get another USB port from somewhere at minimum, but likely 2 as they need to be host ports. Either these would have dedicated controllers of their own, which you interface with over SPI or I2C or something, or you'd need to bit-bash them, the second likely isn't possible at all due to timing issues, the first would severely limit your speed.

Secondly you don't have the sort of memory available for to do any sort of decent read caching. Assuming you can pull that off, you then need to be able to decode the partition table and file system, read the data from it and and write the data to the new file system at ~30MB/sec whicih is all you can get from USB2 anyway. I don't know of any way you could push that sort of speed through a netduino alas. 

You dismiss the software as easy, but being able to read and write to NTFS partitions and file systems is no small feat for something on this scale.

For something like that you'd probably want to look at something like an FPGA board, but even that would be pretty painful as while you'd get the hardware side done fairly easily at decent speed, you still need the whole filesystem and partition layer to be able to write to the second drive.

When playing with these sensors I notice they take quite a while to stabilize after any changes. It may be as simple as moving between 3.3v and 5v VCC and they need some time to settle.

I've written a basic driver for this here

It's basically a direct port of the supplied driver for the arduino

I use 2012, although it should work in any version really (I'm surprised 2013 wouldn't open the sln honestly).

Youneed to make sure you have the NETMF Toolbox assembles installed and include Toolbox.NETMF.Core and Toolbox.NETMF.Hardware.Core as references

Typically when I see that behavior on an LCD my first impression is I'm sending it data too fast. In saying that, most of my experience with LCD's has been either with serial LCD's or SPI/I2C ones as I hate having to dedicate heaps of pins to drive a screen

What _do_ you get when you right click in the edit box? Websites can replace the right click menu, but working around that is pretty simple with add-ons, but before you go down that road you'd want to confirm that's whats going on