We have created an unattended network installation setup for Windows 7 based on the WinPE present in WAIK. We boot a customized WinPE with the necessary network drivers injected and a CMD script prepares the disk partition (ie presents a freshly formatted empty filesystem), mounts the network installation image, and starts setup.exe with the unattend.xml for that particular machine.

All the extra drivers are copied to the C: drive of the new OS using $OEM$\$1 directory, thus the actual copying is done by setup.exe. Some of the drivers, notably the chipset/USB/storage/network drivers get imported by setup.exe into the DriverStore at the beginning (Microsoft-Windows-PnpCustomizationsNonWinPE section in unattend.xml). The directory holding the rest of the drivers (mainly graphics, audio, printer drivers) gets registered by a script running after setup.exe /noreboot finishes and before the first reboot. The script mounts the newly installed system's registry and adds the path to HKLM\Microsoft\Windows\CurrentVersion\DevicePath.

This unattended installer has proved to be successful for many different hardware configurations, except our latest machines based on Asus H81M-K motherboards and Intel G1840 CPUs. The configuration uses the integrated graphics of the CPU (PCI ID 8086:0402). For these machines, as long as the relevant Intel HD graphics driver is present in the installer, there is a delay of about 1 hour at the point during the installation where the screen displays the message "Setup will continue after restarting your computer" on a black background, with a small pulsating star below the message (the star does pulsate but nothing else happens for 1 hour). If the driver is not present, or for other machines (which do not use that driver), this message is displayed only for seconds and the machine reboots after that. If we omit the driver from the original installation and install it only later on, we do not see this exceptionally long wait.

There are more than 20 machines of the same configuration and all behave the same way. We have tested the latest driver version from Intel (DriverVer=09/25/2015, and the driver present at the motherboard manufacturer's support web page (DriverVer=01/28/2014,, there's no difference. Also, we have tested the two different ways of adding the driver (injecting into the DriverStore and adding to DevicePath), there's no difference. We have checked the logs of the installation, we have found no error messages that seem to relate to either the graphics driver or to that 1-hour wait.

The question is: how can we determine the cause of the extra long wait? Which party to escalate this to? MS might be the one to direct us to the proper logs or debugging options, but the problem very much sounds like related to the driver. Intel is the writer of the driver, however, they only provide any kind of support via their manufacturing partner, Asus. On the other hand, Asus is clearly not providing any piece of software in this equation, so they will likely not be able to fix it either. We would of course be equally happy to solve it or work around it by any other means. But we need the driver present at the first boot, otherwise we have no proper way to customize the display resolution through unattend.xml - which we really need.

  • Woah, that's a lot of text to read. You might be driving off some people with that length, would recommend shortening to the minimum required information. – boxspah Jan 17 '16 at 17:14
  • @scriptHero: that's good point, however, I think that every sentence contains useful information. But I'm open to any suggestions. – Laszlo Valko Jan 17 '16 at 17:46
  • 1
    have you tried injecting the drivers with DISM.exe /Image:C:\ /Add-Driver /Driver:d:\Drivers\ /Recurse? In many cases you can press F8 or <shift><enter><f10> or something to get a command prompt when it is stuck. Then review the log files in the Windows/Panther and or windows/system32/sysprep folder. – cybernard Jan 17 '16 at 21:10
  • or you can mount the WIM and using dism to inject it. – cybernard Jan 17 '16 at 21:11
  • What about installing that driver afterwards in your setupcomplete.cmd file? Would that be a temporary fix? – Joe Taylor Mar 4 '16 at 11:06

As we normally say: "The problem solved itself."

After we integrated the current ~150 recommended and some other 50 optional patches of Windows 7 into the install image, the issue is no longer present.

We haven't conducted much investigation (and surely have no intention to do so), so we cannot tell whether this was a timing issue/race condition and the stretching of the timing caused by the addition of the lot of patches helped, or this was a bug and some of patches actually fixed that.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.