As @Tom-Elliott stated, this is not an issue with FOG itself, instead FOG relies on tools like ntfs-3g and partclone to handle all the NTFS filesystem changes. Hopefully this updated version fixes your issue.
I will update the thread once the experimental release is available.

stll no luck “Could not adjust the bad sector list” continues to cause me issues, anyone have any ideas?

So it may be a config issue on your end or it could be a more specific use case due to a windows upstream change.
Can you give a little more information on the hardware you’re capturing from and what your settings are on the image definition in fog?
I can try to recreate to some extent.

This can occur even when the drive is physically healthy. A filesystem marked dirty will prevent offline resize operations. In that case, FOG is behaving as designed — failing here is preferable to deploying a potentially corrupt image to multiple systems.

We are seeing this more frequently after recent Windows updates, which appear to be leaving or reasserting the NTFS dirty bit.

Please boot the source machine into Windows and run a full filesystem and encryption check. Make sure to adjust the drive letter if your system volume is not C:.

chkdsk /x /r /f C:
manage-bde -off C:

Also ensure hibernation is disabled, as it can leave NTFS in a state that prevents offline resizing:

powercfg -h off

If capture succeeds when resizing is disabled, that further confirms this is a Windows filesystem state issue rather than a FOG defect.

FOG cannot safely work around filesystem states imposed by other vendors. Ignoring NTFS safety checks would risk data integrity, and that is not something FOG should or will do.

I would get a windows computer updated to the latest build and try to capture with FOG, if it works I am mistaken and I apologies for the inconvenience.

There are multiple workarounds mentioned in this thread, and at least one other user has already pointed out that this behavior correlates with recent Microsoft updates. That strongly suggests a change in how Windows is laying out or flagging the filesystem — not a regression in FOG itself.

FOG does not implement NTFS.
FOG does not write partclone.
FOG orchestrates existing, well-established tooling to capture and deploy disk images.

When Microsoft changes disk metadata behavior in a way that causes ntfsclone/partclone to behave differently, that does not automatically make it a “FOG bug.” At best, it’s an upstream compatibility issue; at worst, it’s Windows leaving the filesystem in a state that violates assumptions those tools rely on.

For something to be classified as a FOG bug, it needs to meet at least one of the following:

• A regression introduced by a FOG code change
• Incorrect parameters being passed to the underlying tooling
• A failure in FOG’s logic that independently causes the issue

None of that has been demonstrated here.

If someone can provide

• A reproducible case across systems
• Debug runs showing FOG invoking tooling incorrectly
• Evidence that FOG’s behavior changed independent of OS updates.

then I’m happy to investigate it as a FOG issue.

But attributing “FOG needs to fix this” to what appears to be an upstream file-system behavior change isn’t accurate, and it doesn’t help move the problem toward an actual solution.

To be clear: I don’t mind helping fix problems - even upstream or compatibility issues - if there’s a clear, reproducible failure that can be attributed to something FOG controls.

What I do mind is hand-waving the problem away with “FOG needs to fix this” without showing:

• how to reliably reproduce it
• what changed that caused it
• or where FOG itself is behaving incorrectly.

Saying it works if I use an older image or it started after recent Windows updates is useful diagnostic information - but it points away from FOG being the root cause, not toward it.

If someone can demonstrate that:

• FOG is passing incorrect parameters
• FOG logic regressed
• or FOG can reasonably detect and mitigate a specific file-system condition.

then I’m happy to look at code or tooling changes.

Until then, attributing this to “FOG needing to fix something” is a conclusion without evidence.

I am able to capture the image if I turn off compression using Multiple Partition single disk (Not Resizable)