Thanks for those suggestions. The thing I find puzzling about sampling down to 360ppi to solve the problem is that QTR has a native resolution of 720. So when I send it the 360ppi file QTR will resample back to 720ppi before starting the printing process. (Roy has stated this in the past and I can dig out his reference if anyone is interested. Thus anyone who says "just give QTR whatever PPI you have and it will use it" is not strictly correct. Yes it will print, but only after resampling.)
The resolution to this paradox is that on Windows it's the QTR back-end that does this resampling. I assume it's the QTRGui front end that is complaining that it can't process the TIFF to display a thumbnail to display in the GUI interface. If you could get past that then it would print.
In the cool light of morning I tried my images on my laptop running 2.7.6 and lo and behold it worked! It still worked after an update to 2.7.8. I think Dave is right about fragmentation. But which drive - the OS drive or the images drive? Both are filling up, and while there's still plenty of space, I suspect that the code in QTRGui wants contiguous space.