The NTFS3 kernel prevents NTFS volumes from mounting if it detects the so-called dirty bit (a flag that is triggerred when possible damage is found). When that happens, an associated error message is typically displayed BAD SUPERBLOCK etc.
Let me be clear: NTFS3 does not cause the damage (corruption) that the error indicates - it simply tells you that it exists. This is something NTFS-3G does not do - it’s incapable - so, if damage exists, it does not tell you (no error), and the user continues using the volume while oblivious to there being any damage.
So, when using NTFS-3G, the reason for so many uninformed comments such as ‘It doesn’t happen with ntfs-3g’ is simply that it doesn’t tell the user that a problem exists.
When using NTFS3, all that people will understand is that there is an error, and ‘ntfs3 won’t let me mount my ntfs volume’ or ‘ntfs3 has corrupted my ntfs volume’, in the majority of cases, falls back to a lack of understanding that these errors are actually a good thing.
You might find this interesting:
The only way to safely recover data on an NTFS volume, is with Windows based tools, in a Windows environment. Period.
In this instance, you can likely blame yourself. As stated earlier:
In fact, it’s not recommended at all. There will be little to support that claim, but remember, software isn’t generally written with a multiboot scenario, or using foreign filesystems in mind. The Windows qBit version is obviously better suited (by design) for use with NTFS, but as also previously mentioned, even the Microsoft driver is fallable.
The underlying takeaway is - don’t use NTFS filesystems in Linux - unless you absolutely must; and, only if you’re prepared to maintain it properly - from observation, this rarely happens until a user becomes inconvenienced.
Neither NTFS3 or NTFS-3G should even come into the equation. A native Linux filesystem such as EXT4 should be the natural choice for any Linux system. 
Cheers.