SOLVED - NTLite v 2.3.9.9020 crashing while updating Win7

P

pmikep

Active Member
Update: Like so many of my posts in this forum, it was the 'nut behind the wheel.' It was a problem caused by leaving Comodo HIPS enabled. Scroll to bottom to read the details.

I start with a mostly vanilla Win7+SP1 iso that has only my AMD RAID driver integrated into it. (And the OEM disk drivers removed.)

Then I try to update the image with 55 Windows updates.

NTLite has crashed during the process twice now. (Unfortunately, I get impatient and walk away from my computer and so I see only the result - the Windows sign-on screen.) It seems to crash at about 30 to 40% of installing the extracted updates.

I have trimmed the Updates folder to remove obsolete updates. I just now erased the temp folders and will try a third time.

Because it crashes before NTLite is finished I have no easy log files to upload.

I didn't see anyone else mentioning crashes recently in this forum. I'm using a Win10 box, which has been robust. So I don't think that the problem is hardware (overheating or bad RAM).

What data can I supply to help troubleshoot this?

(It's 3 am here and I really need to go to sleep now. Perhaps tomorrow I will try this on my AMD 8-core Win8.1 machine to see if it crashes doing the same updates.)
 
Last edited:
Okay, I tried it one more time on the Win10 box. (I moved all the temp directories for NT Lite to SSD's.)

It's a BSOD. I didn't see a stop code.

It crashes during the integration of KB2841134, a large IE11 update.

Time now is 3:15 a.m. Gotta sleep.
 
Last edited:
WOW! NTLite just BSOD'd on my AMD Win8.1 box!

Same place in the process as on my Dell Win10 box. (I used the same wim, the same updates, and the same preset on my AMD as on my Dell.)

The BSOD error message is: BAD_POOL_HEADER.

I cannot believe that this could be a hardware problem on two different computers. (Although later I will sneak away my friend's Acer laptop to see if it crashes during processing.) This crash appears to be following NTLite.

Attached is the Preset. The wim is Win7 US 64-bit with SP1 built in.
 

Attachments

  • Win7 had RAID now 55 updates and Remove FLK - didn't complete.xml
    21.7 KB
I was reading through your steps and one thing that stood out to me was that it doesn't look like you've yet to try using NTLite on a W7 image, to create your modified W7 image. If so, maybe try that? I only mention it because there have been other similar reports about dism issues when trying to do something like create a W10 image while using W8. I realize this example may not directly translate here since you're going the opposite direction, but it's worth trying just to eliminate potential suspects at least.

Make sure any antivirus software is disabled, and maybe even try to disable your network adapter temporarily while running NTLite and processing things, to help eliminate background activity that may be interfering. Also run LatencyMon and see if you have driver issues, because that error you posted could be a sign of that.
 
For a sanity check, I'd run a W10 image on W10 host, and W8 on W8 to determine if only your W7 preset crashes a machine.
 
Okay, some semi-good news on this New Year's Eve: I was able to process my Win7 wim on my friend's Acer Win10 laptop.

Now, before you tell me that this proves that my problem is hardware related (on two different machines?), my gut feeling is that there is a race-condition in the newer versions of NTLite.

I say this because:

1) This link from Microsoft suggests that BAD_POOL_HEADER can be a software problem. (It talks about stepping through internal pool links with a kernel debugger. (They used the word "walk."))

2) I modified this same Win7 wim last year (in January 2022) on both my Dell Win10 and my AMD Win8.1 machines using earlier versions of NTLite and I didn't have this problem. But I do a year later. (I haven't done any wim work since last year.)

3) The Acer laptop that worked has only one 'hard' drive. (NVMe.) Whereas my Dell has one NVMe and one SSD. And I set NTLite's various working directories on the different drives on the Dell for faster 'hard drive' access. The Acer took noticeably longer to process the wim.

Similarly, my AMD has one regular spinner and one RAID. It's RAID 1 + 0, so almost as fast as SSD for sequential read or writes. I'm guessing that it could cause a race condition/collision too.

4) Although my Win8.1 machine is overclocked a bit, the Dell Win10 is not. (Dell's 'BIOS' doesn't allow overclocking.) So my Dell is very vanilla.

And I run programs on my Dell that exercise it to the max. (The CPU at near 100% for minutes at a time with the two GPU's at about 80%.) So if it were power supply sag or over heat problem causing my problem with NTLite, I would be seeing it on those programs too. But I don't.

5) I don't think it can be bad RAM on both of my machines because NTLite crashes at the same point on those two machines. If the problem were, say, a stuck bit in RAM, the crashes would be somewhat random and independent of each other. But they're not.

And so I hypothesize that the reason that this version of NTLite completed on my friend's Acer is because, with only one drive, there couldn't be any race conditions on the Acer.

I suppose, if I were getting paid to do this, I could test my hypothesis a couple of ways: 1) I could put all of NTLite's working directories on one drive on my Dell to bottleneck I/O. 2) Similarly, I could do this test in a VM, which, by its nature, is going to have slower I/O than the host OS.

But I have other things to do. The only reason that I'm trying to remake a 'Lite'd Win7 is because Dragon Dictate stopped working on my Win7 box and I'm experimenting in a VM with 'Lite'd versions of Win7 to see if my Removals broke Dragon. (Now that I write this, I recall posting something in the forum (maybe now in the old archive forum?) about Dragon needing some arcane component.)

And so, as is said, I leave this exercise to the reader.
 
Last edited:
BAD_POOL_HEADER is a kernel-level memory allocation problem. NTLite works in userland, the only privileged operation it needs is to call TrustedInstaller (through DISM). If you have a BSOD, I'd recommend using WinDbg (Store app) to look at the crash dump.

It's fairly straightforward, click on the crash file and WinDbg will take a fairly good whack at guessing the general reason.
 
FWIW, the version of NTLite that worked for me successfully was v 1.8.0.7095.

I have learned to keep copies of previous versions of NTLite. I have one from September of this year and will try that to see if I have a problem with it.
 
Hey garlin, thanks. This is one reason why you're a Moderator and I'm not.

Well, as you might guess from my previous posts (if not from being an NTLite User in the first place), I did not let Win10 create an M$ account for me. So I don't have access to the Store. (At least not directly. I wonder if I can use my friend's Acer to download WinDbg and xfer the file to my desktop?)
 
v1.8.0.7095 is dated Aug 13, 2019. That's not really a "recent version".

On your friend's PC, download the PowerShell GUI for downloading Microsoft Store Apps.
- Run the PS script, pick "x64" & "Retail" and enter App ProductID "9PGJGD53TN86"
- Warning: it's a hefty debugger package (be patient).
- Copy the files to USB. Bring it back to your PC, and if you haven't removed DesktopAppInstaller -- click on the WinDbg package in Explorer to sideload.
 
As for the "recent" version - yeah, I know. But it was the last one that worked for me. As I said, I will try the Sept version and see if that works. (Since that's easy for me.)

Well, I have removed DesktopAppinstaller. So I'll have to do the trick that others talk about - selecting WinDbg from the SDK.

But I need a few nights of sleep (maybe weeks) before I try this big step.
 
Add-AppxPackage -Path "D:\Microsoft.WinDbg_1.2210.3001.0_neutral_~_8wekyb3d8bbwe.msixbundle"
 
I was just about to report that NTLite v 2.3.8.8920 didn't crash on the same Win7 wim as above. And in fact, it made to about 95% of completion.

It wasn't a fair experiment though, with only one variable changing. In addition to trying an earlier version of NTLIte, I also moved the location of the NTLite Extraction Folder, from my mirrored spinning array (very slow) to my SSD, which already had NTLite_Temp on it.

Unfortunately, just as NTLite was about to finish, I received a BSOD. This time the message was "Kernel_Security_Check_Failure."

Hmmm... I didn't have my browser running initially (virtualized by Comodo). Then I ran my browser and a few minutes later NTLite crashed.

I have Comodo on my Win8.1 Box. It's never been a problem before, but now I'm wondering if Comodo is interfering with something?

Well, it's 12:30 am and I really am too old to be staying up late goofing around with computers.

Hopefully nuhi will chime in later with his thoughts on what, if any, optimizations to NTLite could cause this.
 
Like most security products, Comodo uses a kernel filter driver to accomplish snooping. Yeah...
 
SOLVED.

As someone else hinted here, it was a 3rd party problem. (Not antivirus specifically. But security software.)

Once garlin stated that "NTLite works in userland, the only privileged operation it needs is to call TrustedInstaller (through DISM)," that started me thinking. As Sherlock Holmes said, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth."

So if it couldn't be an NTLite problem, what else could it be?

Well, in the past, when I used NTLite on my Win8.1 box, I always had to disable Comodo's HIPS feature. It gave me a lot of pop ups warning about DISM. And they seemed all unique, because I couldn't tell Comodo to accept all the DISM requests.

So I had developed the habit of disabling HIPS whenever I used NTLite.

Now it seems that something changed in the past year, because when I used NTLite now on my Win10 box (with Comodo), I didn't have any HIPS warnings.

But I did see one on my Win8.1 box.

So I'll end a long story and make it short: Once I disabled HIPS on my two boxes, NTLite has been trouble free. (The Acer laptop doesn't have Comodo on it. So that explains why NTLite worked fine on it.) Apparently it was the DISM requests after all.

Now if I can just figure out this Flag 9 thing so that I can do a refresh of Win8.1. (I see that there is a new feature in NTLite now, as I see Flags for the boot.wim on the main page now.)
 
You must log in or register to reply here.
Back
Top