Captured a BIOS image of a 1909 system. Deploys it to an EFI system but gets: "No operating system was found on this system" message


Article ID: 195604


Updated On:


Deployment Solution IT Management Suite Management Platform (Formerly known as Notification Server)


The customer is trying to deploy a new image captured from a Windows 10 1909 BIOS system to an EFI system. 

This is with DS 8.5 RU3 (with POST-RU3 installed)

The source for the image is a Virtual Machine (VM) that was upgraded from Windows 10 1803 (BIOS) to Windows 10 1909 (EFI); Enterprise Edition is used, with volume licensing (KMS).  The underlying virtualization software is Nutanix AHV.    The customer has also duplicated the issue with a fresh installation of Windows 10 1909, which would indicate that the upgraded image is not the issue.

Deployment of that image also failed with the "No operating system was found on this system" message.


Known Issue.

As far as what they fixed, they had to add some code handling around the following:

Ghost currently doesn't use BCDBoot command, instead it copies custom set of boot binaries, and performs several calls of BCDEdit.

The root cause of the issue is that EFI binaries that are copied to (newly created) ESP, somehow loose digital signature. All files in ESP are filled with zeroes. The image itself contains signed binaries.

These zero filled files are WOF files:

To create UEFI partition ghost copies these files using low level file access API. But ghost doesn't support data extraction from WOF files.  We had to rework current implementation and use a different approach to copy needed files.


DS 8.5 RU3 and RU4


This issue has been reported to Symantec Development team. A fix has been added to our next release: ITMS 8.6

The current workaround is as follow:


Many times some people will image a Windows 10 box and get a variation of the "No Operating System found".

The fastest fix has been to boot with a Windows 10 Installation disk, run recovery mode, and then do the following:

At command prompt:

Ø  Diskpart

Ø  List volume (note boot partition, windows partition letter)

Ø  Select volume x (x = partition responsible for booting the system (hidden fat32 partition usually)

Ø  Assign letter w (to be able to recover the boot files)

Ø  Exit (exit diskpart)

At Command prompt:

              Bcdboot x:\Windows /s w: /f UEFI (x=boot partition)(w=drive letter you assigned to the hidden fat32 partition)


Reboot (Choose the new boot option – there may be 2.. choose one, if it doesn’t work, choose the other)

In Windows launch msconfig, go to the boot menu and delete the non working entry. Save (Apply) and restart to test.

This doesn’t work for a mass deploy scenario.

We have seen this on OEM partitioned machines as well as disk wipe and default windows install scenarios.



Here are some references for the workaround steps suggested above in order to avoid the “No operating system was found on this system” :