Was it fdisk which showed errors? Although fdisk now has some partial awareness of UEFI, a UEFI layout will more or less be an “error” (even though it isn’t really an error, it is just the wrong tool to examine partitions with on UEFI).
Windows will not assign any letter to a filesystem type which it does not understand, and thus there is no letter assigned to any ext4 partition (though I suppose Windows subsystem for Linux could see this, but still this would not likely be assignable as a drive letter). Any time Windows cannot assign a drive letter for Linux content, this is “a good thing”. Any time Windows can assign a drive letter for Linux content, this is “a bad thing” (and likely the filesystem will fail to correctly work with permissions).
Here is an experiment to work with, but it requires not accessing the SD card in any way which might modify it. Trying to mount the card will probably invalidate this. I’m not sure where to get this on Windows, but if you can find a way to view the checksum of a file (it doesn’t matter which kind, e.g., crc32, sha1, sha256, it doesn’t matter…though one type will be faster than another) find the checksum of the binary image used by dd. Then, when the image is copied, copy it back to the host as another file name, and see if the checksum matches. If this were on Linux, and if the SD card as a whole were “/dev/mmcblk0”, and if the checksum is sha1sum, then it would go something like this:
cd /where/ever/the/original/image/is
sha1sum ./my_image.bin
dd if=./my_image.bin of=/dev/mmcblk0 bs=512
dd if=/dev/mmcblk0 of=/copied_back.bin bs=512
sha1sum ./copied_back.bin
# Be sure to erase unused files after this since it is a lot of space.
If the original checksum matches the copied back checksum, then the dd copy operation and the function of the SD card (in combination) are perfect. Any attempt to mount the SD card (including automount, not just manual mount) will possibly alter the image (e.g., through attempts to repair a filesystem or to update mount times in journals), so you have to guarantee no modification prior to viewing the copy back image.
Also note that an SD card as a whole (e.g., “/dev/mmcblk0”) is not usually mountable. Only individual partitions are normally mountable (e.g., “/dev/mmcblk0p”), and even individual partitions cannot be mounted unless they are formatted with a filesystem type the host operating system understands.
I don’t use the Windows subsystem, nor the Windows equivalent to dd, not sure what win32DiskImager is. I can tell you though that if the SD card (or other storage device) is functional I’ve never had dd ever fail to correctly copy an image under Linux (and I’ve used Linux since kernel 1.0.9). Do you have a native Linux host to work with?