Blue Screen (BSOD): CONFIG INITIALIZATION FAILED after WIM Image Creation Process

System Requirements:

  • Windows 7, 8.0, 8.1, 10
  • Windows Server 2008 R2, 2012, 2012 R2, 2016
  • DISM, MDT, SCCM, WAIK, WADK

The Problem:

I am a DVBLink user. DVBLink does not play nicely with Windows Service and consequently it wants to run on a client OS. This means that I have lots of server hardware running server Operating Systems and one device with 4 TV Tuners in it running Windows 10.

After modifying the registry of an off-line WIM image, after the initial image has been inflated onto the drive, the system blue screens (BSOD) at the first reboot with

:(
Your PC ran into a problem and needs to restart. We'll restart for you.For more information abotu this issue and possible fixes, visit https://www.windows.com/stopcodeIf you call a support person, give them this info:
Stop code: COMFIG INITIALIZATION FAILED

BSOD

The newly imaged system will now get stuck in a boot loop.

More Info

You have a corrupted registry.

The Fix

There are a number of possibilities to explore first

Check that you haven’t deleted the contents of CurrentControlSet (reference machine prior to sysprep) or ControlSet001 (reference machine and WIM file) from the registry

Check that you haven’t deleted the SYSTEM file from C:\Windows\System32\Config (this is a hidden file and it has no file extension)

Finally, if you injected registry data into an offline WIM image, ensure that you did not create the Key .\CurrentControlSet in the C:\Windows\System32\Config\SYSTEM. CurrentControlSet is a virtualised key that is loaded and unloaded dynamically as part of the Windows boot proceess (it is actually a copy of ControlSet001). When the system goes through shutdown or a reboot, CurrentControlSet is cleared and ControlSet001 is copied in-place. If the key CurrentControlSet exists in the WIM file’s registry, Windows will present the CONFIG INITIALISATION FAILED blue screen of death as it is not expecting the CurrentControlSet key to exist at all.

To fix the problem, re-mount your image and from the SYSTEM container move any data from CurrentControlSet into ControlSet001 and then completely delete the key for CurrentControlSet

“The system image restore failed. Error details: Incorrect function (0x80070001)” when attempting to restore a Windows Server Backup / Windows Backup Image over the network from Windows Backup or bootable recovery media

System Requirements:

  • Windows Vista, 7, 8, 8.1, 10
  • Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016

The Problem:

If you attempt to restore a Windows Server Backup or Windows Backup recovery image (system state) from a bootable recovery media (either DVD, USB or a recovery partition) you receive the following error message

The system image restore failed.

Error details: Incorrect function (0x80070001)

More Info

Just to keep this simple. The limited amount of information available on-line on this error suggests that either the image is corrupt or you are having a network reliability issue.

These could be true. In my case, it wa the path length that I was using to recover the image from. I was recovering from

\\192.168.15.106\BackupFiles\Servers\2012 R2\WindowsImageBackup\<hostname>\…

It turns out that the entire path must be 110 or fewer characters otherwise it will fail with the 0x80070001 error.

A simple fix is to temporarily create the path \\192.168.15.106\BackupFiles\WindowsImageBackup on your share and then copy the <hostname> folder into it. This worked in my case.

Preventing a driver from automatically installing from Windows Update on Windows 10 (when it keeps reinstalling before you can run the driver blocking tool)

System Requirements:

  • Windows 10

The Problem:

Microsoft’s descent into Apple design and general irrelevancy continues unabated with design time decisions for Windows 10. Obviously when drivers get released onto Windows Update, they’re going to work for everyone. Obviously.

In my experience the main issue is with integrated chips from the large PC OEM’s (Dell, HP etc). The subtle modifications that they make in their own proprietary releases of their “2010” driver when do not necessarily directly map onto the generalised driver with the same PnP ID’s being detected from Windows Update.

In the last week I’ve had to deal with this no less than 8 time on 6 separate occasions. I, like most people in IT, have encountered this many times before however it has usually been with fairly large driver updates that require a reboot – prolific Windows 10 dual screen problems with Windows Update Intel HD Graphics drivers anyone?

So unlike previous Windows versions, there is no longer a way to stop Windows Update automatically installing updates immediately using the UI, you have to resort to group policy to have any chance of delaying it. In Windows 10 there is also no way to block certain updates if you do not want them / they don’t work.

Of course Microsoft’s business decision behind this end user horror is quite simple: Too many people blocked or are blocking KB3035583 (the Windows 10 installer update for Windows 7 and 8.x) preventing them from force feeding you Windows 10. They also want to de-fragment their ecosystem (I can empathise with this) and consequently they want to ensure that people are being spoon fed the latest feature updates as soon as possible under the new Windows feature release cycle.

Of course, if you get a bad update or a bad driver, now that there is no way to block it, you will uninstall it and it will simply come back.

The problem is exacerbated with small driver downloads (in the kilobytes range) that do not require reboots. In my most recent cases a 2009 HP Laptop Webcam. a 2010 HP Laptop Fingerprint reader and a 2008 Toshiba laptop touch screen driver. By the time that you have uninstalled the bad driver, rolled back to ‘no driver’/a working driver, run Windows Update to make Windows aware that there is a bad one available and then in turn run the Window Update Show/Hide Tool. Windows has already reinstalled the bad driver and as a consequence the WU Show/Hide tool is unable to give you the option to block the driver.

Bravo Microsoft. Bravo!

More Info

As eluded to above, the issue is one of timing. Windows 10’s brutal and where possible immediate desire to install anything that comes down the update channel is breaking the sequence necessary to correctly use the WU Show/Hide tool.

The required sequence is:

  1. Uninstall defective device, deleting the old driver
  2. Run Windows Update so that the local Windows Update Available Updates Catalogue shows an available driver update for that device
  3. <Windows Update should NOT do anything at this point>
  4. Run the Windows Update Show/Hide Tool
  5. Block the bad driver update
  6. Re-scan Windows Update to clear the update from the Available Updates Catalogue
  7. Install updates manually / after a sensible delay

In practice, at step 3 Windows Update – now aware that there is a driver waiting – is simply installing the bad driver again. This prevents you from running the WU Blocker tool. The problem is exacerbated by small updates (or fast Internet connections) because there isn’t a delay between Windows realising that there is an update and taking the time to download it before executing the Install.

This delay is useful for things like the Intel HD Graphics problem because the driver files is over 120MB and in many cases this gives you enough time to run the WU Blocker tool successfully.

The Fix

Yes, you can mess around with Group Policy to fix this – unless of course you are on a home edition. Yes, you can also modify the driver installation policy, however again this isn’t always desirable. So I present a simple way to solve this.

  1. Download the Windows Update Show/Hide (blocker) tool from KB3073930
  2. Open Windows Explorer at C:\Windows\SoftwareDistribution\Download
  3. Open en elevated command prompt and type:
net stop wuauserv
  1. Return to C:\Windows\SoftwareDistribution\Download and delete everything in the folder (but not the folder itself) – this deletes the installer cache for the driver
  2. Right click on the C:\Windows\SoftwareDistribution\Download folder itself, choose properties
  3. Open the security tab
  4. Click Edit to change permissions
  5. Select the SYSTEM account from the accounts list
  6. In the Deny column next to the permission for “Write” place a tick – JUST place a tick next to Write, that is all that is needed!
  7. Click OK twice to return to Windows Explorer – accepting any messages and warnings about Deny actions and system folders
  8. Go to device manager, uninstall the defective device – ensuring that you select the option to delete the driver along with it
  9. Run Windows Update
  10. Windows Update will now attempt to install the device, however it will fail with error code 0x80246007
  11. Now run the Windows Update Show/Hide Tool, block the update
  12. Return to Windows Update and re-scan for the update to flush it out of the available update list
  13. Go back to setup 5 and REMOVE the Deny Write permission tick to undo your changes
  14. Return to Windows Update and re-scan for updates. Windows Update should inform you that your device is up to date and will not attempt to install the driver

View: Windows Update Show/Hide Tool

Error 1635 from Microsoft Office Installer when installing from a SMB File Source

System Requirements:

  • Office 2007
  • Office 2010
  • Office 2013 (Enterprise)
  • Office 2016 (Enterprise)

The Problem:

You’re one of the lucky people who has access to a version of Office that doesn’t need to use the awful “Click to Run” to perform the install. You are trying to use SCCM, Group Policy, a BAT file or some other remote invocation method to deploy Office from a source repository on a SMB file share.

Office starts to install, the installation looks like it is working and even one or two app’s appear on the start menu… before it unexplainably performs a roll back and uninstalls itself leaving your machine with no Office installation.

If you check the log files (in %temp% or c:\users\<user>\AppData\Local\Temp by default) you will find a Windows Installer Error 1635 entry listed before it commenced the rollback.

More Info

Windows Installer Error 1635 is “This patch package could not be opened. Verify that the patch package exists and is accessible, or contact the application vendor to verify that this is a valid Windows Installer patch package”.

If you are using SCCM, then you are probably attempting to execute this through the NT System account or via local admin.

Obviously you’ve checked the share permissions, perhaps even enabled a Null Session Share to allow anonymous access to the share… and it still doesn’t work. The client script is obviously executing successfully because the setup programme loads and runs for 10 minutes or more quite happily before erroring out.

The Fix

Quite simply, save yourself a headache and script the process to call the Office setup.exe from the local machine rather than directly against the SMB Share. This will solve the problem. Something in line with the following will download the installer and files from the repository to the OS Temp directory, execute the installer process and then clean-up

mkdir C:\Windows\Temp\OfficeSetup

xcopy "\\server\share" "C:\Windows\Temp\OfficeSetup" /Y /E /V /C /Q /H /R

:: Pre-Install actions here

call "C:\Windows\Temp\OfficeSetup\setup.exe" <switches go here>

:: Post-Install actions here

rmdir "C:\Windows\Temp\OfficeSetup" /S /Q