Jump to content

Slowness in the sysprep process with Windows 7 32 bit

clivebuckwheat
 Share

Recommended Posts


cluberti

cluberti

Posted
Posted

Hrm - this file isn't timestamped at all, which I guess is potentially expected. It is odd that it keeps going back and installing/removing the video driver for an Intel G41 chipset though, over and over, without logging ANY of the UMDF CBS logging that would generally be logged in between.

This is a mystery.

Link to comment
Share on other sites
clivebuckwheat

clivebuckwheat

Posted
  • Author
Posted

Hrm - this file isn't timestamped at all, which I guess is potentially expected. It is odd that it keeps going back and installing/removing the video driver for an Intel G41 chipset though, over and over, without logging ANY of the UMDF CBS logging that would generally be logged in between.

This is a mystery.

That's odd that it's doing that too the video driver, but I have to tell you the resolution is always wrong on my 32 bit image, and always dead on with my 64 bit image, no matter what hardware it is deployed on. So I think toy maybe right about the slowness being the video driver on the 32 bit builds.

But the question is how to fix the **** thing?

Link to comment
Share on other sites
Tripredacus

Tripredacus

Posted
Posted

The missing timestamps is not rare. It always does this, or at least mine is like that too. Here is a process comparison:

Your setupact (last 5 lines)

dispci.dll:  ============BEGIN DisplayClassInstaller============
dispci.dll:  DisplayClassInstaller: Returning 0xe000020e for DIF 0xc
dispci.dll:  ============END DisplayClassInstaller==============
montr_ci.dll:  DIF_DESTROYPRIVATEDATA
montr_ci.dll:  Returning 0xe000020e for function 0xc.

And mine (relative last five + next few)

dispci.dll:  ============BEGIN DisplayClassInstaller============
dispci.dll:  DisplayClassInstaller: Returning 0xe000020e for DIF 0xc
dispci.dll:  ============END DisplayClassInstaller==============
montr_ci.dll:  DIF_DESTROYPRIVATEDATA
montr_ci.dll:  Returning 0xe000020e for function 0xc.
AudMig: No audio endpoint migration settings found 0x2
AudMig: No audio endpoint migration settings found 0x2
2010-02-27 19:59:17, Info                  CBS    Starting TrustedInstaller initialization.

So you can see mine does not stop where yours does, and it does start doing time stamps. But later on, it does go back to logging more display entries without timestamps on them. Let's take a look at some more files...

C:\windows\TSSysprep.log

C:\Windows\Panther\setupact.log

C:\Windows\Panther\UnattendGC\setupact.log

However since there appears to be a LOT of driver activity with the display, I am wondering, did you (clive) inject any drivers to your install?

Link to comment
Share on other sites
clivebuckwheat

clivebuckwheat

Posted
  • Author
Posted

The missing timestamps is not rare. It always does this, or at least mine is like that too. Here is a process comparison:

Your setupact (last 5 lines)

dispci.dll:  ============BEGIN DisplayClassInstaller============
dispci.dll:  DisplayClassInstaller: Returning 0xe000020e for DIF 0xc
dispci.dll:  ============END DisplayClassInstaller==============
montr_ci.dll:  DIF_DESTROYPRIVATEDATA
montr_ci.dll:  Returning 0xe000020e for function 0xc.

And mine (relative last five + next few)

dispci.dll:  ============BEGIN DisplayClassInstaller============
dispci.dll:  DisplayClassInstaller: Returning 0xe000020e for DIF 0xc
dispci.dll:  ============END DisplayClassInstaller==============
montr_ci.dll:  DIF_DESTROYPRIVATEDATA
montr_ci.dll:  Returning 0xe000020e for function 0xc.
AudMig: No audio endpoint migration settings found 0x2
AudMig: No audio endpoint migration settings found 0x2
2010-02-27 19:59:17, Info                  CBS    Starting TrustedInstaller initialization.

So you can see mine does not stop where yours does, and it does start doing time stamps. But later on, it does go back to logging more display entries without timestamps on them. Let's take a look at some more files...

C:\windows\TSSysprep.log

C:\Windows\Panther\setupact.log

C:\Windows\Panther\UnattendGC\setupact.log

However since there appears to be a LOT of driver activity with the display, I am wondering, did you (clive) inject any drivers to your install?

I have got all the drivers we use in our organization, as I said the 64 bit master has 0 issues, it's the 32 bit master that is slow. Both the 64 bit master and 32 bit master were built on the same hardware a Dell Optiplex 755 Quad core.

Attached are all the files you requested.

TSSysprep.rar

UnattendGC.rar

setupact.rar

Link to comment
Share on other sites
cluberti

cluberti

Posted
Posted

Question - how many language packs are installed in this image? I've only ever seen the call to "Launching [C:\Windows\system32\oobe\setup.exe]..." from windeploy take that long when an image had a large number of language interfaces installed...

Link to comment
Share on other sites
clivebuckwheat

clivebuckwheat

Posted
  • Author
Posted (edited)

Eng-us, eng-ca, fr-ca, the same as the 64 bit which has 0 issues. I think your right it has something to do with the video driver, as you stated above. I just add the three language via inputlocale in the sysprep.xml file. Same as I did with the 64 bit master image.

Question - how many language packs are installed in this image? I've only ever seen the call to "Launching [C:\Windows\system32\oobe\setup.exe]..." from windeploy take that long when an image had a large number of language interfaces installed...

Edited by clivebuckwheat
Link to comment
Share on other sites
Tripredacus

Tripredacus

Posted
Posted

The first thing I want to say is that we can't gauge the 32bit image based on how the 64bit behaves. They aren't the same thing. Now if you were to say a different version (say Home Premium) of 32bit worked fine, that would be a different story. So let's keep 64bit out of the discussion all-together for now.

Checking the new setupact.log, it looks like starting around 23:18 and ending around 23:34 it is installing drivers. Definately appears to be the slowest part of the setup. Comparing to my log (I'm at work now, and my install was done with a master image instead of a DVD) only takes 4 minutes to install drivers. You can see this is the period of time that Cluberti may be refering to, which you can find in the UnattendGC\setupact.log:

2010-07-30 23:18:23, Info                         [windeploy.exe] Launching [C:\Windows\system32\oobe\setup.exe]...
2010-07-30 23:34:59, Info                         [Shell Unattend] Running 'specialize' pass

Presumably, this isn't caused by the total amount of drivers you had installed into the master image.

Link to comment
Share on other sites
cluberti

cluberti

Posted
Posted

No, drivers would indeed not cause this particular delay. The only other times I've seen this, redoing this with an image without language packs added removed the problem. This is sysprep running oobe/setup, which is configuring OOBE and languages. It's taking all of it's time there, but as to why, I couldn't say for sure - I can only say that the other times I've seen this it's been problems with language packs added to the base image.

Link to comment
Share on other sites
clivebuckwheat

clivebuckwheat

Posted
  • Author
Posted

so remove the languages in the inputlocale in the sysprep.xml to test?

No, drivers would indeed not cause this particular delay. The only other times I've seen this, redoing this with an image without language packs added removed the problem. This is sysprep running oobe/setup, which is configuring OOBE and languages. It's taking all of it's time there, but as to why, I couldn't say for sure - I can only say that the other times I've seen this it's been problems with language packs added to the base image.

Link to comment
Share on other sites
cluberti

cluberti

Posted
Posted

Potentially - can you get the CBS logs from one of these sysprep runs?

What specifically is happening when OOBE runs at this point is it's extracting all of the language packs you've added, and then adding the servicing/WinSXS binaries to the system. French being a fully-localized version of a language pack (versus en-ca, which is just CA on top of the base EN) takes a lot longer compared to the others. The more language packs you add, the longer this takes (and remember, binaries for x64 are at least twice as large as x86, because they contain both amd64 and wow64 versions of the files).

Taking 35 - 40 minutes seems a bit excessive though, so if you could repro one more time and get the setup*.log files as well as the \Panther directory and CBS.log, that would be useful (the CBS log might be very interesting).

Link to comment
Share on other sites
Tripredacus

Tripredacus

Posted
Posted

But doesn't the logs make record of it working with different languages? The setupact.log in Panther (not UnattendGC) has these at the start and stop of the delay:

2010-07-30 23:18:42, Info                  SYSPRP SPPNP: Making sure system services have been started...
2010-07-30 23:19:29, Info                  SYSPRP SPPNP: Reinstalling devices on the system...
2010-07-30 23:19:29, Info                  SYSPRP Status: Active
2010-07-30 23:19:29, Info                  SYSPRP Status: Total = 6,	Complete = 0, 	Progress = 0%	(0%)
// snip //
2010-07-30 23:34:46, Info                  SYSPRP Status: Active
2010-07-30 23:34:46, Info                  SYSPRP Status: Total = 208,	Complete = 207, 	Progress = 99%	(99%)
2010-07-30 23:34:46, Info                  SYSPRP Status: Active
2010-07-30 23:34:46, Info                  SYSPRP Status: Total = 208,	Complete = 208, 	Progress = 100%	(100%)
2010-07-30 23:34:46, Info                  SYSPRP Callback canceled operation, Err = 1223!
2010-07-30 23:34:46, Info                  SYSPRP DeviceInstallStatusThreadProc failed, Err = 1223
2010-07-30 23:34:48, Info                  SYSPRP SPPNP: Devices reinstallation completed.

Link to comment
Share on other sites
clivebuckwheat

clivebuckwheat

Posted
  • Author
Posted

But doesn't the logs make record of it working with different languages? The setupact.log in Panther (not UnattendGC) has these at the start and stop of the delay:

2010-07-30 23:18:42, Info                  SYSPRP SPPNP: Making sure system services have been started...
2010-07-30 23:19:29, Info                  SYSPRP SPPNP: Reinstalling devices on the system...
2010-07-30 23:19:29, Info                  SYSPRP Status: Active
2010-07-30 23:19:29, Info                  SYSPRP Status: Total = 6,	Complete = 0, 	Progress = 0%	(0%)
// snip //
2010-07-30 23:34:46, Info                  SYSPRP Status: Active
2010-07-30 23:34:46, Info                  SYSPRP Status: Total = 208,	Complete = 207, 	Progress = 99%	(99%)
2010-07-30 23:34:46, Info                  SYSPRP Status: Active
2010-07-30 23:34:46, Info                  SYSPRP Status: Total = 208,	Complete = 208, 	Progress = 100%	(100%)
2010-07-30 23:34:46, Info                  SYSPRP Callback canceled operation, Err = 1223!
2010-07-30 23:34:46, Info                  SYSPRP DeviceInstallStatusThreadProc failed, Err = 1223
2010-07-30 23:34:48, Info                  SYSPRP SPPNP: Devices reinstallation completed.

where is the CBS log located?

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
 Share
Go to topic listing

  • Recently Browsing   0 members

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