@wonko: Thank you for those ideas. They allowed me to take a step back. I had focused on formatting. I had left out the capture.
So I redid a "capture" with the /NoRpFix parameter. But no evolution.
It is also true that it is not easy to understand the context of my test. I had 2 possibilities.
a - explain everything from the beginning, the purpose, the method, the tools, the implementation
b - simply extract a sticking point in my progress
So I'm going to do a little bit of the 2.
1 - the overall goal: to use SandBox in a Winpe (22000-194 FR)
identify the elements needed for Winpe
inject these elements into Winpe
Fix the current issue "RDP link broken by Sandbox VM" : my actual work
identify an error-free context!
many tests including FullFlat
various means of investigation used (simultaneous or not)
procmon: the analysis of traces makes it possible to locate the source of the anomaly, mainly thanks to the symbols.
This gives me a good view of the logic, processes, and steps taken to build and operate the Sandbox VM. And I can now imagine tests to identify a solution, including this one:
copying entire directories from another source: avoids unit search
the choice of the directory: define a selection criterion
various methods of copying depending on the presence or absence of ACL, the desirable time
This is the starting point of my final question
2 - the context of implementation of the next test
the reference VHDX disk in which Sandbox works without anomaly (Winpe FullFlat)
a physical machine with a GPT hard drive
this GPT hard drive can start the test VHDX
the BCD of the hard drive of the physical machine is modified to start the test OS
the test VHDX is obtained by making a copy of the reference VHDX file: it is therefore identical to "dd"!
the test VHDX is also GPT type (but this does not impact the test)
the test VHDX therefore has 2 partitions, I designate here by "C:" the partition containing the test OS launched at startup
note: the first partition is FAT and it contains a BCD used to boot into HyperV (or another hypervisor)
3 - one of the blockages during my research: the copy of the entire partition at once
After attempting various copies, I want to copy the entire partition containing the OS of the reference VHDX disk
I tried 2 methods: copying with windows file explorer (but ACL), and copying with "dism capture / dism apply"
I could have tried "7z.exe" but I didn't.
In the case of the use of "dism", I followed this modus operandi:
boot to another "winpe"
mount the reference VHDX
capture OS partition
mount the test VHDX
format "C:" partition of OS -> new signature for partition !!!
apply the captured file in this blank partition
disassemble the 2 VHDX
reboot on the test VHDX
Sanbox works <- with the new signature !!!
reboot on the test VHDX
Sandbox does not work (RDP link is broken by sandbox VM)
I then did the test to apply the capture file without formatting the test VHDX: Sandbox does not work from the first reboot
4 - a point about the Sandbox
I forgot an important thing about capturing the reference partition and the Sandbox itself.
In this reference VHDX, I installed the Sandbox FOD with "DISM /ADD-FEATURE" in "offline" mode.
Then I started the VHDX to check that the FOD was present in "optionalFeature.exe".
Then I restarted another Winpe to capture the reference partition.
So, the next launch of "WindowsSandox.exe" will start on a blank environment.
And it will build all the necessary context for Sandbox.
And this will be true in the reference VHDX as in the test VHDX.
These 2 VHDX do not contain any reference to an already active Sandbox image.
5 - hence my question: what does the formatting that allows the first operation of Sandbox do?
note : I could try to describe the Sandbox anomaly more precisely but I don't know if it can be useful to you.
note : it is a Winpe context, so change in hives are not present on the next boot
note : it is a VHDX context, so change in files are present on the next boot
Thank you for taking the time to read and try to understand my question