The "queer" thing is that the only parts that grub4dos should actually check/look into are the MBR partition table (and not the MBR CODE) and the PBR BPB (Bios Parameter Block) (and NOT the PBR CODE).
The partition table in the MBR MUST be "unencrypted", as otherwise the BIOS would never be able to initiate the booting, I believe.
Checking it's contents it's easy from grub4dos:
cat --hex --skip=446 (hd0)
The BPB of a "bitlockered" volume should also be "clean", in the sense that it should remain the same as that of the same volume NON-bitlockered with the only exception of course of the volume ID which is "renewed" when formatting, in your case the volume "D:" is however seemingly not even "bitlockered", as only volume "C:" is (and at least limited to the "cluster size", your "plain" result of "8" confirms this)
The fact that both the ls and the blocklist command fail sounds more an issue of some kind with the $MFT (which should not at all be an issue, in the sense that in theory there is no reason why a "non-bitlockered" volume should have it's $MFT changed
But all in all your latest results seem like to exclude a connection with bitlocker, so only some "queer" values in the $MFT (that need to be additionally "transparent" to native Windows tools/OS BUT affect the grub4dos NTFS driver/interpreter) must be the culprit.
The needed tests to be performed in order to understand the cause of the issue may be long and troublesome (you will need to image/clone/re-format/bitlocker/un-bitlocker a "test machine"/"test device"), if you are game for it, it would be very interesting but - don't want to put you down in any way
, mind you - it will need some serious commitment on your side (as you are the one that will have to do most of the work). AGAIN
, which EXACT
version of grub4dos are you using?
this piece of info to exclude preliminarily the possibility that you are using a buggy, obsolete or more generally "inappropriate" version.