CBT doesn't work after KB5074109 and KB5067467 installed

[Zek]

CBT is not working anymore after 2026-01 Security Update (KB5074109) (26100.7623) and Phi Silica AI Component Update (KB5067467) installed on Win11 24H2 few days ago. Has anyone else encountered a similar problem?
Logs saying failed to read file in indexer because incorrect parameter, while vss snapshot created successfully.

Code: Select all

[18.01.2026 00:08:08] <01> Warning  Failed to generate volume (C:) CTK: Failed to calculate digests for volume \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy10
[18.01.2026 00:08:08] <01> Warning  Cannot read file in indexer::CFileWriteCollectorReadCache::_ReadBlock. Pos=0x000001d163150000 Length=0x00010000.
[18.01.2026 00:08:08] <01> Warning  Win32 error:The parameter is incorrect.
[18.01.2026 00:08:08] <01> Warning   Code: 87
[18.01.2026 00:08:08] <01> Error    Failed to create digest files
[18.01.2026 00:08:08] <01> Error    Failed to calculate digests for volume \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy10
[18.01.2026 00:08:08] <01> Error    Cannot read file in indexer::CFileWriteCollectorReadCache::_ReadBlock. Pos=0x000001d163150000 Length=0x00010000.
[18.01.2026 00:08:08] <01> Error    Win32 error:The parameter is incorrect.
[18.01.2026 00:08:08] <01> Error     Code: 87 (System.ArgumentException)
[18.01.2026 00:08:08] <01> Error       at VeeamEndpointSysUtilsDllLib.IVeeamEpSysUtils.MakeVolumeDigests(String wSnapshotName, String wNewMftDigestsFileName, Boolean vbDeviceHasSeekPenalty)
[18.01.2026 00:08:08] <01> Error       at Veeam.EndPoint.CEpMftCtpCreator.TryCreateCtpForVolume(String diskUniqueId, CLiveVolumeInfo volume, CGuestDiskInfo disk, String shadowVolumePath, EVolumeBackupMode volumeBackupMode)

Support case 07955136

[Dima P.]

Hello Zek,

Thank you for your post, this issue is unexpected. Please keep working with support team.

[Zek]

Yes, of course. However, I’d like to see feedback from other users to determine whether this issue also affects others on the same version of Windows, or if it’s an isolated case caused by a specific environment.
The issue may go unnoticed by most users, as it does not trigger any warnings or errors in the interface, but it can cause a noticeable performance degradation during backup operations on large disks.

[Dima P.]

Hello Zek,

To be honest, you’ve encountered a very rare issue.

1. The C: volume size isn’t aligned with the filesystem cluster size (4 KB). Because of this, the filesystem size is 2.5 KB smaller than the volume size, as it’s impossible to create a full FS cluster in those remaining 2.5 KB. This situation is practically unique — doing this intentionally requires significant effort, so we suspect some software created this misaligned layout.

2. There is very little free space left on the volume (1,838,699 MB used out of 1,906,225 MB at the time of the last backup).

3. During a Windows update, new files were created. It appears the system ran out of available MFT space, so Windows extended the MFT at the very end of the volume and wrote information about those new files there.

4. VAW performs MFT tracking by reading the entire $MFT file and computing hashes for each MFT record.

5. The MFT is read in 64 KB chunks from the filesystem. If a full 64 KB block is not available at the end, VAW reads whatever remains.

6. What happens here is that VAW tries to read beyond the actual end of the filesystem — because the filesystem ends before the volume does — and ends up attempting to read those extra 2.5 KB where no filesystem data exists.


As a workaround, you can shrink the affected volume by 1 MB and then extend it back by 1 MB. This should correct the layout alignment issue, although it may cause additional data to be re-read during the next backup due to the layout changes. Thank you!