2.5.38 Windows server can’t read back its own VHDX images (mount and assemble both fail)
Wasn’t quite sure if this should be ‘General discussion’ or ‘Restore’ or ‘Server’, so defaulting to the more general topic.
I can’t get any image backup off this server through UrBackup. The web UI mount fails, and assemble_disk_image.bat fails the same way. Fulls and incrementals, all four clients. Windows opens the full backups fine, but not incrementals… And opening in Windows is read-write by default so vulnerable to corrupting the chain.
What’s notable is that Mount-VHD with read-only flag appears to work just fine. So the images themselves look OK and something in the VHDX reader is rejecting them.
Setup
- Server 2.5.38, bare metal Windows 11 Pro
- Clients 2.5.25-cbt and 2.5.31-cbt (Infscape CBT build), Windows 11 Pro, UEFI/GPT
- Storage is a local NTFS volume
- Image format VHDX, uncompressed
- Incremental style “Based on last image backup”, full style “Full image backup #1”
- ImDisk installed,
sc query imdiskshows RUNNING - Service runs as LocalSystem
- Mount button shows up and there’s no “Image mounting disabled” at startup, so
canMountImages()is returning true
Debug-level server log attached.
urbackup-server-debug-excerpt.log (7.6 KB)
urbackup-server-full.log (810.5 KB)
Corroborating screenshots:
assemble fails on a file that mounts fine in Windows
Easiest one to reproduce. Image_E_260902-0437.vhdx is an incremental six links deep, back through five incrementals to a full from 2026-08-27.
assemble_disk_image.bat on it:
2026-09-02 16:59:31: ERROR: Footer checksum wrong. Switching to header
2026-09-02 16:59:31: ERROR: Header and footer checksum wrong
2026-09-02 16:59:31: ERROR: Error opening VHD-File "P:\PC Backups\Mainframe\260827-0418_Image_E\Image_E_260827-0418.vhdx"
Same file, same machine, read-only via the Hyper-V module:
Mount-VHD -Path "P:\PC Backups\Mainframe\260902-0437_Image_E\Image_E_260902-0437.vhdx" -ReadOnly
That works. Volume mounts, I can browse it. Windows walks the whole parent chain and checks every parent identifier on the way, and it won’t attach if any of them are off, so the chain is intact.
The error says “VHD-File” for a .vhdx, and footer/header checksums are a VHD thing rather than VHDX. Might be nothing, might be a hint the file is going to the wrong reader.
Fulls fail too
Web UI mount on a full C: gives “Mounting image failed. Please see server log file for details.” Log has nothing but:
2026-09-02 16:39:06: ERROR: Footer checksum wrong. Switching to header
2026-09-02 16:39:06: ERROR: Header and footer checksum wrong
Tried it on two different clients about ten seconds apart, same output both times. No parent lookup, which makes sense for a full. Both of those files also mount read-only in Windows and browse fine.
Odd parent path in the incremental path
Mounting an incremental through the web UI, the second candidate path it tries is mangled. Full filename with ..\..\..\..\..\..\..\ stuck on the end:
2026-09-02 16:39:23: WARNING: Could not open parent vhdx at "\\?\P:\PC Backups\Megabyte\260827-1729_Image_C\Image_C_260827-1729.vhdx" or "P:\PC Backups\Megabyte\260827-1729_Image_C\Image_C_260827-1729.vhdx..\..\..\..\..\..\..\"
Also, Get-VHD shows the parent locators aren’t written consistently down a chain. Some are P:\..., some are \\?\P:\.... Windows resolves both so it doesn’t break anything, but it stood out.
Other notes
Turning the loglevel up to debug added nothing for any of these. Looks like there’s no debug logging in the VHDX read path at all.
No client log to attach. The client side is running at warn and hasn’t written anything since July, which fits, since backups themselves aren’t failing. They complete, CBT is working, and the numbers in the backup logs look right. It’s only reading the images back that fails.
Can run a patched build or pull whatever else is useful.