FrameMaker loses formatting during crashes

Report · Apr 01, 2011

I recently upgraded from FrameMaker 8 to 10, and I have noticed that Frame 10 has a charming habit of losing formatting when it crashes. So for example, if a paragraph tag is supposed to be bold, all text with that tag will no longer be bolded after the crash. The paragraphs are still tagged correctly, but I have to go back and apply the "Default Font" character tag to each paragraph with mangled formatting. It's incredibly aggravating, and I usually just revert to an older version of the document (and copy any new or changed material over), but obviously this is inefficent and will be error-prone in the long run. Just out of curiosity, has anyone seen this bad behavior?

I don't know if it matters, but I am using Windows XP Professional 32-bit, and all of my files were created in Frame 8.

Report · Apr 01, 2011

I would expect that to happen because unless you saved just before the crash, FM has no way of knowing that there have been changes made when it craps out. The bigger question is what's causing your crashing? Have you tried to figure that part out?

Report · Apr 01, 2011

No, you've misunderstood. The crash is changing the documents. So, for example, everything in the document is formatted and displaying correctly. The file has been saved. The file has always been formatted correctly through many weeks' worth of editing and saving. There have been no problems. Then the crash occurs and, when I reopen the document, it has been altered -- lots of paragraph tags have lot their bolding (and possibly other changes, though the bolding is the most obvious). This never happened in FrameMaker 8.

I do not know what is causing the crashes, though I think it is related to saving as a PDF. It's not happening with alarming frequency, but the side effect of ruining the formatting makes it a much bigger problem than it would be otherwise.

Report · Apr 01, 2011

... Frame 10 has a charming habit of losing formatting when it crashes.

Frame has always had that "feature".

The only thing that is usually safe to open after a crash is your previously saved .fm file, or a .backup file.

If Frame managed to create a .recover, open it separately, and only use it copy back the latest local edits.

Go no longer between saves than you care to re-create. Be advised that Frame can sometime crash DURING save. Check the timestamp on the .fm file in question to see if it is now questionable.

I primarily use FM7.1 on Unix, and it crashes a lot, due apparently to some degenerate intersection of our odd page layout and massively networked document files.

Sometimes I get a .recover, usually not.
Sometimes I get a crash message on the console (usually 7103).
Sometimes the crash crashes, so we routinely have a non-writeable "core" directory in every document dir, to prevent time-consuming creation of useless huge core dump files.
Sometimes Frame just winks out without a trace.

In addition to managing any damage to the .fm file, it is not uncommon for the crash to screw up the page numbering declared in the .book file for all .fm files in the book (open or not), that are after the .fm file that crashed. Easy to fix, but wierd.

Each document directory here has, among other subdirectories, one which is used to store working/backup/recover files after crashes.

Because Frame crashes can be due to latent corruption in the .fm file, you can be editing a book and discover way late that major sections have turned to garbage. Having archives helps.

Report · Apr 01, 2011

"Go no longer between saves than you care to re-create."

Again, the problem has absolutely nothing to do with material added since the last save. I'm talking about formatting that has existed for quite some time. These are the things that are now being lost.

"Frame has always had that 'feature'."

I have been using FrameMaker for 10 years and have never seen this. My experience has been with Frame 5.5, 7, 7.2 and 8 -- and I have not previously noticed corrupted formatting as the result of a crash except for the color being lost from conditional text definitions. But that was far more minor because the correct conditional text definition could be imported from another document. With what I am seeing now, the paragraph tags are still defined correctly (so there is no point in importing them). But it's as if someone went through the whole document and did an override of massive numbers of headings and phrases, so that the standard paragraph-tag definition is not being used -- with the additional weird caveat that when you highlight the text and look at the name of the tag, FrameMaker does not add an asterisk to indicate a deviation. This has also happened to several character tags, though with the character tags FrameMaker does use an asterisk to show a deviation.

"In addition to managing any damage to the .fm file, it is not uncommon for the crash to screw up the page numbering declared in the .book file for all .fm files in the book (open or not), that are after the .fm file that crashed. Easy to fix, but wierd."

Interesting, I have not seen this.

Report · Apr 01, 2011

r0y,

Again, the problem has absolutely nothing to do with material added since the last save. I'm talking about formatting that has existed for quite some time. These are the things that are now being lost.

I believe Error7103's point is that when a crash occurs, you should have no expectation that the .recover file should be OK, no matter how long the formatting has been there. During a crash, anything can happen. To say that is is the crash that is changing the formatting is .... well.... to be expected....because a crash is a crash and anything can happen.

In my experience (fm9), the recover files are usually OK, but there is no guarantee. So, in stead of worrying about the recover file's not being good, simply save often and open only the most recent saved file and go from there.

Van

Report · Apr 01, 2011

Again, the problem has absolutely nothing to do with material added since the last save. I'm talking about formatting that has existed for quite some time. These are the things that are now being lost.

I didn't mean to imply that. Indeed, the new material is usually well preserved in a .recover file. But entire paragraphs dozens of pages laters are now reduced to a %^&*_-. Go to your backup. Re-apply the current edits from the .recover.

I've also seen Frame crash while doing absolutely nothing - while sitting there reading something in another window.

Chances are Frame was not actually idle, had just initiated an auto-save, and failed.

Report · Apr 03, 2011

Go to your backup. Re-apply the current edits from the .recover.

I might add that when a crash occurs, do not necessarily just re-open the .fm file, as one of the first things that happens is your .backup.fm gets overwritten, and it may be your only hope.

Taking the options of "open recover" or "open autosave" instead is slightly less dangerous, as your working file name is now "auto.fm" or "recover.fm", so the original ".fm" and ."backup.fm" are left as is unless you save-as them.

On crash, I routinely make copies of all .fm and .book files that were open, and all .backup, .auto and .recover.

Fortunately, it appears that Frame does saves as save-as-temp : delete-original : rename-temp. So, if a Save crashes, the .fm you were trying to save as usually is left as it was after the previous successful save.

______

Good thing disk space is cheap ...

Report · Apr 03, 2011

rb3, some troubleshooting questions.

1. is the FM10 install on a new/different computer or was an O/S upgrade or Service Pack done to the system from when you were using FM8?

2. It would be interesting to examine the MIF file of a problem file, specifically at a section where the formatting has been lost. I'm wondering if there is any distinction to be found between the pre-existing formatting (e.g. from the MIF of a file that hadn't crashed) vs. that of the crashed file, specifically where the formerly good formatting is lost.

The best tool for looking at MIF is the excellent freebie MIFBrowse, by Graham Wideman, available here:

http://www.wideman-one.com/gw/tech/framemaker/index.htm

Even through it hasn't been updated for eons, it still works perfectly.

What I'm wondering is whether there might be some difference in the FM8 vs FM10 MIF codes. Or whether the crash is blasting the paragraph tags with some font override statements.

3. What fonts are you using in the problem docs? Specific fonts and type, TT, OT, PS? And what printer do you have set as the default for FrameMaker, do you use other excellent freebie SetPrint, from http://www.sundorne.com to control what printer FM sees as the default, independent of what the O/S has as the system default?

4. After you have a crash, do you reboot your system or just open FM again?

5. Can you look in the XP Control Panel for the Event Viewer, to see if there are any errors written from the crash.

6. Look at the FM console file, console.txt, usually located in the FM install directory in XP, to see whether there are any errors written there (if there is a chunk of hundreds of numbers don't post them on here, they're only intelligible for Adobe support, not us mere user forum folks)

EDIT:

7. What specifically are you doing when FM crashes, can you identify what actions lead up to the crash?

Sheila

Message was edited by: Sheila Carlisle

Report · Apr 04, 2011

Thank you all for the responses.

Van, just to clarify, when this happens, Frame is actually not creating a .recover file. The file that is corrupted is the saved .fm file. I do daily backups to a source control system, so that's helpful, but of course it's not a perfect solution because those archives can be up to a day old.

Error7103, thanks for the tip about not reopening the .fm file and overwriting the .backup.fm -- I have been guilty of this. Next time this happens, I'll definitely copy everything before opening anything.

Sheila,

1. Frame 10 is installed on the same server as Frame 8 with the same OS and service pack.

2. I haven't looked at the MIF file yet -- I will try that. Thank for the tip on the freebie.

3. The fonts in question are Arial and Arial bold. The are TrueType fonts. I am user Distiller X.

4. I do not reboot after crashes. Should I?

5. I did not check the Event Viewer on any of the occasions when this happened. Looking now, I do see some Frame errors, including a few hanging errors, which has been another problem I've encountered since upgrading. Because I don't recall the exact times and days of the incidents, it is difficult to tell now which errors might be specifically linked to this, but next time I will look right away.

6. I've just searched my FrameMaker 10 folder, then my entire Adobe folder, and according to Windows there is no file with the word "Console" in the name except for 21console.jsx. In my Frame 8 folder, I do find several files whose names begin "FrameLog_date," which have contents similar to what you describe, but there are no current files like this -- none in my Frame 10 folder.

7. Because the crashes have happened unexpectedly, and they did not occur close together (ie., they've been spread out over a few weeks, not a few days), I don't have a perfect recollection of what I was doing prior to them happening. My general sense is that they're related to the creation of PDFs. Also, I know there was at least one occasion where FrameMaker was hanging for more than 20 minutes, and I ended the program. I realize that sounds like a bad thing to do, but the program was completely unresponsive and I didn't see an alternative.

Roy

Report · Apr 04, 2011

Why have you got FM installed on a server? Not a normal procedure AFAIK.

Report · Apr 04, 2011

Sorry -- I misspoke. It's installed on a PC.

Report · Apr 04, 2011

1. Same system for FM8 and 10 -- but what OS & SP? -- always useful for us to know when trying to track down "issues".

4. Reboot after crashes. I always reboot after crashes, to my way of thinking there's just too much chance of something critical to operation getting clobbered during the crash.

5. Event viewer. I would also check events just prior to FM's crash to see whether there are any that seem "suspiciously close". For example, do you also use any Office 2010 apps? If so, there's a known crash in Word and Outlook that involves a file called "usp10.dll" which is the Uniscribe (unicode) font display module that you might see in the Event log. There's some sort of incompatibility with Adobe PS fonts, very often with Helvetica but also other PS fonts.

AFAIK FM doesn't apparently use usp10.dll, but seeing as font rendering is so essential to FM it wouldn't surprise me if the crash is also affecting something else font-related that FM does rely on -- e.g. I hear echoes of the still-an-issue MS hotfix for XP, for text missing in PDFs,

Adobe blog: Hotfix for FrameMaker

In theory there's a hotfix issued Jan 21/2011 for the usp10.dll issue, but I have yet to find any corroboration that the issue is indeed fixed.

http://support.microsoft.com/kb/2119612

Error message opening a document in Word 2010: "Microsoft Office Word has encountered a problem and needs to close" USP10.DLL

Oh, and even if you are not using Helvetica or other PS fonts in the documents intentionally, if the docs could possibly have been edited by other folks on other systems or other versions of FM, or where a different printer was selected as the default, or content was copied in from another FM file, then Helvetica could still be in the files, e.g. in the titles on reference pages, or in a table definition (even if there isn't an instance of that table format in the actual doc).

6. consfile.txt (not "console") -- ooops, apologies for sending you on a wild goose chase, my bad.

7. possibly crashes are related to creating PDFs. How do you create PDFs, do you typically use Save As, or do you print to a PS file and then distill? The distinction has often been critical in previous FM versions.

ick, removed big formatting: Sheila Carlisle

Report · Apr 04, 2011

Thanks, Sheila.

1. I'm using Windows XP Pro, Service Pack 3.

5. From now on, I will reboot after a crash -- thanks for the tip.

With Event Viewer, I will just have to monitor this more closely in the future. However, looking now at events from last Friday, when I had one of these incidents, I don't see anything too suspicious listed.

I do use Outlook, and it does crash occasionally. I do not use Word. I just searched the Event Viewer logs for usp10.dll and did not find anything, but I will remember that for the future. Regardless, thanks for the tip on that hotfix -- I don't know if it will have any effect on this particular issue, but it sounds like a good thing to install just in case.

6. I found the consfile.txt, but it is empty -- don't know if that's normal or not. It has a timestamp of last Friday afternoon (I was using FrameMaker then and have also been using it today, though I have not closed Frame today).

7. To create PDFs, I just do a "Save as."

Roy

Report · Apr 04, 2011

>> Look at the FM console file, console.txt

It's actually consfile.txt. Oddly, it appears that FM no longer writes that file, beginning with FM9.

Report · Apr 04, 2011

Ah, a nugget for us all, then, it's a preference:

http://www.i-frame.itl.info/en/feature-description/free-scripts/open-fm-console.html

Report · Apr 04, 2011

I have the box ticked in FM9 (File> Preferences> General to show file

translations errors. The console does display with entries. However,

consfile.txt does not exist. It appears that writing it to disk

disappeared with the new interface in FM9. Does anyone see it differently?

Ah, a nugget for us all, then, it's a preference:

http://www.i-frame.itl.info/en/feature-description/free-scripts/open-fm-console.html

>

Report · Apr 04, 2011

In FM9 on XP mine is located here:

C:\Documents and Settings\Administrator\Application Data\Adobe\FrameMaker\9

just opening FM and closing it updates the date of consfile.txt, so it's still being written by FM.

Report · Apr 04, 2011

Well, son of a gun. On Windows 7, I found it here:

<C:\Users\[Username]\AppData\Roaming\Adobe\FrameMaker\9\consfile.txt>.

So it is still being written, just not in the old location.