Interesting - not stumbled across that one yet.
- Does it always fail on that machine (in which case - probably something to do with that hardware setup that either we don't like or that breaks us). Would help if it's at least married to "a particular device model".
- Is there anything interesting in any of the logs? You may want to enable max verbosity as well -- How to enable Xtrace Diagnostic Logging -- to see if that catches anything of use.
... will probably need to go via support eventually, but I'd start with the above. If it's a hardware specific thing, we may need one of those boxes shipped to our devs for them to look at what's going on specifically.
Hope that helps move this on a bit .
I tested this on 3 different machines, Dell and HP work Station and on an ASUS server. Same Result.
Can't find anything on the logs.
Supports is helping me with this.
I do not understand... this is happening on my 9.6 SP2, SP3 and I also tested it with a new 2016.
I created a stand alone USB (before i was doing a PXE boot) SAME Result.
Hi Carlos, did you try to mount your boot.wim? Is it OK?
I saw something weird sometimes and usually we solve rebuilding the boot.wim from scratch (you can follow this doc: How To: Create a Clean WINPE (BOOT.WIM) on the Core Server. )
@amagi, yes i tried doing that, still the same problem.
It boots but ldprovisioning.exe doesn't run.
I tested this by closing the console window and navigate to the ld provisioning folder and try running the ldprovisioning.exe but it fails with the same error.
this error seems to come up if you try to run a 32bit version of an app on a 64bit OS. Maybe something is wrong with your boot64.wim or boot.wim.
I am having the same issue here on a Lenovo E570 - I rebuilt my 64bit boot.wim twice with no luck. Any fix out here....
Tried rebuilding 32 and 64 bit boot.wim's no luck.
I get the following in the background;
"A subdirectory or file \ldprovision already exists.
Unexcpected EOS during body read 3 766545"
Any one find a solution on this one? - Using a Dell XPS 15 9560 - CORESERVER: 10.1.0.168
I had this issue today with a bare metal provisioning task. I found that the issue was the wrong serial number was entered for the identifier in the bare metal object.