Reproducible “Unload registry failed” during Windows 7 x86 update integration — NTLite.exe holds COMPONENTS hive itself

A

amidevous

New Member
Messages
1
Reaction score
0
This report was automatically generated by ChatGPT at my request.



Title: Reproducible "Unload registry failed" during Windows 7 x86 update integration

NTLite version: 2026.09.11904
Host OS: Windows 7
Target image: Windows 7 SP1 x86
Image type: WIM

Hello,

I am experiencing a reproducible registry hive unload problem with NTLite.

The problem occurs during the final processing/reconstruction stage after integrating a specific set of Windows 7 updates.

NTLite displays:

The registry unload failed.

Make sure that registry hives are not open by another program, then try again.
Click to expand...

The important point is that the hive is not being held by another external application.

I investigated the problem using Sysinternals Handle.

NTLite had loaded the following registry hive:

Code: 
HKLM\NLTmp~35809916~COMPONENTS

I checked the open handles with:

Code: 
handle.exe -a "NLTmp~35809916~COMPONENTS"

The result was:

Code: 
NTLite.exe         pid: 2120   type: Key   B9C: HKLM\NLTMP~35809916~COMPONENTS

So NTLite.exe itself was holding an open handle to the COMPONENTS registry hive.

Trying to unload the hive normally:

Code: 
reg unload "HKLM\NLTmp~35809916~COMPONENTS"

returned:

Code: 
ERROR: Access is denied.

I then closed the specific handle:

Code: 
handle.exe -c B9C -p 2120 -y

After that, the handle was no longer present.

I then executed:

Code: 
reg unload "HKLM\NLTmp~35809916~COMPONENTS"

and the unload succeeded:

Code: 
The operation completed successfully.

I clicked Retry in NTLite, and NTLite was able to continue.

The problem is reproducible.

I completely closed NTLite and purged the NTLite temporary folders under %TEMP%.

I then restarted from the Windows image before the updates were applied.

I asked NTLite to integrate the same set of updates again.

The exact same registry hive unload problem occurred again, at exactly the same point in the operation.

Therefore this does not appear to be simply a stale temporary mount left behind by a previous failed operation.

The sequence was:

  • Close NTLite completely.
  • Purge the NTLite temporary folders under %TEMP%.
  • Restore/use the original image before update integration.
  • Start NTLite again.
  • Integrate the same update set.
  • Reach the same processing stage.
  • Get the same "Unload registry failed" error.
  • Check the registry handle.
  • NTLite.exe is holding the COMPONENTS hive itself.

Additional information

At the time, DISM reported these active WIM mounts:

Code: 
C:\Users\admin\AppData\Local\Temp\NLTmpMnt
    -> starterx86.wim
    -> Index 1
    -> Read/Write
    -> State: OK

C:\Users\admin\AppData\Local\Temp\NLTmpMnt (1)
    -> boot.wim
    -> Index 1
    -> Read/Write
    -> State: OK

The affected registry hive was a genuine Windows servicing COMPONENTS hive.

Querying it showed entries including:

Code: 
StoreFormatVersion
StoreArchitecture
ExecutionState
PendingXmlIdentifier
CanonicalData
ccpinterface
Configuration
DerivedData
Installers
ServicingStackVersions

The most important observation is:

NTLite reports that the registry hive cannot be unloaded, while Sysinternals Handle shows that the handle preventing the unload belongs to NTLite.exe itself.
Click to expand...

Manually closing that handle allows the hive to be unloaded successfully, after which NTLite's Retry operation continues normally.

Since the problem reproduces after:

  • completely closing NTLite,
  • purging %TEMP%,
  • starting from the pre-integration image,
  • and integrating the same updates again,

the problem appears to be reliably reproducible and related to the handling/lifecycle of the registry hive during this particular update integration sequence.

Could you please investigate why NTLite.exe still owns the COMPONENTS hive handle when NTLite attempts to unload it?

Additional reproduction details

The following CAB updates were actually applied by NTLite during this second reproduction:

Code: 
IE11-Windows6.1-KB4534251-x86.cab
Windows6.1-KB2952664-v25-x86.cab
Windows6.1-KB3000483-x86.cab
Windows6.1-KB3021917-x86.cab
Windows6.1-KB3068708-x86.cab
Windows6.1-KB3075220-x86.cab
Windows6.1-KB3080149-x86.cab
Windows6.1-KB3150513-x86.cab
Windows6.1-KB3184143-x86.cab
Windows6.1-KB4019990-x86.cab
Windows6.1-KB4040980-x86.cab
Windows6.1-KB4474419-v3-x86.cab
Windows6.1-KB4490628-x86.cab
Windows6.1-KB4524752-x86.cab
Windows6.1-KB4532945-x86.cab
Windows6.1-KB4534310-x86.cab
Windows6.1-KB4536952-x86.cab
Windows6.1-KB4539602-x86.cab
windowsupdateagent-7.6-x86_7.6.7600.320.exe

NTLite also generated an ntlite.log during this reproduction.
The log is available and can be provided for investigation if required.

Thank you.
 

Attachments

You must log in or register to reply here.
Back
Top