“(0x80091007) Failed to run the action: Apply Operating System. The hash value is not correct.” on machines with 16GB RAM

This article is for all of those who receive 0x80091007 “The hash value is not correct” error message when trying to deploy WIM file using SCCM 2012 and you have already tried the following (without success):

• You trigged “Update Distribution Points” action, but it didn’t help
• You removed content from distribution points and re-distributed, but it didn’t help
• You removed the WIM file from SCCM library, moved the WIM file to a new location and re-added it (to force hash value change), but it didn’t help

The problem

My work colleagues approached me with similar problem: they were getting this error message when trying to deploy a particular Windows 7 WIM image through SCCM Task Sequence. They have tried all of the above, but with no luck. They had two machines, both Lenovo T470, but with slightly different specification:

• one with i5 series processor with 8GB of RAM (deployed without issues)
• one with i7 series processor with 16GB of RAM (failed every time)

The investigation

In process of elimination, the following has been tried with success:

• Deploying vanilla Windows 7 image through the same SCCM Task Sequence (success)
• Deploying intended WIM image through MDT (success)
• Deploying intended WIM image through SCCM Task Sequence with Access content directly from the distribution point option selected on “Apply Operating System” step (success)

While the third option mitigated the problem, I didn’t consider it resolved. This behaviour causes the WIM file to be applied directly from the Distribution Point, hence skipping hash value check. It would not let me sleep at night…

I suspected the RAM from the start, as I have heard of cases where a dodgy RAM would cause this error in certain (rare) circumstances. However,  we have run manufacturers diagnostics on the machine and it reported no memory problems. I was also reluctant to try to swap memory DIMMs between machines before I have exhausted all of my options.

I had a hunch this is must have had something to do with the way Windows PE handles RAM. After all, the Task Sequence deployed vanilla image (2GB) without issues, but it failed to deploy intended image (8GB). I have run a quick WMI query on the machine (wmic memorychip get /format:list) and it revealed that machine comes with 16GB in a single DIMM. While this may be a red herring, it is worth pointing out we have deployed machines with 16GB of RAM before in this environment without issues.

It was time to limit amount of memory available to Windows PE… (no, this is not an issue with x64 images deployed in x86 WinPE – keep on Googling…)

The resolution

In order to limit RAM for Windows PE, I decided to use bcdedit. The boot images in this lab environment are served through WDS services, so in first instance I have imported a copy of existing boot image into WDS. Next, I queried the associated store to find out the GUID of Windows Boot Manager.

C:\>bcdedit /store "D:\RemoteInstall\Boot\x64\Images\DEV_SCCM_(x64)_RAMlimit.wim.bcd" /enum all

Windows Boot Loader
-------------------
identifier {0babbfae-bd1a-4bf7-980a-4221594e4f3e}
device ramdisk=[boot]\Boot\x64\Images\DEV_SCCM_(x64)_RAMlimit.wim,{60654cba-b38e-4dfa-9ae8-d53e64129eac}
description DEV SCCM (x64) (with RAM limit)
osdevice ramdisk=[boot]\Boot\x64\Images\DEV_SCCM_(x64)_RAMlimit.wim,{68d9e51c-a129-4ee1-9725-2ab00a957daf}
systemroot \WINDOWS
detecthal Yes
winpe Yes

Device options
--------------
identifier {60654cba-b38e-4dfa-9ae8-d53e64129eac}
inherit {68d9e51c-a129-4ee1-9725-2ab00a957daf}
ramdiskmcenabled No
ramdiskmctftpfallback Yes

Next, I have used that GUID to identify Windows Boot Loader and apply a setting that will limit WinPE’s RAM usage to 4GB (I have chosen this value arbitrarily without much forethought). The setting in question is called truncatememory and specifies address in bytes where WinPE will stop reading/writing memory. It accepts value in decimal or hexadecimal formats – I have chosen to use HEX.

You can read more about the setting on Microsoft’s website: https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/boot-parameters-to-manipulate-memory

C:\>bcdedit /store "D:\RemoteInstall\Boot\x64\Images\DEV_SCCM_(x64)_RAMlimit.wim.bcd" /set {0babbfae-bd1a-4bf7-980a-4221594e4f3e} truncatememory 0x100000000
The operation completed successfully.

C:\>bcdedit /store "D:\RemoteInstall\Boot\x64\Images\DEV_SCCM_(x64)_RAMlimit.wim.bcd" /enum all

Windows Boot Loader
-------------------
identifier {0babbfae-bd1a-4bf7-980a-4221594e4f3e}
device ramdisk=[boot]\Boot\x64\Images\DEV_SCCM_(x64)_RAMlimit.wim,{60654cba-b38e-4dfa-9ae8-d53e64129eac}
description DEV SCCM (x64) (with RAM limit)
truncatememory 0x100000000
osdevice ramdisk=[boot]\Boot\x64\Images\DEV_SCCM_(x64)_RAMlimit.wim,{68d9e51c-a129-4ee1-9725-2ab00a957daf}
systemroot \WINDOWS
detecthal Yes
winpe Yes

Device options
--------------
identifier {60654cba-b38e-4dfa-9ae8-d53e64129eac}
inherit {68d9e51c-a129-4ee1-9725-2ab00a957daf}
ramdiskmcenabled No
ramdiskmctftpfallback Yes

Last thing that I had to do was to run sc control wdsserver 129 to regenerate BCD store on WDS server and run another deployment. As you probably have already figured it out – it has worked like a charm!