There is not enough free memory to load the entire file

[_WebHubbleTelescope_]

I saw an older reference to this error in a previous post which apparently got resolved, but didn't explain precisely how it got resolved:
Michael Kitzmiller, "There is not enough free memory to load the entire file" #, 27 Jul 2007 5:23 am

I presume that one answer is to rebuild the document from scratch, changing imported images to referenced images. But I want to recover the file as I put hours of work into it and expected that anything I can save that I also should be able to read back in. I will certainly change to referenced images, but I have to be able to open it first.

thank you

[_Dennis_Brunnenmeyer_]

Web...

It might help you if you told them what OS and FM Version you're working with, and how much RAM, free HDD space and paging file allocation you have available.

Dennis...

[_WebHubbleTelescope_]

Dennis,
Exactly the same configuration, give or take, as in the older post on this topic:
Michael Kitzmiller, "There is not enough free memory to load the entire file" #, 27 Jul 2007 5:23 am
That one had the same size of document as mine, which was under the RAM available.

My XP page file setting has 3 options: custom set to 1532 MB, system managed size, and a no paging file option. I used the first option, but moving this up to double doesn't help. The maximum is 4096 MB it appears.

Strange that FM knows right away upon starting the load that the file is too big. Almost as if there is some bad magic in the header that it uses to allocate or reserve memory with.

Also it looks like FM hits a peak memory usage during initial file load that is 6x of steady state usage. I have another file that I can load that is 10% smaller than the one that doesn't load, but this one hits the same peak usage. The peak usage happens right away and is the same for both files. This looks like a reserved memory that only gets used on commit.

It would be interesting to know if these limitations are from a design that is carried forward from old versions of FM, back when memory was more a premium. I last used FM to write a book more than 10 years ago, and made the mistake this time in trying to aggregate too much content into one file before splitting into the book/multiple document arrangement. I definitely won't make that mistake again.

[_Dennis_Brunnenmeyer_]

Web...

Here is a smattering of ideas.

Do you have ample unused HDD space? If not, defrag it, although in myu experience, this hardly makes a difference. Check your TEMP/TMP folders and clean them out. Consider downloading cCleaner and running it. Do everything you can to make ample room on your HDD and in places like your TEMP folders. If your HDD is congested, temporarily remove big but relatively unimportant applications and move data elsewhere for a while.

Even with 4GB of RAM, Frame can only use somewhere between 2.7 - 3.2 GB of it under the very best of conditions, and that includes the application as well as the files. Unpacking image files can consume considerably more space than it takes to store them. For example, a 1024 x 768 color image requires more than 3.1MB to describe it as a 32-bit color image, yet when stored in JPEG format, it can be as small as 50kB, a compression of 65:1. Of course, it's not reasonable to assume that your document is comprised entirely of such highly-compressed images, but in the unachievable extreme, it would take 980MB to simultaneously open 15MB worth of those kind of files. The point here is to not fall into the trap of thinking a 15MB file comprising a lot of images needs little more than 15MB of RAM.

Make sure ALL other applications are closed when trying to open your file...Outlook, IE or FireFox, Anti-Virus and Spyware apps, Word, etc.

Consider sending a copy of the file to someone else to see if they can open it for you and delete some of the images before resaving it. If you have a backup copy, rename your current file and restore the backup. Maybe your working copy is corrupt. Who knows? Anything is probably worth trying as long as you have a save copy stored somewhere.

Dennis...

[_david1]

AFAIK, Microsoft recommends that, for WinXP, you should always set that page file size dialog to "System managed size"
(Setting a static page file size was sometimes helpful in Win9x, but not for WinXP.) XP should be able to dynamically resize the pagefile to make it as big as required to open anything...

Another useful utility is www.sysinternals.com (now brought back into the Microsoft fold) "PageDefragment", which can defrag the green bits on your hard drive that Disk Defragmenter can't reach ;-)

[_WebHubbleTelescope_]

I am going through a disk defrag right now. The number of unmovable green bits doesn't look too high so I am using the regular disk defragger.

I tried the "System Managed Size" for paging and that didn't help.

I am leaning toward it being a corrupt file (a bad file size in the header maybe?) and taking the hit.

Funny that after all this time, FM is still the only good document engineering tool out there and even with this setback, I don't think I would even consider using anything else. Other people look at us as an odd bunch, but they just do not understand :)

Thanks for the help.

[Guest]

Web, another possibility -- there's a setting in FM to turn off display of graphics (could be in preferences, could be buried in maker.ini, I forget where just now). Anyhow, maybe that would help conserve resources enough to let the doc load.

[_sherman_watstein_]

Sheila-To turn off the view graphics, you must first be able to open the file. Looked through the maker.ini file and I don't see anything to turn off the graphic display. Maybe some one else may.

WebHubbleTelescope- Is your document one file or files? If you have individual files, have you tried opening one at a time?

Because you embedded your graphics there is a way to still use the embedded graphics without starting over, but it require some work and you must be able to open the file. Start with the first graphic in the file open and click on the graphic. Use the Ctrl+c to copy it to the clip board. open paint or any other graphic program you use, and do a Ctrl+v to paste the graphics in your grapic program. Do as Save As or Export and save to either a Jpeg, BMP or png in an art folder you must create with the documents in question. Go back to your open FrameMaker document, delete the embedded graphic within the frame, the do a File>import. Locate the new file and click Import (make sure you have Import by Reference radio button selected. Select the dpi and click Set. Resize the imported grapic as needed. You must repeat these procedures for all graphics in your file. Make sure you do a save on a regular bases till you finish. Close the file and reopen, you should no longer have a problem with this one being too big.

[Guest]

Good catch, Sherman, you're right, graphic display on/off is a document property (for the record, in MIF, it's DGraphicsOff=Y/N)

[_WebHubbleTelescope_]

Thanks everyone, I have tried all the possibilities including a disk defrag and closing all other active programs. The fact that the FM document loader knows that the file is too big within a tenth of a second after opening tells me that the magic header might have some enormous value for reported file size. You would think that it would struggle to try to open it and use disk cache if possible. Yet, it gives up almost immediately. This has to be a corrupt file. I will go back to an older backup file and start over.

[_Thomas_Michanek_]

I'm not sure anyone has mentioned this:
Start FM and open any small FM file that doesn't give you any problems.
Then type "Esc o shift+H" (press and release Esc, press and release
lower-case o, press and release upper-case H).
Then select your troublesome file and see if it can be opened.
If it can, you MUST immediately save it to another filename!

This is the (almost) undocumented "Open Heroic" command that tries
to open files in a different manner than normal. It can only be
invoked if another file is already open in FM.

--
/Thomas Michanek

[_WebHubbleTelescope_]

Thanks, but "Esc o shift+H" did not work either.

[_sherman_watstein_]

How large is this file ?

Last option is to pay Adobe for tech support, they just may have a work around for a file that is as large as you say.

[DrDaveJ]

I hope this Forum is still being seen.
I was just presented this issue and have never seen it before.

Other files, as much as four times larger than the trouble one, open just fine.
Someone mentioned the idea that the file is loaded with embedded graphics. That is known to be true in this case.
Since the graphics are not unusually smaller than any other graphics - such as the ones in the much larger file that works - I am also wondering why the trouble file appears to be a small size. It's corrupted? The header data mentioned by WebHubble is at issue? Can we hack that in hopes of tricking FM into opening it?

By the way, the large file that works has many graphics, but they are import by reference. So, there you go.

Regards,
Dave

[Guest]

Yup, we're mostly still here; it's the summer doldrums.

Just grasping at straws, but maybe the file wasn't saved 100% correctly last time it was written to disk, e.g. maybe there was some slight video memory glitch that wasn't enough to crash FM but it was enough to trash the written file.

I wonder if there's any chance that one of the batch file apps might open it and save it as MIF without hitting "the wall" with whatever's gone wrong.

You might check out DZBatcher at http://www.datazone.com (don't pay too much attention to the somewhat dire-sounding warnings, but ALWAYS test only when backup copies of the problem file are safely stowed, of course) or doBatch or OmSys's RunFM, links found here in the helpful Leximation tool list: http://www.leximation.com/framemaker_automation.php

[DrDaveJ]

Sheila, thanks for responding! Unfortunately, the Writer that owns this file is not available for a week or more now. I sent an email asking for the following info, in case any of it is either known, or helps at all.
1) How many Graphics are in the file? 5 or 7? More than 10?
2) How many pages?
3) Does the file contain graphics that are 'copy into document' instead of 'import by reference'?
4) Does the file open on SOME pc's but not others?
5) What Frame Version is the file?
6) Who is the Building Tech working on this?

A question for you guys out here:
Is there a way to look into the "header" data for this file? (I think I got this idea from a thread here, but cannot find it again to see if there is an answer).
My thinking is, I could hack that file, change a data point somewhere, then FM will open it again.

btw: We are running WinXP Pro (SP2), and FM 7.0p579.

Thanks.
Dave

[DrDaveJ]

Just a quick note to say this issue is neither dead nor solved. I am still waiting for my Customer to return and be available for troubleshooting.
Dave

[_WebHubbleTelescope_]

I agree. I started over from scratch and am very careful to only use references to image files, and never try to load an image (i.e. copy) directly into the document. I also use the book feature and keep file sizes small. However, I still cringe when I save/close and then re-open a FM file, hoping not to see the dreaded error message.