JFX

Would call that a lazy question, took just 5 minutes to try and verify that it boots normally.

There is nothing to worry about. WinNTSetup just check if the target partition has the set FILE_ATTRIBUTE_NOT_CONTENT_INDEXED. That is what the last checkbox of drive properties (if unchecked) means. Only in that case, WinNTSetup will inherit FILE_ATTRIBUTE_NOT_CONTENT_INDEXED to all files and folder, that will be applied from the wim/esd file.

The RunAsTI problem will be fixed. Are you sure the second problem isn't caused by this NTLite source? Please post the log file H:\Windows\Logs\WinNTSetup\*\WinNTSetup.log And what happens if you manually run bcdboot.exe? bcdboot H:\Windows /s H: /f BIOS

Good, I will add a fallback for RunAsTI setting. About the crash, is there anything in windows eventlog?

Is a crashdump created or can you post the error information from event log? Newer version will execute "Tools\x64\WIMHost.exe" to apply the WIM file. If no error code is displayed, it could only mean that the program did not even start. Maybe an antivirus program intercept here or WinNTSetup is located on a network share. WinNTSetup tries to run WIMHost.exe with "trusted installer" rights maybe that is the problem. Add a WinNTSetup.ini next to WinNTSetup_x64.exe with following contain, and try again. [WimHost] RunAsTI=0

Hmm, just don't delete the files it comes with. Unless there are critical bugs or needed changes for Windows 12, no further development is planed.

Last version could fallback to xpress compression and also ignoring the compression level. I don't think "merge ide" will cause any problems, but i would not recommend to use it without reason. I is really only thought to apply or copy a not generalized image to different hardware.

WinNTSetup 5.3.3 - fixed wim capture regressions - fixed trusted installer could not access temporary drive letters - automatically switch to wimlib, for non solid ESD (fix wimgapi crash) - wincopy commandline volume mode can use filemode as fallback - vhd drives can be saved and loaded from ini file

With slim taskbar the systray icons are no longer centered. TaskBand2SmallIcons::Taskband2, TASKITEM --> CONTENTMARGINS = 4,4,4,4

MergeIDE tweak can be useful, if you capture a fully installed Windows and apply it on different hardware. With older OS you could often get a 0x7B BSOD caused by different SATA drivers. I don't know if it makes much sense with Win8 and later.

WinNTSetup.ini.txt only show the hidden options. Most of them are uses in initialization and can't be changed later while loading a new ini file. if you want to document the normal GUI options, sure do and I will add it.

WinNTSetup 5.3.2 - native ARM64 code for WIM apply and capture - WIM apply and capture will be executed as "trusted installer" - WIM capture UI adds compression level, defaults to wimlib's LZX Fast - wimlib wimboot apply - changed overlay type to WIM_BOOT_OS_WIM - wimlib capture WIM - deletes incomplete WIM after operation cancel - wimlib smooth progress bar for appending operation - using customized wimlib.dll (do not update!) - automatically switch to wimlib, if wimgapi can not load WIM file - fixed cancel setup was ignored during DISM operations - fixed WinCopy Volume mode problems - fixed some issues with ARM64 sources - added advanced VHD creation options - respect NTFS indexing option on target partition - no longer downloads ADK files on Win10/11 Host

A warning, yes that should be added. But more options will not be added. It's just a simple action like get used clusters and copy them. Adding exclusions would require complete MFT parsing, what I don't have the time to implement.

Mount the VHD and than create backups like you do on every other normal disk system. Either a disk imaging software like Acronis TI, Macrium Reflect or a file backing image like a WIM backup.

Yes, it working for me, using it from time to time. But the grow rate is quite high. Just booted a diff and shutdown after 3 minutes it grow to 1.42 GB. You could simplify this without editing BCD. Just rename the VHD to let's say Base.vhd and create a diff with the old name. Also make sure that parent and diff vhd are in the some folder.

Maybe, differencing VHDs are not the best choice for you Have not seen that 0xC0000000f error. Could be a problem coming from Bootice edit.

No, but {default} is the correct one. "bcdedit -v -store Q:\Boot\BCD" would show the correct GUID, but you can use symbols like {default} or {current}, too.

"bcdedit -store Q:\Boot\BCD" should print something like this:

Yes, that would require to do all steps manually. Update BCD with bcdedit.exe: Get the %GUID% form bcdedit -store S:\EFI\Microsoft\Boot\BCD than update device and osdevice: bcdedit -store S:\EFI\Microsoft\Boot\BCD -set %GUID% device vhd=[C:]\diff.vhd bcdedit -store S:\EFI\Microsoft\Boot\BCD -set %GUID% osdevice vhd=[C:]\diff.vhd

No, you have to do this manually.

You create a diff.vhd and use this for everything (mounting or booting via BCD). If you make any changes to the base.vhd the diff will be invalid.

Hi dimo70, if the selected boot partition is GPT, WinNTSetup automatically switch to UEFI only for bcdboot.exe. unless BCD option is set by ini or command line. This was requested years ago and actually makes sense. But if you use legacy boot with a GPT hybrid MBR, this causes promlems. Makes sure you set BCD option to "ALL".

Yes, simple use a filename with .vhdx extension and it will create a VHDX file.

Just guessing will not help much. WinNTSetup already uses these 2 commands. bcdboot.exe W:\Windows /s S: /f ALL bootsect.exe /nt60 S: /mbr Were W: is the Windows installation drive and S: is the selected boot partition. Only difference I see is the missing /force switch on bootsect command. But this is done on purpose, also diskpart does write bootable MBR and PBR. If you encounter the problem again try 1 of these command from a WinPE, to find out witch one makes a bootable again.

That sounds like a problem with the MBR of the boot disk. By default WinNTSetup uses bootsect to update the boot sectors. bootsect.exe /nt60 S: /mbr The first 2 green lights are only using simple checks, there is no way to tell if the code is actually bootable. To limit the problem, it depends on what repair you do with bootice.