Hello,

I am receiving an Invalid signature for registry hive message on the second step of the Imager. The first time I used the Fling it worked, now every time I run it I get the same error in the same spot. I'm trying to create an image of Win 11 22H2 using a Win 10 laptop with 16gb ram and 8 logical processors.

So far I have deleted everything, uninstalled, rebooted and reinstalled but still get the same error.

Thanks

Hi Brice,

Invalid signatures on the registry usually indicates the VM did not gracefully shutdown from the previous step. Imager is able to detect this state and reboot the VM to clear this. However, in your case this is occurring at the Install OS stage which is just going to use the hive files from base ISO. Maybe there is an inconsistency in the hive files applied from the ISO you are using, but granted it worked the first time which impacts this assumption.

Can you please send the imagertoolw log file (under %LOCALAPPDATA%\VMware\Imager\logs) to: ws1labsImager@vmware.com, and we have a closer look.

Where did you obtain the Win11 ISO?

Thanks for reporting this.

Hi Paul,

The logs have been submitted. I downloaded the ISO from the Microsoft Volume Licensing Site. I've tried a Win10 and Win11 ISO and both generate the same error.

Thanks Brice. The logs indicate the OS installation is not completing and timing out after 2 hours. I suspect it is stuck on an install screen waiting for user input, something we may have missed in our unattend.xml file sensitive to your environment. Unfortunately we are unable to auto capture OS install logs unless the installation completes because of this invalid signature error.

Could you please open the console of the VM in Workstation or Player when at the install stage and see where it is stuck or what it is doing. Please send a screen shot to same email address.

Thank you for this new release and your great work at this project!

I have build a new image till the stage "Update OS" and exported the image as OVF to import to our test-environment.
I sc´kipped conscious at this stage and would expect that the windows image is in sysprep mode because sysprep is the last stage.

The same when preparing a golden image. I alwys work in sysprep mode until I do optimize and generalize with OSOT.

Why is the windows image after "Update OS" not in sysprep mode anymore?

Hi Tom,

Thanks for your feedback.

Are you referring to Windows audit mode? The Imager does not leave the image in audit mode between stages, allowing users to stop after any stage and have access to a fully functional Windows image.

If you wish to place your image in audit mode, you can do so manually after any stage of the Imager by following this guide here https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/boot-windows-to-audit-mode-or-oobe?view=windows-11.

Hope this helps

I just tried a very basic imager build, actually, this is my third try, running it directly on a server in our test lab. IT crashes right near the beginning while attempting to create the windows pe ISO. I have tried using several different Windows Client and Sever versions...

Here is the log output near the failure:
22-12-20 16:31:23.863 [22836] [INF] Microsoft LGPO cache file "C:\Users\Jon\AppData\Local\VMware\Imager\cache\LGPO.zip" exists
22-12-20 16:31:23.864 [22836] [INF] Microsoft LGPO cache extraction path "C:\Users\Jon\AppData\Local\VMware\Imager\cache\LGPO.keep"
22-12-20 16:31:23.866 [22836] [INF] Windows PE ISO build required
22-12-20 16:31:23.871 [22836] [INF] Windows ADK feature "Deployment Tools" is installed
22-12-20 16:31:23.872 [22836] [INF] Windows ADK feature "Windows Preinstallation Environment" is installed
22-12-20 16:31:23.874 [22836] [INF] Running Windows PE ISO build script to create "C:\Users\Jon\AppData\Local\VMware\Imager\cache\ImagerWinPE.keep.iso"
22-12-20 16:31:23.875 [22836] [INF] Creating Windows PE
22-12-20 16:31:23.888 [22836] [INF] Started process: "C:\Program Files\VMware\Imager\Assets\BuildWinPE.cmd" C:\Users\Jon\AppData\Local\VMware\Imager\cache\WinPE-iiheafn1.qyb.dismtmp C:\Users\Jon\AppData\Local\VMware\Imager\cache\WinPE-iiheafn1.qyb.iso
22-12-20 16:31:26.374 [22836] [WRN] ERROR: Failed to mount Windows PE image.

22-12-20 16:31:26.382 [22836] [WRN] Reporting BuildImageCommand error
22-12-20 16:31:26.382 [22836] [WRN] Failed to create customized Windows PE ISO.
22-12-20 16:31:26.384 [22836] [INF] End BuildImageCommand scope
22-12-20 16:31:26.389 [22836] [INF] Request starting HTTP/1.1 GET http://localhost:5097/api/v1/images application/json -

Any Ideas? I would greatly appreciate being able to get this tool working :)

Thank you!!
Nightshade

Nightshade, As an experiment could you please run the following on an elevated command prompt and share the output:

"C:\Program Files\VMware\Imager\Assets\BuildWinPE.cmd" C:\Users\Jon\AppData\Local\VMware\Imager\cache\WinPE-iiheafn1.qyb.dismtmp C:\Users\Jon\AppData\Local\VMware\Imager\cache\WinPE-iiheafn1.qyb.iso

If this doesn't give us anything useful, on line 137 of the BuildWinPE.cmd script add the following parameter to the "dism /Mount-Image" command so we can get the dism logs:

/LogPath:C:\Users\Jon\AppData\Local\VMware\Imager\cache\dism.log

None of this will workaround the problem but should give some us insight.

We have experienced the odd reliability issues with the WinPE script, especially on these dism commands. Because of this we have rewritten the BuildWinPE script in Powershell and have added dism log capture so we have better diagnostics to work from. This will be in the next 2.1 release due early January. If there is some specific problem to your environment, that is good to know now so we can get a fix in for it.

Thanks for reporting this.

Thank you very kindly for your response Paul.

PS C:\Program Files\VMware\Imager\Assets> .\BuildWinPE.cmd C:\Users\Jon\AppData\Local\VMware\Imager\cache\WinPE-iiheafn1.qyb.dismtmp C:\Users\Jon\AppData\Local\VMware\Imager\cache\WinPE-iiheafn1.qyb.iso
Copying Window PE image files to "C:\Users\Jon\AppData\Local\VMware\Imager\cache\WinPE-iiheafn1.qyb.dismtmp"
Mounting Windows PE image

Error: 577

Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.
ERROR: Failed to mount Windows PE image.
Cleaning up temporary files
PS C:\Program Files\VMware\Imager\Assets>

Well, this was somewhat revealing. I added the log parameter to the mount image command any just to see if it would provide any additional information. It seems to be about the same to me but maybe there is something in the extra lines that helps you out...

2022-12-20 22:57:55, Info DISM DISM.EXE: Executing command line: "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\AMD64\DISM\dism" /Mount-Image /ImageFile:"C:\Users\Jon\AppData\Local\VMware\Imager\cache\WinPE-iiheafn1.qyb.dismtmp\media\sources\boot.wim" /Index:1 /MountDir:"C:\Users\Jon\AppData\Local\VMware\Imager\cache\WinPE-iiheafn1.qyb.dismtmp\mount" /Quiet /LogPath:C:\Users\Jon\AppData\Local\VMware\Imager\cache\dism.log
2022-12-20 22:57:55, Info DISM DISM Imaging Provider: PID=6264 TID=26840 WIM image specified - CGenericImagingManager::GetImageInfoCollection
[6264.26840] [0x80070241] OpenFilterPort:(365): Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.
[6264.26840] [0x80070241] FltCommVerifyFilterPresent:(459): Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.
[6264.26840] [0x80070241] WIMMountImageHandle:(1102): Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.
[6264.26840] [0x80070002] StateStoreRemoveMountedImage:(1124): The system cannot find the file specified.
[6264.26840] [0x80070002] WIMMountImageHandle:(1344): The system cannot find the file specified.
2022-12-20 22:57:55, Error DISM DISM WIM Provider: PID=6264 TID=26840 "Failed to mount the image." - CWimImageInfo::Mount(hr:0x80070241)

Any suggestions on how to proceed? Thank you for your help. If it is to much trouble, I am happy to just wait until January to use the upgraded PowerShell script. I appreciate your time and don't want to take up to much if just waiting a week or two will produce the same or better result with out costing you anything additional. Thank you for the help :)

Nightshade

Thanks Nightshade, good info. This seems to indicate a signature verification problem with the ADK's filter driver (wimount.sys) when Secure Boot in enabled:

https://social.technet.microsoft.com/Forums/en-US/7dd076c6-73c2-4820-a691-abdf6b9561b4/adk-1703-mountwim-577-windows-cannot-verify-the-digital-signature?forum=win10itprosetup
https://www.msnloop.com/windows-adk-1703-echoue-secure-boot/
https://www.thewindowsclub.com/windows-adk-windows-10-knows-issues-workaround-fix

These indicate a problem for an old version of the ADK (1703) which was apparently fixed by Microsoft soon after. However, the technet thread below hints that the problem might not be limited to ADK 1703, but doesn't offer a solution:

https://social.technet.microsoft.com/Forums/en-US/5d069c77-f0ba-4d26-a7b2-0db318bbb828/adk-mount-wim-error-577-dism-wimmountsys-windows-10200420h1?forum=mdt

Did you have the ADK installed on your machine before using Imager? I am curious what version you have - can you run dism with no arguments. Running with full path to dism.exe is required to avoid getting the native OS dism executable:

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\AMD64\DISM\dism.exe"

If this is older than 10.0.22621.1 (ADK for Windows 11 22H2), I suggest upgrading to the latest:

https://learn.microsoft.com/en-us/windows-hardware/get-started/adk-install

Or, you can simply uninstall the ADK (and the ADK Windows PE add-on) and start a new Imager build job which will install the latest automatically.

Other option is to disable Secure Boot, but appreciate this might only be practical if you are trying out Imager within a VM.

Since this is likely something to do with ADK installation, I am fairly certain our new Powershell build script won't help you.

Hello Paul! Merry Christmas and Happy Holidays. Thank you for all the information etc.

First things first, my primary workstation is in a test lab and I use the rEFInd EFI bootloader on my system because although I primarily use a Windows 10 OS, I quite often boot into a large number of alternative environments. The rEFInd bootloader was the only option that would easily allow me to create a large number of boot configuration entries while also having reasonable graphics AND UEFI compatibility. Unfortunately, the one thing rEFInd does not have is a signed version that is compatible with Secure Boot. Because of this I have secure boot disabled.

I do, however, think it has been a long time since I upgraded my ADK. I will assume that is probably the issue and check what version number it is...

My version is 10.0.22523.1000 which is older than the version you suggested. Maybe it is possible that secure boot is not the only problem with the older ADKs such that the older ADK can cause failures of this WinPE ISO Build script in the presence of Secure Boot and also in its absence. Its simple enough to uninstall the old ADK and WinPE Add on, then I will do ask you suggested and try to run an imager build again and allow it to automatically download the best ADK version.

Lets see........

As you suggested, I just uninstalled my old ADK and ADK Windows PE add on, then tried to run the imager again and it automatically downloaded the most recent version.

After that, the Windows PE ISO Creation task completed successfully.

While I am sure there are secure boot issues with these older versions of the ADK like you and the references you listed described, if that was the only problem you would think disabling secure boot (or running on a system that never had it enabled in the first place.) would solve the problem. The issues of the older ADK versions must be more widespread than just the secure boot problems.

Thank you very much for your help. Now I will be able to make use of Imager over my Christmas Break.
Thanks a bunch and Merry Christmas Paul and Everyone Else who Contributed to the Imager Project and to this message board.

Nightshade

Hi Nightshade,

Happy New Year! I am very glad this fixed the problem and you are unblocked. Information about this specific ADK version is difficult to find - it appears to be an old pre-release or insider build. Generally our testing with older versions of the ADK have been trouble-free but given your experience, for a future release of Imager we will enforce a set of known-good ADK versions. Thanks for persisting through this and getting it working.

I've just done an end to end test with very basic settings and it all worked quite nicely. Just one note: When provisioning the ManagedVM and running "InstallOnWindows.exe" it obviously required administrative rights to install the ManagedVM Agent. In a corporate scenario this may be a difficult hurdle as not all users have administrative access. Thinking about an alternative way for this would be very welcome.

Thanks for the feedback Julius. I share your concerns about this limitation and will ask my team to explore some alternatives.