Chkdsk artifact after restore

User discussion and information resource forum for Image products.
Post Reply
kenhagin
Posts: 2
Joined: Tue Mar 28, 2023 7:08 pm

Chkdsk artifact after restore

Post by kenhagin »

I restored my Windows 10 boot drive (2 partitions) from a "just made" full backup using VSS. After rebooting, and running chkdsk, I find unusual remarks in the chkdsk output. This does not cleanup with subsequent reruns of chkdsk. I can restore these partitions from Windows Home Server v1 backups without any such issue. Trying to get squared away so I can abandon WHS...

System Reserved partition:
The allocated length 0xc000 is not in multiple of 0x10000 for attribute
of type 0x80 and instance tag 0x833.
Drive C:
The allocated length 0x1e9000 is not in multiple of 0x10000 for attribute
of type 0x80 and instance tag 0x0.
TeraByte Support
Posts: 3598
Joined: Thu May 05, 2011 10:37 pm

Re: Chkdsk artifact after restore

Post by TeraByte Support »

The artifact is a result of excluding $UsnJrnl data which requires advancing it to the next record. However, doing this causes Windows NTFS/$UsnJrnl init/startup to modify the metadata in a way that creates the issue chkdsk is reporting in the event viewer when manually running chkdsk. The issue is harmless and chkdsk will fix it up silently (other than the event log notice).

Version 3.58 was changed to address this by rebuilding and moving the $UsnJrnl all the way to the next aligned allocation record. However, that version introduce a regression by a last minute change that could cause an underflow of the total allocated of the $UsnJrnl causing chkdsk to trigger with a bunch of noise.

Version 3.59 fixed that regression, but users having $Logfile transactions to redo/undo can, on mount, have chkdsk trigger because of the $Logfile recovery process which undoes part of the changes. 3.60 will address that issue.

Note that none of the issues above are critical or anything to worry about. It only affects the $UsnJrnl when that data was excluded. NTFS mounting/redo/undo modifies $UsnJrnl causing the issue that chkdsk is simply fixing it up so it's ready to use.
OldNavyGuy
Posts: 79
Joined: Mon Apr 17, 2023 4:08 am

Re: Chkdsk artifact after restore

Post by OldNavyGuy »

Try adding /skuj:0 to your command line, or SkipUsnJrnl=0 to the ifw.ini file in the BACKUP_DEFAULTS section.

See page 188 in the IFW User's Manual.

We use PHYLock.

Examples -

Windows Scheduled Task

start "" "C:\Program Files (x86)\TeraByte Drive Image Backup and Restore Suite\imagew64.exe" /wait /b /uy /um /d:w0 /f:"F:\My Backup Folder\Backup-w0-$~YYYY$-$~MM$-$~DD$-$~HHMM$" /skuj:0 /vb

ifw.ini file

[BACKUP_DEFAULTS]
PostValidate=0x2
SkipUsnJrnl=0

So far, it has stopped chkdsk from being triggered on two Windows 10 22H2 test systems using 3.59

A manual chkdsk, run after booting into Windows, shows no errors.
VanBuran
Posts: 20
Joined: Mon Aug 15, 2011 8:58 am

Re: Chkdsk artifact after restore

Post by VanBuran »

Thanks OldNavyGuy,this worked "SkipUsnJrnl=0 to the ifw.ini file in the BACKUP_DEFAULTS section"
Post Reply