Installation of ISO with install.esd images constantly crashes 0xC0000005: ACCESS_VIOLATION in \sources\ImageLib.dll

The called out exception is for the chunking process. Chunking is where you partition a large file into logical data segments, so you don't need to read the entire ESD file before beginning the extraction. It's like how you divide up MPEG files into small sets of starting key frames.

Since the WIM version installs fine, it's obvious the problem doesn't exist in the image's content.

More likely wimlib's compression is not 100% compatible with whatever Setup's DLL is expecting. I was hoping you would try using 23H2's boot.wim to install the 24H2 ESD, to determine if the DLL version that Setup uses makes a difference or not.
 
Ahh, sorry I thought I already answered that one previously...

I tried 23H1, 23H2, 22H2 , but It makes no difference at all, if it fails with 24h2, then the failure always happens at the exaclty same percentage no matter which boot.wim you use...

And accordingly, if there is a working ESD, it again does not matter what boot.wim you use, all of them will work...

There is one thing that came to the light right now. I just tried again the bad-ESD and boot WinPE and I can see that it stopped (5%) evidently at copying the two animated cursors, that I added to the image.... I can see that the directory \windows\cursors contain all cursors except for the two that I added to the image... Maybe coincidence.... But what I do now, it that I will edit the bad-ESD and delete the two animated cursors and try to install again...
 
Last edited:
So, deleting of the two animated cursor files had no effect on the instalaltion ESD and ISO. Still the same failure error.
 
I downloaded your ISO and installed it without troubles in Hyper-V. So i unpacked your ISO, converted ESD to WIM and took a look inside. First of all there are a lot of files you inserted directly into the image instead using $OEM$ method. Maybe conversion from WIM to ESD has problems with these files - maybe give $OEM$ a try to avoid your problems.
 
With great hope I tried inserting the files using $OEM$ method, but no change. You write "a lot of files".
g-force said:
I downloaded your ISO and installed it without troubles in Hyper-V. So i unpacked your ISO, converted ESD to WIM and took a look inside. First of all there are a lot of files you inserted directly into the image instead using $OEM$ method. Maybe conversion from WIM to ESD has problems with these files - maybe give $OEM$ a try to avoid your problems.
Click to expand...
With great hope I tried inserting the files using $OEM$ method, but no change. Still failure.
You write "a lot of files". I am not ware of any other files than those in windows\setup\files and windows\migration directories (<20). All the other files were just installed normally prior to sysprep. (Clink and Office by it's installer , Dynamic Theme by DISM provisionad to all usersa , etc...) I do not see how I could add these installation via $OEM$ method. I also found out, that all "manually added files" actually are present on the corupted installation, as if the manually added files were to be coppied first...
 
ESD was intended for low bandwit download of Windows images.
Why have this intense wish for using ESD for install as .WIM is working.
Little the same when comprimate the HD/ SD and every little file opening has to be extracted in every sense.
 
francis11 said:
ESD was intended for low bandwit download of Windows images.
Why have this intense wish for using ESD for install as .WIM is working.
Little the same when comprimate the HD/ SD and every little file opening has to be extracted in every sense.
Click to expand...
The other purpose for ESD compression was to fit a less than 4 GB image on a FAT32 filesystem.

Today, that's less likely to happen with current W11 image sizes and several workarounds already exist for the 4GB limitation (split WIM's, modern UEFI support for NTFS, Ventoy extended partitions).
 
You can think about whether it is still smart to burn DVDs for installing Windows.
I think most people install from USB and have experienced that it is not possible to buy a USB smaller than 16 GB from an IT store.
But I could be wrong depending on where you are in the world and what equipment you use.
 
I never had problems with a WIM that was converted to ESD. When WIM was working, the ESD was working too. The conversion does not change any file at all, it`s just like another compression. I changed and added files in Windows, syspreped and captured, made some changes with NTlite and exported as ESD. I never had an issue with ESD. There must be some failure in one of the steps creating this ISO.
Some members here mentioned that it`s no need to use ESD and stay with WIM. They are not wrong - but it doesn`t explain the failure.
 
ESD's are crypted - when NTL is'nt updated to match this - it fail.
Also there's some components needed to be kept like WinRE.
 
WIM files are not encrypted. The Windows release ISO's that are provided in encrypted ESD files are only intended for volume licensing clients, and not for public release. That's just a form of basic copy protection.

You can't provide an encryption key when DISM capturing WIM's, or changing the compression format. When MCT exports an ISO image, the ESD file isn't encrypted.
 
What i write is decrypting an ESD file - and not talking about .wim saved from NTL.
Luckywise member abbodi86 have hands on decrypting ESD downloads + among very important other IT stuff regarding Windows.
A very respected member here in NTL forum and MDL forum.
Thank you.
 
Can everyone who has a problem ESD, please run wimlib-imagex for me? This is the same library that NTLite uses for compression.
wimlib-imagex.exe info install.esd

Windows Setup has known problems if your ESD's chunk size is > 64MB. Share the full output of "WIM Information".
Your GUID is an auto-generated ID and has no real privacy concerns.
 
Hello, i'm writing here out of desperation because I have an almost exact copy of your problem, only difference is i had already encountered this issue in the past and recompressing usually solved it.

garlin said:
Can everyone who has a problem ESD, please run wimlib-imagex for me? This is the same library that NTLite uses for compression.
wimlib-imagex.exe info install.esd

Windows Setup has known problems if your ESD's chunk size is > 64MB. Share the full output of "WIM Information".
Your GUID is an auto-generated ID and has no real privacy concerns.
Click to expand...
Here is the output from the INFO function:

Code: 
WIM Information:
----------------
Path:           install.esd
GUID:           0xedc7f773460becfd556c387f0da97517
Version:        3584
Image Count:    3
Compression:    LZMS
Chunk Size:     131072 bytes
Part Number:    1/1
Boot Index:     0
Size:           14468132272 bytes
Attributes:     Integrity info, Relative path junction

Available Images:
-----------------
Index:                  1
Name:                   Win-11Pro [Laptops]
Description:            Win11 Pro for Laptops
Directory Count:        33620
File Count:             151766
Total Bytes:            38247374442
Hard Link Bytes:        9873980948
Creation Time:          Tue Mar 18 07:45:12 2025 UTC
Last Modification Time: Tue Mar 18 07:45:13 2025 UTC
Architecture:           x86_64
Product Name:           Microsoft« Windows« Operating System
Edition ID:             Professional
Installation Type:      Client
HAL:                    COMPUTER\Generic
Product Type:           WinNT
Product Suite:          Terminal Server
Languages:              en-US
Default Language:       en-US
System Root:            WINDOWS
Major Version:          10
Minor Version:          0
Build:                  26100
Service Pack Build:     3194
Service Pack Level:     0
WIMBoot compatible:     no

Index:                  2
Name:                   Win-11IoT [Desktops]
Description:            Win11 IoT for Desktops
Directory Count:        37962
File Count:             166186
Total Bytes:            39984423273
Hard Link Bytes:        10968481189
Creation Time:          Tue Mar 18 07:49:06 2025 UTC
Last Modification Time: Tue Mar 18 07:49:06 2025 UTC
Architecture:           x86_64
Product Name:           Microsoft« Windows« Operating System
Edition ID:             IoTEnterpriseS
Installation Type:      Client
HAL:                    COMPUTER\Generic
Product Type:           WinNT
Product Suite:          Terminal Server
Languages:              en-US
Default Language:       en-US
System Root:            WINDOWS
Major Version:          10
Minor Version:          0
Build:                  26100
Service Pack Build:     3194
Service Pack Level:     0
WIMBoot compatible:     no

Index:                  3
Name:                   Win-11IoT [Workstations]
Description:            Win11 IoT for Workstations
Directory Count:        35446
File Count:             151075
Total Bytes:            38540842345
Hard Link Bytes:        9768088803
Creation Time:          Tue Mar 18 07:53:27 2025 UTC
Last Modification Time: Tue Mar 18 07:53:27 2025 UTC
Architecture:           x86_64
Product Name:           Microsoft« Windows« Operating System
Edition ID:             IoTEnterpriseS
Installation Type:      Client
HAL:                    COMPUTER\Generic
Product Type:           WinNT
Product Suite:          Terminal Server
Languages:              en-US
Default Language:       en-US
System Root:            WINDOWS
Major Version:          10
Minor Version:          0
Build:                  26100
Service Pack Build:     3194
Service Pack Level:     0
WIMBoot compatible:     no

I will try exporting using DISM, maybe that will work.
Could i manually specify a chunk size? I thank you all in advance for any help you're willing to provide.
 
I MIGHT have found a solution about my issue specifically with the added bonus of removing an extra 2 gb from my final image.
I have been thinking about the issue being caused by the recovery image (winre.wim) like OP suggested and I realized that my image has three completely different ones, each with their own set of WinPE Drivers.

I extracted one of the winre.wim(s), added the drivers for all three types of machines and then applied it to all three.
I captured all three images with no compression (40gb) and then i used ntlite to convert to esd, result was 13.5GB (from 14.6GB with different WINREs) and has the same issues if not worse than before.

i re-ran the compression with the --solid switch directly from wimlib keeping the defaults
Code: 
wimlib-imagex export install.wim all install.esd --solid

The process was slower but the image file was even smaller at 12.6GB AND this time it works...
I have no idea which of these modifications resulted in the fix but i just wanted to leave this comment so maybe we can troubleshoot further and OP can fix his original problem.

EDIT: the error just moved to another index, I don't understand, 2 out of three always work, one out of three works about one time in 10.
If anyone has any ideas I'd like to try. Thank you.
 
Last edited:
What happens if you use DISM to convert the WIM, instead of wimlib? Does the ESD install for you?
Code: 
Dism /Export-Image /SourceImageFile:install.wim /DestinationImageFile:install.esd /Compress:max /CheckIntegrity
 
Code: 
Dism /Export-Image /SourceImageFile:install.wim /DestinationImageFile:install.esd /Compress:max /CheckIntegrity

Deployment Image Servicing and Management tool
Version: 10.0.26100.1150


Error: 87

A required option is missing from the command-line.
Ensure that /index or /name is specified.

The DISM log file can be found at C:\WINDOWS\Logs\DISM\dism.log

I never tried with dism but this is what i just got
I tried adding /sourceindex:1 before running the command again and it looks like its doing something, it will take ages to do all three but in the meantime if you have any other questions or tips for me i'll stay online until late (I live in GMT+1)
 
garlin said:
What happens if you use DISM to convert the WIM, instead of wimlib? Does the ESD install for you?
Code: 
Dism /Export-Image /SourceImageFile:install.wim /DestinationImageFile:install.esd /Compress:max /CheckIntegrity
Click to expand...
I confirm the issue just moves to another index again, the one that is usually problematic is number 2, the chunk size never changed in all of my tests, would you suggest trying again with different chunk sizes? Am I right to assume a larger chunk size will also benefit the deployment performance and thus, maybe, eliminating the issue?
 
wimlib's dev suggests MS's tolerance is a chunk size of no larger than 64MB.
 
what i understand is that the --solid chunk size is different than the standard chunk size and that information is not included in the transcript from the Info function.
I'm trying with a lower solid chunk size and a larger standard chunk size, i have no other way of solving this other thank trial and error
 
You must log in or register to reply here.
Back
Top