Hello,
I hope someone can help me understand what is happening here, because I have been troubleshooting this for quite some time and I am honestly exhausted.
I am working with Windows offline images (WIM) and recently started using WimWizard for more advanced offline Windows servicing.
I have discovered a very strange reproducible problem:
WimWizard by itself works perfectly.
However, when I process the image with wimlib first and then process the same image with WimWizard, the resulting Windows installation consistently ends in a BSOD.
The basic difference is:
Original WIM
↓
WimWizard
↓
Windows boots normally
versus:
Original WIM
↓
wimlib processing
↓
WimWizard
↓
Windows BSOD
The problem happens regardless of what I subsequently change in WimWizard.
I am therefore trying to determine whether wimlib is changing some filesystem metadata or Windows-specific information in a way that is incompatible with what WimWizard expects.
I am particularly wondering about differences involving:
NTFS metadata
ACLs/security descriptors
reparse points/junctions
symbolic links
hardlinks
alternate data streams
file attributes
timestamps
extended attributes
anything else that could affect an offline Windows installation or servicing
I understand that wimlib is primarily a WIM imaging/manipulation library and that WimWizard operates much more deeply on Windows servicing components. I am not claiming that wimlib is necessarily "corrupting" the image — I would simply like to understand whether there is a known difference between a filesystem tree produced by wimlib and one produced by Microsoft's deployment tools.
I will be doing controlled tests as well, including comparing the result of a Microsoft/DISM operation against the equivalent wimlib operation.
I can provide the exact wimlib commands, options, Windows version/build, WIM information, WimWizard procedure, and the exact BSOD stop code.
Could someone familiar with wimlib please advise what areas I should investigate first?
In particular, are there wimlib options or behaviors involving ACL restoration, reparse-point handling, hardlinks, or other Windows metadata that could produce a Windows installation which behaves differently from one deployed using Microsoft's tools?
Thank you very much for any help. I am not trying to blame wimlib — I really like the tool and would just like to understand what is happening and find the correct way to use it with this workflow.
The important difference
The two tools are doing very different jobs.
wimlib is fundamentally a WIM/archive engine. It knows how to capture, extract, modify and apply WIM images and, on Windows, it does preserve a lot of Windows-specific NTFS metadata.
WimWizard, on the other hand, is operating at the Windows servicing layer. Its documentation specifically says its WIZARD ENGINE works with CBS components, dependencies, drivers, registry structures, AppX packages and servicing remnants.
That distinction is extremely important.
My first suspicion: the image is already subtly different after wimlib
I would not initially assume that "wimlib corrupts the WIM."
Rather, I suspect the sequence is producing an image whose filesystem/metadata state is slightly different from what WimWizard expects, and WimWizard subsequently performs a deeper servicing operation that exposes the inconsistency.
There are several areas I would investigate.
1. Reparse points / junctions
wimlib explicitly handles Windows reparse points, including symbolic links, junctions and other reparse types. It also has logic for fixing absolute reparse-point targets during application.
This is potentially very important for Windows.
A Windows installation contains a lot of junctions/reparse points. If your first tool is doing something like:
WIM
↓
wimlib apply
↓
NTFS directory
↓
WimWizard servicing
↓
capture WIM
↓
boot Windows
then I would want to know exactly how the wimlib apply is being performed.
In particular:
--rpfix
--norpfix
can change how absolute symbolic-link/reparse targets are handled.
2. Security descriptors
This is another big one.
wimlib attempts to restore Windows security descriptors from the WIM, including ACL-related information. Its documentation even warns that Windows installations contain files whose security descriptors are unusual enough that they can cause access problems if restored incorrectly or incompletely.
It has different behavior depending on whether it can restore the complete descriptor:
normal
↓
try complete security descriptor
↓
if unsuccessful
↓
fallback / partial descriptor
and there is also:
--strict-acls
--no-acls
with substantially different semantics.
This is something I would absolutely test, because WimWizard subsequently works directly with the Windows servicing ecosystem.
3. Hardlinks
wimlib also restores hardlinks.
Windows uses hardlinks in places that are relevant to the servicing architecture, particularly around component-store files.
So I would want to compare:
Microsoft WIM apply
VS
wimlib apply
for the resulting filesystem.
Not just file contents.
Specifically:
hardlinks
reparse points
security descriptors
alternate data streams
file attributes
timestamps
8.3 names
object IDs
extended attributes
wimlib actually documents support for essentially all of these on Windows.
That means the interesting question isn't simply "does wimlib preserve metadata?"
It does.
The interesting question is:
Does wimlib reproduce the exact filesystem state that Windows' own servicing/deployment stack expects before WimWizard starts manipulating CBS?
That's a much more interesting question.
And there is an even bigger clue
WimWizard explicitly says:
it operates exclusively inside mounted WIM paths
and has its own servicing engine rather than being a collection of DISM scripts.
It also specifically works with things such as:
CBS components
drivers
registry hives
AppX
servicing remnants
WinSxS
packages
dependencies
and can perform extremely deep component removal.
So if WimWizard by itself works, its assumptions about the initial Windows image are apparently satisfied.
If:
original WIM
↓
WimWizard
↓
works
but:
original WIM
↓
wimlib
↓
WimWizard
↓
BSOD
then I would concentrate on what wimlib changes before WimWizard ever sees the image.
Best regards
Just in case here are the clues:
https://wimwizard.blogspot.com/p/wimwizard.html
and youtube https://www.youtube.com/@byEduardG