Jump to content

WinNTSetup v5.3.4


JFX

Recommended Posts

Thanks for that reply, AlexCeed. I don't want to go offtopic too much here, but I did want to ask JFX if he maybe had any "final" tips on why there seems to be a lag/ freeze in Windows Update these days. As you have read in JFX's response, he confirms this problem, but doesn't have the "ultimate" solution.

I think maybe you misundestood my question a bit (or I wasn't clear in explaining), but the problem is not that Windows 7 is slowing down with some updates, but *searching* for updates can take hours and hours these days. It has to be MS server related.

You also recommend 3rd party solutions like wsusoffline. Thanks, I am aware of these alternatives (also: WHDownloader, Simplix). They are indeed a great alternative. But again: I hope that some day we can find out about the mysterious lag/ freeze/ delay in "Searching for updates", that's the main point.

So once more: let's not get too much off-topic, but please reply again if you hear about a solution (or at least: explanation) of this weird problem. It almost looks like MS is trying to "kill" Windows 7!!

Link to comment
Share on other sites


I think maybe you misundestood my question a bit (or I wasn't clear in explaining), but the problem is not that Windows 7 is slowing down with some updates, but *searching* for updates can take hours and hours these days. It has to be MS server related.

 

No, it is not server related. It all comes down to Windows 10, the updates they release need to perform lots of checking before they are downloaded and installed. Which is why you need 8GB of ram when you update the OS from SP1 because otherwise it'll run out of memory and issue errors. These add stress to the system and an increase in time.

 

Thanks, I am aware of these alternatives (also: WHDownloader, Simplix). They are indeed a great alternative. But again: I hope that some day we can find out about the mysterious lag/ freeze/ delay in "Searching for updates", that's the main point.

 

The alternatives you mentioned are just like microsoft they do no filtering of any kind, VHDDownloader gets all updates from microsoft while Simplix uses the updates from VHD and package them into an installer. No difference.

Link to comment
Share on other sites

No, it is not server related. It all comes down to Windows 10, the updates they release need to perform lots of checking before they are downloaded and installed. Which is why you need 8GB of ram when you update the OS from SP1 because otherwise it'll run out of memory and issue errors. These add stress to the system and an increase in time.

 

OK AlexCeed, I see you know what you're takling about, so I'm going to believe you :-)

But how can you explain then, that when I install a 100% original Windows 7sp1 on a test system (like I do every few months) to create a "base" wim with all updates (sysprepped only once. Using WU, not the "other" solutions. This way all updates, including "pending" ones, can get included), that this *also* has major delays in the first "search for updates" run?

That sentence was too long, but what I'm trying to say: 100% clean and normal install, search also stalls.

If there a certain updates to block, how on earth can I block those on that very first run?

Also: the delays seem "random", sometimes it's fast, sometimes it takes a day.

 

About WHDownload: this does *not* download all the Win10-related updates, and the Abbodi1406 install script I use also makes sure these are *not* installed. Simplix pack also skips the (or "some") Win10-related updates in its latest version (after a lot of requests).

 

If you have any specific solutions for me to test, I'd love to try them! Thanks for your input.

Edited by Atari800XL
Link to comment
Share on other sites

WU saves it's information in database: \Windows\SoftwareDistribution\DataStore\DataStore.edb.

Sysprep will delete the complete \Windows\SoftwareDistribution folder,

so the next time that huge database needs to regenerated again.

 

This huge database can on a low RAM PC (< 4GB) cause a lot slow pagefile usage.

Edited by JFX
Link to comment
Share on other sites

Thanks JFX, I didn't know about the DataStore.edb file. Always good to learn new stuff.

 

This still leaves the issue that searching for updates has become a big problem over the last few months, it wasn't a problem for me until about July of this year ("Windows 10 introduction time"?). This is also what a lot of other people complain on the net in numerous threads. For example, a lot of people don't like their w7->w10 upgrade, so they're going back to w7sp1 clean, then face the "stall" issue.

I still believe it's a server issue, like I said: it looks Microsoft has set w7 update servers to "low priority" and w10 servers to "high". I do seem to recall reading something about that (MS buying new server space this summer), but I can't find that info anymore!

(This would also explain the "sometimes it works, sometimes it doesn't" issue. Now if I can only find out which hours per day/ days per week are the best?).

Edited by Atari800XL
Link to comment
Share on other sites

A similar problem also appeared in WinXP. I doubt that it could be server issue.

I would say WU simply isn't designed for so many updates.

Edited by JFX
Link to comment
Share on other sites

Thanks, JFX.

There is still the issue of "sometimes yes, sometimes no". Last week (for example wednesday) I ran a test (just because I have enough spare systems here). No go...

Then in the weekend (all the same hardware, exactly the same setups, a=clean sp1 base, b=ntlite integrated updates based, c=abbodi1406 integrated updates based, d=simplix updates base), *ALL* worked again.

See, that's what's driving me nuts. I never seem to have a test that has repeatable results. It's just a matter of luck... Now if only one of the test systems had that result, I would use it as a solution, but it's the same with all of them, it seems.

Thanks for all your input. JFX, feel free to cut this subject off at any time...

 

EDIT: I'm now seriously thinking of doing this test:

- Do a clean w7sp1 setup (using WinNTSetup, of course [see, not off-topic after all!])

- Make system image (acronis or similar)

- Restore this image every day at the same time, then test how long "search for updates" takes until it displays its results. So *don't* do the actual update process, just see how long the search takes (and if the results vary).

Wouldn't this "prove" the server theory? Or would it be a useless test?

Edited by Atari800XL
Link to comment
Share on other sites

A similar problem also appeared in WinXP. I doubt that it could be server issue.

 Funny you should mention XP. Still updated with POS updates, guys like OnePiece are still doing a great job updating their packs and tools. And of course WinNTSetup does a superb job installing everything. All the way back from XP to the latest Windows 10 preview build 11082 (just finished [clean-]installing now). Just wanted to be the first to confirm build 11082 compatibility!! (Here we go again...)

:thumbup

Link to comment
Share on other sites

A similar problem also appeared in WinXP. I doubt that it could be server issue.

I would say WU simply isn't designed for so many updates.

I can live with WU taking longer searching for updates as long as it does this in a reasonable way. What I can't live with, is the amount of CPU it uses to carry out the task. On a dual core T2300, it uses 50-51% CPU during the whole process which is unacceptable. If the system is fully up-to-date, WU is much quicker and If you are missing any updates, it is slow. Vista has the same problem. Win8.1 is better, but they all suffer the high CPU usage.

Edited by click-click
Link to comment
Share on other sites

If the system is fully up-to-date, WU is much quicker and If you are missing any updates, it is slow.

 

This is not what I am seeing. A few weeks ago, I did tests on original SP1u installs. I only added kb3102810 (first) then (because I was told it was the "magic cure"). Indeed, all 150+ updates were found in less than 7 minutes (tested around 15 times, search only, not the actual install of the updates).

I did an update/ sysprep/ capture run on one of those to an updated wim, fresh installed again with that, then did a search again. This resulted in totally unreliable (and stalled/ frozen) results. I gave up on testing then.

 

Now I'm back to testing that updated wim again (doing clean installs with it and search for updates again).

Until now, I've repeated this test 4 times, all were around the 31/32 minute mark (10 updates [december] found in all cases). Very interesting, but again this proves nothing and seem to be very strange test results. When we follow your reasoning, the first search for 150 updates should take more time, and the second search for 10 updates should take less. Also, why are all the searches taking 31 minutes now, when they were stalling a few weeks ago?

 

So once again, it leaves the question unanswered about what the hell is going on here... Some kind of server throttling by MS seems the only explanation for now, but to be honest I'm getting more and more confused.

Edited by Atari800XL
Link to comment
Share on other sites

Hi commiethebeastie,

Thanks for the report. WinNTSetup requires the XML information from a wimfile.
A wimlib captured wim is missing most of them, so the wim file is not accepted.
I added a workaround in version 3.8.5.5, please try again.

 

JFX, it looks like the new Wimlib beta version can add more info to the XML.

If you decide to check out the new version, could you (or commiethebeastie, or anyone else) please give some examples of how we can add more info to the wim, that WinNTSetup can use? (Which entries are needed?)

The latest Wimlib beta can also capture from a live system (VSS)! So I guess it can act like a disk imaging tool in this case, but I wonder if the speed is any good in that case?

Edited by Atari800XL
Link to comment
Share on other sites

  • 3 weeks later...

First of all, congratulations for this nice tool :D

 

I'm creating UEFI partitions with diskpart then format C: drive and then i use this tool to restore the WIM to C:.

After rebooting, the Windows doesn't start given boot error :(

If i create the same partitions, but next install with normal setup and then there format C:, after reboot it start Windows.

Does anyone know what can be? i know that GPT partitions doesn't have boot flag, so i don't know what is happening :(

Thank you

Link to comment
Share on other sites

i know that GPT partitions doesn't have boot flag, so i don't know what is happening :(

Well, it is not that GPT partitions don't have a boot flag, it is the whole mechanism of UEFI booting that works differently.

If you are booting in UEFI a GPT style disk, on it there must be a FAT (FAT32 usually but FAT12/16 will normally do as well) partition containing the Windows EFI boot files.

The UEFI loads a file from a FAT partition, a few motherboards UEFI implementation do include a UEFI NTFS driver but it is rare.

Unless you are willing to modify your UEFI, this is not negotiable, there are workarounds, but usually they are not worth it, and in any case a small FAT partition is needed.

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Thanks for replying,

i have that partition, it's called System.

Do i need to copy the files to that partition?

If so, can you tell me what are the files?

Thanks

 

This is my batch to create the partition:

 

select disk 0
clean
convert gpt
rem == 1. System partition ================================
create partition efi size=100
format quick fs=fat32 label="System"
assign letter="S"
rem == 2. Microsoft Reserved (MSR) partition ==============
create partition msr size=16
rem == 3. Create Windows partition ========================
create partition primary size=100000 
format quick fs=ntfs label="Windows"
assign letter="C"
rem == 4. Create Restore Partition ========================
create partition primary size=20000 
format quick fs=fat32
rem == 5. Create Backup partition ========================= 
create partition primary
format quick fs=ntfs label="Backup"
assign letter="W"
list volume
exit
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...