Could not allocate page table memory

[Migration User]

I am getting this error trying utilizing Ghost 11.5.1.2266 from a boot CD trying to image a Dell OptiPlex 755.  I have the SATA set to ATA, and still no joy.  I'm at a loss for what to try next.  Any help would be greatly appreciated.

Thanks.

[ShawnOfTheFarm]

using Dos, Linux or winpe?  Do a scan disk and a boot time defrag to make sure that the hard drive is clean.  Also if you are not already using win pe you should change to winpe.

cheers,

[Migration User]

I'm using a dos based multiboot CD that I've been using for years as it has drivers for almost all cards and has been faster (at least from a time to boot standpoint - winpe is VERY slow to boot) than my winpe based disk which I need to update to the latest ghost version.  I will try it from the winpe disk and see if there's any difference.

[Migration User]

Is the error on a BSOD? Check that you have the correct mass storage drivers for that chipset loaded into your boot disk and DeployAnwhere (if you are using it) as well.

[Edward Tippelt]

At what point do you see the error when booting DOS ?  Are you able to reduce memory footprint by taking out the mouse driver completely and see if that makes a difference. With the bios set to ATA, is DOS able to see the partitions? (eg try running FDISK).

WinPE is indeed slower to load than DOS, as you are loading typically 150-200 Mb of data into RAM for WinPE instead of a couple of Mb or less.  However, WinPE is much superior in its ability to mount modern device drivers and access current hardware, so for me is the logical choice going forward.

[Migration User]

Some years ago reports of failures to allocate memory started appearing in Dell machines; this is due to a design fault in the machine BIOS; there are a number of BIOS APIs to report the available extended memory in the machine, and the DOS-extender software used to run 32-bit code in DOS tries a number of them in sequence.

In many Dell machines, all these various APIs return a single fixed size, typically 16Mb, which is the capacity limit of the very oldest of the APIs. On normal BIOSes all the APIs return different sizes depending on the era in which they were introduced, but Dell machines force Ghost to work in merely 16Mb of memory.

The workaround I developed for this many years ago was to ask customers to use the FreeDOS equivalent of the classic DOS HIMEM.SYS extension. That utility understands the relatively new ACPI data table BIOS API introduced in the Windows 95 era, which is the only BIOS API that works properly in these Dell models. This then makes the results of that one working API available to Ghost's DOS extender via the XMS API, and so running the FreeDOS HIMEM.EXE will let Ghost use a great deal more of the installed memory than a mere 16Mb.

Unfortunately because FreeDOS is not licensed cleanly it can't be bundled or redistributed by Symantec alongside Ghost, but it's easy enough to obtain this tool by itself and include it in the PC-DOS templates used by the Ghost Boot Wizard, since it does work as a drop-in replacement for the IBM one.

[cheebus]

Nigel, your post could not have come at a better time.

We have a highly customized Initial Deployment job that leverages lots of DOS comands (choice.com, find, etc).  Our PXE boot process has been working great for many years until we received a Latitude E6320. 

First we booted into PXE after receiving the laptop to deploy the base image.  We ESC'd out of the PXE boot process, ran RDeploy and were off to hunt for the appropriate drivers.  Having put together our driver package, we put the system into the build process to see how it would work.

We used RDeploy to begin with and kept getting "Out of Memory" errors immediately after rdeployt.exe started to roll the image. 

The Altiris DS console showed "Rdeploy: Internal error: assert failed." and occasionally we received an RDLog "Memory allocation failed.  Not enough conventional RAM for the ream mode disk i/o buffer."

Out of ideas, we swapped the RDeploy image for a Ghost image and received the error message which is the subject of this post "Could not allocate page table memory" which consequently led us here.

We could run ghost.exe and rdeploy after having exited the PXE boot process but if the Altiris DS was managing the RDeploy or Ghost image deployment the process would fail with memory errors.  The solution was simple and took 5 minutes.

We grabbed HIMEMX.EXE from the link in Nigel's post, dropped the file into our PXE configuration (we put it in the folder where config.sys is), edited config.sys (DEVICE=\HIMEMX.EXE), saved the configuration, restarted the build process with the E6320 and everything worked perfectly.

Thanks Nigel

[Migration User]

It may be because I am not familiar with this whole process that I need additional help..I tried the steps you suggested using HIMEMX.EXE and editing the config.sys but I seem to have five config.sys on the ghost server. Can you help me with step by step instructions on how to correctly do this. I would be so grateful as I am really in a bind.

Thank You so much

[Edward Tippelt]

Can you post the content of your config.sys file ?

[Migration User]

Where would I find the correct config.sys?  The exact location...Seem to be a few on the system

[Edward Tippelt]

Give us the one on the boot media you have created.

[Migration User]

DEVICE=\net\undi_drv.exe
DEVICE=\HIMEM.SYS
LASTDRIVE = Z
 

[Migration User]

DEVICE=HIMEMX.EXE
DEVICE=IFSHLP.SYS
DEVICE=PROTMAN.DOS
DEVICE=DIS_PKT.DOS
DEVICE=NDIS.DOS
DOS=HIGH
FILES=60
BUFFERS=30
STACKS=40,512
LASTDRIVE=Z
 

[Migration User]

DEVICE=\HIMEMX.EXE /MACHINE:17
DEVICE=\net\undi_drv.exe
LASTDRIVE = Z
 

[Edward Tippelt]

Have you tried this on more than one example of this machine?  It would be helpful to establish that this is not caused by a hardware fault.

If it is definitely not a hardware issue, then it is time for you to try WinPE instead of DOS for booting.