Sigh... well, I can answer this question now, user error.
I had played around with VMMap but it wasn't really helping, so I decided I'd try adding some extra checks to the code as a precursor to installing VS on the VM for full debugging. I added an ArgumentException
check for if the passed image was not 32bit ARGB. As it turned out though, the exception was thrown on my development machine which was somewhat unexpected. Evidently one of the images I was using for testing wasn't 32bit ARGB, but yet was happily being locked to 32bit ARGB. Just as evidently the right pixel data was being returned, as I think even I would have noticed a garbled image after manipulating bits!
Seems newer versions of Windows can in fact lock bits to a completely different format - a quick test program which simply opened a PNG then attempted to call Bitmap.LockBits
on all values in the PixelFormat
worked for every single format, bar the weird ones (that aren't prefixed with Format). Well, at the very least it doesn't thrown an exception, and in my case an image that had the format Format8bppIndexed
was locked to Format32bppArgb
and returned the correct pixel data. Whereas XP and Vista can't seem to do that and just throw an exception. Not sure if I prefer the former behaviour or the latter actually, almost leaning towards the latter although obviously the former is more convenient.
I stuck in a ugly hack where if the source image wasn't 32bit ARGB then a new temp image was generated from the source and used that to get the pixels. Now my code works in the VM without any noticeable problems, bar the speed of the method will have taken a hit. So there's one problem solved, now I just need to get rid of that hack.