Deployed imaged failed with blue screen (error 0xc0000225 or "NTFS file system")

[Matthieu Jacquart]

@Sebastian-Roth Yes deployed on another machine, same model and another different model.
But this behaviour occurs regardless the machine I use to prepare image (Dell 3020, 3060, 3070, same final result)

[Sebastian Roth]

@Matthieu-Jacquart Are all your PCs set to UEFI or legacy BIOS?

or after AD integration with “NTFS file system” error…

Can you be more specific on what you mean by this? Does it mean first boot is working ok? How do you do AD integration? Manually or via fog-client or different tools? Is this the exact error screen you get? If not, please take a picture an post here!

Personally I have not used sysprep myself and can’t help you with that. I know that @george1421 knows a lot about it. Not sure if he might have an idea.

[george1421]

@Matthieu-Jacquart I’m not sure my input can help here because my workflow is really different than yours.

Every time I rebuild/update our golden image I rebuild it using MDT on a VM. With the MDT build I always remove the recovery partition so the C drive is the last partition on the disk. I never sysprep an image more than once. My golden image doesn’t have access to the internet at any time. From image build to capture with FOG is never more than 15 minutes (15 min == Quality Control check duration).

My production fog server is still running 1.5.7 (I think), so I could create a new 2004 golden image (last one was in May 2020) with all of the windows updates. Capture with FOG and deploy with 1.5.7. Upgrade to 1.5.9, recapture the golden image to another image def and then deploy with 1.5.9 both the 1.5.7 and 1.5.9 images to our dell workstations in the test lab. This would give us an idea if its 2004, 1.5.9, something in your environment that is causing the issue, or something else.

[Matthieu Jacquart]

@Sebastian-Roth
Yes sometimes after fog deployment PC didn’t crash immediately but reboot 3 or 4 times with fog hostname changer and AD integration (made by fog client) and then I’ve got the exact screen you post.
I’ll continue some tests tomorrow with last dev-branch version and just trying to deploy and then upload my master image (without any update or new software)

@george1421 Indeed I didn’t use this method but I think it will be good idea to use a VM with snapshot to update my master…

[Matthieu Jacquart]

So I continue tests and update fog to last dev-branch (1.5.9-29), which gave me same results that last stable 1.5.9 :

• if I upload image without sysprep, everything is ok, I can deploy this image.
• if I sysprep image without capturing it with fog, behouviour is normal and I can sysprep image 2 or 3 times without any bug.
• BUT if I sysprep image AND capture it, this time windows can’t boot, and Gparted give this :

Windows partition C seems not recognised and empty, so of course it can’t boot ! But why this behaviour occurs only after sysprep + fog capture ?
Thank you for your lights !
Matthieu

[Matthieu Jacquart]

another strange behaviour, this one worked fine 10 minutes and supports few reboot, but then failed with “NTFS file system” error.
Gparted return this :

If I boot with win 10 installation USB key, I’ve got a message disk is GPT…

[Sebastian Roth]

@Matthieu-Jacquart Thanks for the update. I still can’t make sense of it.

Just to make sure I may ask you again - try using non-resizeable image type to see if this spikes the exact same issues.

another strange behaviour, this one worked fine 10 minutes and supports few reboot

What exactly do you mean by this. Sounds like you tried just rebooting the system several times and that worked fine but at some point it fails, right?

Where does gparted and with that ntfsresize (as seen in the picture) come into the game? As far as I see you haven’t told us about manually resizing before.

[Matthieu Jacquart]

@Sebastian-Roth Ok I think yo can close this topic, it was a bug in my image due to Windows partitions… When I upgraded Win 10 from 1909 to 2004 this summer, I found a 600MB recovery partition at the end of the disk, after C partition, while there was already a 500MB recovery partition at the beginning of the disk.
So I deleted this final partition and as everything seemed to work fine I left like that. Except that now, for a reason I can’t explain, sysprep + fog capture crash my image.
Likely I found one Pc which has not been erased this summer so I was able to update and capture it, now I’m saved !

Here is the partitioning of my image, it seems strange to me with the first 500MB partition with 10MB used and 0 unsused (where are the missing 480 MB ?), and another recovery partition at the end. It’s working like a charm for now but I think I will have to start a fresh install soon…

Thanks,
Matthieu

[Sebastian Roth]

@Matthieu-Jacquart Well that’s really interesting. It is known that Windows 2004 adds another revovery partition to the end of the disk. I have this on my list of things to work on for the next weeks.

Though I cannot imagine how removing this partition can cause such issues you described here. It’s really over the top for a Windows installation to boot fine for a couple of times and then fail with such errors if it is for the missing recovery partition I would think. But well, I am a Linux guy and only scratch my head unable to understand the way MS is making up its world.

[Sebastian Roth]

@Matthieu-Jacquart Do you still see this happening?

[Matthieu Jacquart]

@sebastian-roth Hi, I didn’t made other tests since end of October but I was able to deploy image to 80 PC at this moment so for me it’s ok