Video Screencast Help

GSS v2.5 Ghost v11.5 (ghost.exe) Script Problem

Created: 15 Jan 2013 | 8 comments

Problem Description

I am a novice user of Ghost.

I have a ghost image of Win7 x64 size-limited to 4 GB spans that was created
with ghost32.exe.  It consists of a 100 MB System Reserved partition and
another partition that contains just a C: drive.

When executed from a DOS batch file, the DOS version of Ghost v11.5
(ghost.exe) from Ghost Solution Suite v2.5 executes a two-line ghost script.
Upon reboot the Windows Boot Manager displays the following:

                            Windows Boot Manager

Windows failed to start.  A recent hardware or software change might be the
cause.  To fix the problem:
     1. Insert your Windows installation disc and restart your computer
     2. Choose your language settings, and then click "Next".
     3. Click "Repair your computer."

If you do not have this disc, contact your system administrator or computer
manufacturer for assistance.

Status 0xc000000e
Info   The boot selection failed because a required device is inaccessible.

ENTER=CONTINUE                                                 ESC=ABORT

I think that Ghost is executing the first line of the script and not the
second.  The two lines of the script "tmp2.rst" are as follows:

-Clone,Mode=pload,dst=1:1,src=..\base_os\tmp.gho:1 -fx -sure -span -ntic -afile=c:\\Logs\\GhostErr.txt
-Clone,Mode=pload,dst=1:2,src=..\base_os\tmp.gho:2 -fx -sure -span -ntic -afile=c:\\Logs\\GhostErr.txt


A coworker of mine (with more ghost experience) was able to run ghost from
the DOS command-line to restore the ghost image on an Lenovo T61p laptop.
He is investigating using NTUtils as a short-term alternative to using Ghost.

Comments 8 CommentsJump to latest comment

EdT's picture

For modern hardware, you would be much better off using WinPE rather than DOS, as DOS has many limitations when used with modern hardware.

When using DOS, it is normal to have a 2Gb span size, as this is the file size limit of "regular" FATxx partitions.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

ethughes1's picture

My comment regarding the WorkAround of investigating NTUtils was incorrect.  He is investigating NTFS Utils.

For now, I am stuck supporting a legacy DOS solution.  I tried and failed again with the following differences in the environment:

  1. I took EdT's advice and created a ghost image of Win7 (100 MB System Reserved, the rest C:\) using Ghost v11.5 invoked with command    ghost32.exe -span -size=2048   It created tmp.GHO, tmp001.ghs, tmp002.ghs, and tmp003.ghs size limited to 2GB.  I was able to verify the image by using Ghost v11.5 (ghost32.exe) to restore the image to a Lenovo T61p Laptop.
  2. I un-escaped the file path C:\\Logs\\GhostErr.txt as C:\Logs\GhostErr.txt in the tmp2.rst ghost script file.
  3. I manually renamed tmp.GHO to tmp.gho (all lowercase)
  4. I tried to restore the image using Ghost v11.5.1 (ghost.exe)

I see Ghost v11.5.1 starting up and then going away quickly (a bad sign), the CMOS gets loaded, and upon reboot, I get the "Windows failed to start" message from the Windows Boot Manager.

I manually ran ghost and got:

Internal Error 36000

An internal inconsistency has been detected

If the problem persists, contact Symantec Technical Support


Before I pressed the OK button, I copied the Details:

Connection type Local

Source Partition Type:7[NTFS], 100 MB, 24 MB used, System Reserved

                           from Local File C:\BASE_OS\TMP.GHO, 152627 MB

Target Partition Type:7[NTFS], 103 MB

                          from Local drive [1], 152627 MB

Current file        98 tracking.log

I manually ran ghost again with manually typing the command-line parameters from the second line of the file.  Ghost v11.5.1 appeared to be acting normally with an advancing progress indicator.  I copied the Details:

Source Partition Type:7[NTFS], 152525 MB, 18516 MB used, Disk Load

                           from Local file C:\BASE_OS\TMP.GHO, 152627 MB

Target Partition Type:7[NTFS/HPFS extd] 121794 MB

                          from Local drive[1], 152627 MB

EdT's picture

Are you using Lenovo's System Recovery software in your base image, as this creates a non standard boot sector if I recall correctly, and I think you need to use the /IB switch to get around this.

I note you did not comment on using DOS rather than WinPE. Are you imaging machines with the bios set to compatibility mode as DOS does not have SATA support?

Do you have any Advanced Format disks in your hardware? If so, you may need to specify cylinder boundaries due to the way these drives work.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

Dpak D's picture

Create a disk image with -IB swiitch and restore the same,which should be the straight forward solution.

ethughes1's picture

EdT and Maneesh,
The images I created from a WinPE Bootable Ghost v11.5 CD, are restorable to the same T61p laptop. I create the GHO image, wipe the partitions using "gdisk32.exe 1 /y /del /all, and restore the image. If the image is created without the -IB switch, it is restored without the -IB switch. If the image is created with the -IB switch, it is restorable with the -IB switch.

The images I had created are not using Lenovo's System Recovery software. I did not see it in the list of installed programs. It is using some kind of Lenovo power management software.

I can run "ghost32.exe -script=tmp2.rst". Ghost32.exe fails if I had not already created the partitions.
If I create the partitions:
"gdisk32.exe 1 /CRE /PRI /SZ:100" and
"gdisk32.exe 1 /CRE /PRI /SZ:152521"
and then run ghost
"ghost32.exe -script=tmp2.rst",
it works fine.

In my test MS-DOS ramdisk environment, I am telling the legacy "software" to create a 100 MB partition and the rest, a second partition. From my comments above, it appears that the second partition being created is 30 GB smaller

Source Partition Type:7[NTFS], 152525 MB, 18516 MB used, Disk Load

from Local file C:\BASE_OS\TMP.GHO, 152627 MB

Target Partition Type:7[NTFS/HPFS extd] 121794 MB

from Local drive[1], 152627 MB

What is the proper way of checking for an Advanced Format disk?
I executed the following command:
"wmic partition get BlockSize, StartingOffset, Name, Index"
which returned

"Block Size Index Name Starting Offset
512 0 Disk #0, Partition #0 32256
512 1 Disk #0, Partition #1 108380160

I don't know whether this is a physical block size or a logical block size. I am using a 160 GB Seagate Momentus 7200.2 hard-drive. It is spec'd to 512 bytes per sector in the product manual.

I still need to get back to you on how the BIOS is set.

EdT's picture

OK, it's not an advanced format disk, as a 160Gb drive does not need it.

When you say that the second partition is being created 30Gb smaller, what exactly do you mean? Are you saying that there is 30Gb capacity left unused on the drive?  If so, the reason for that is the limitation of how MSDOS addresses hard disks using 28 bit LBA, which I believe was the address limit that DOS could handle. (

If you work out the number of sectors represented by 2 to the power 28, and then divide by 2 to get the number of Kilobytes storage this represents, the figure comes to around 132 Gb. 

Again, there are other variables including the age and design of the bios, but it's one reason I would always recommend using WinPE for any recent hardware.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

ethughes1's picture


In the case where I have a 100 MB "System Reserved" primary partition and a 96 GB Win7 primary partition, using a Ghost Bootable CD (WinPE), I can manually use GDISK32.exe to create two primary partitions (100MB and 96 GB) and use the ghost32.exe manually to restore these partitons. I am using Ghost v11.5 here.

It appears that in the linux PXE (bootable from CD), we are creating a 30 GB primary partition prior to starting the DOS ramdisk.  In the DOS ramdisk, we are passing in parameters to FreeDOS FDISK v1.2.1 to partition the hard disk drive.

In the simple case where I have a ghost image of Win7 on one primary partition of a particular size, FDISK creates a primary partition and Ghost restores a clone of that image to the newly created partition and eventually upon reboot, It boots and I have a two primary partitions (one of them 30 GB).

In the case where I have a 100 MB "System Reserved" primary partition and a 96 GB Win7 primary partition, FDISK creates a 100 MB primary partition and an extended partition containing a logical partition of 96 GB.

When GHOST.exe v11.5.1 executes, it restores the 100 MB partition fine (I think) and now blows up with a

General Protection Fault in RMCB at eip=196330; flags=3002
      eax=ffff0001 ebx=00001246 ecx=00000000 edx=000015c3 esi=0000142a edi=00002418
      ebp=00acacfc esp=000023fc cs=af ds=3b es=33 gs=bf ss=33 error=0000

and GHOST.exe returns a non-zero return code.

Is there anything that I need to do to Win7 before I image it with ghost (besides removing temp files and defragging)?

EdT's picture

To be honest, I am confused about when you are using DOS and when you are using WinPE. Mixing the two environments may be the underlying cause of your problems. There should be no preparation required when creating a Win 7 image, but you need to ensure that the source partition numbering will be the same as the target partition numbering. Thus if the source has a boot manager in the first partition, then not imaging this will result in a partition numbering shift on the target which will definitely stop Win 7 booting.

Can I also check that you are using build 2266 of Ghost 11.5.1, as this has not been mentioned anywhere in this thread.

As I have no Linux experience, I cannot advise you on any Linux aspects.

Have you tried creating a disk image as a test?

Finally, when using WinPE to build systems, I personally prefer to use the DISKPART utility in WinPE to clean and to partition disks - you can get an idea of how to do this in my article:

where it looks at creating bootable USB devices. The diskpart commands are used in that, but of course you can run DISKPART from the WinPE command prompt and then type ? for help.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.