Piriform's Defraggler says one thing, Windows Defrag says another?

I would be tempted to believe windows at this point, especially after defragging twice.

Maybe uninstall with revo, then reinstall defraggler and see what it says?

This could simply be a difference in the way the applications determine fragmentation. Certain files cannot be de fragmented for various reasons, (Pagefile is one I think) .

it may be that Windows is actually saying is that of the defragmentable files 0% are fragmented, whilst defraggler is stating that there is fragmentation of 17% of all files

I think that Windows Defrag reports % of files and Defraggler reports % of bytes in fragmented files. One or two large fragmented files can cause this discrepancy.

It's also worth noting that the inbox defrag ignores any files that are larger than 64MB when generating fragmentation statistics, whereas most other defragmenters do not. The Engineering Windows 7 Blog had a post specifically about disk fragmentation in Windows 7, and why defrag might behave differently than people expect:
Disk Defragmentation

In Windows XP, any file that is split into more than one piece is considered fragmented. Not so in Windows Vista if the fragments are large enough – the defragmentation algorithm was changed (from Windows XP) to ignore pieces of a file that are larger than 64MB. As a result, defrag in XP and defrag in Vista will report different amounts of fragmentation on a volume. So, which one is correct? Well, before the question can be answered we must understand why defrag in Vista was changed. In Vista, we analyzed the impact of defragmentation and determined that the most significant performance gains from defrag are when pieces of files are combined into sufficiently large chunks such that the impact of disk-seek latency is not significant relative to the latency associated with sequentially reading the file. This means that there is a point after which combining fragmented pieces of files has no discernible benefit. In fact, there are actually negative consequences of doing so. For example, for defrag to combine fragments that are 64MB or larger requires significant amounts of disk I/O, which is against the principle of minimizing I/O that we discussed earlier (since it decreases total available disk bandwidth for user initiated I/O), and puts more pressure on the system to find large, contiguous blocks of free space. Here is a scenario where a certainly amount of fragmentation of data is just fine – doing nothing to decrease this fragmentation turns out to be the right answer!

As I've said many times, using a 3rd party disk defragmenter might be necessary to quickly clean up a drive that's been left alone for long periods of time, but for ongoing maintenance the inbox defragmenter is very good, and very smart.