Skip to main content
Inspiring
October 12, 2011
Answered

FrameMaker freezes after 60 minutes

  • October 12, 2011
  • 4 replies
  • 8235 views

Over the years I have had insurmountable problems with FrameMaker version 5.5.6, 7, and 8 freezing exactly 60 minutes after FrameMaker startup on certain machines, including Dell, Lenovo and Asus hardware, and Windows XP and Windows 7 operating systems. At the 60 minute mark exactly, the FrameMaker process hammers the CPU up to 50% and stays there, and the program is then frozen ( " not responding " ). The rest of the system is still functioning. I (and several system administrators) have spent many days trying everything in the book, to no avail. I never found the source of the problem; I gave up and avoided it by using random Windows machines that don't exhibit the problem, and by using FrameMaker on Solaris. I am working at home now (actually, *trying* to work at home); I can no longer avoid the problem, and the lock-ups make FrameMaker practically unusable.

Although I appreciate any suggestions, each one takes 60 minutes to test (obviously) and I have tried so many that I feel like I can't try any more of them without some kind of a lead. To that end, I have a direct question to the Adobe FrameMaker programmers:

WHAT IS FRAMEMAKER DOING AT THE 60 MINUTE MARK?

This topic has been closed for replies.
Correct answer Tigdave

I think I have finally found the offending parameter that makes all versions of Frame (including 10) lock up at the autosave time or 60 minutes, whichever is sooner. It started happening to me again (even when logged as the new user) just after I went into the Windows Control Panel and adjusted the keyboard settings. It turns out that if I set the Cursor blink rate to None then I get the freezing problem. If I set the blink rate to any other setting then Frame doesn't freeze.

I have checked my other broken machines as far as possible, and this seems to be the issue, and I can fix them just by setting the cursor blink rate to any value other than None. I'd be interested to know if this fixes your problem, too, rhbeers.

4 replies

TigdaveAuthor
Inspiring
February 6, 2012

I've reported the bug now, as I feel it is the first time I've been able to isolate the problem enough that the Adobe engineers can reproduce it and work on it. I've also marked it as answered (boy did that feel good) so that people know that there is now a workaround, as it can be a real show-stopper.

Arnis Gubins
Inspiring
February 7, 2012

FYI, I can confirm that Adobe's engineers have reproduced the bug.

TigdaveAuthorCorrect answer
Inspiring
February 6, 2012

I think I have finally found the offending parameter that makes all versions of Frame (including 10) lock up at the autosave time or 60 minutes, whichever is sooner. It started happening to me again (even when logged as the new user) just after I went into the Windows Control Panel and adjusted the keyboard settings. It turns out that if I set the Cursor blink rate to None then I get the freezing problem. If I set the blink rate to any other setting then Frame doesn't freeze.

I have checked my other broken machines as far as possible, and this seems to be the issue, and I can fix them just by setting the cursor blink rate to any value other than None. I'd be interested to know if this fixes your problem, too, rhbeers.

Bob_Niland
Community Expert
Community Expert
February 6, 2012

> It turns out that if I set the Cursor blink rate to None then I get the freezing problem.

Now that you've isolated it, I see that there are other applications that are sensitive to that.

Apparently, Windows internally codes blink rate "none" as -1, rather than 0. Applications which use a "non-zero" blink rate value as an increment to determine the next blink time, come up with "already passed" every time, when the offset is -1. They can loop continuously as a result, which may be as good as locked-up.

Now, as to why it's taking an hour for Frame to get tripped up ...

Inspiring
October 12, 2011

Have you tried temporarily uninstalling all plugins/add-ons/startup

scripts to see if any of them might be causing a conflict?

Bob_Niland
Community Expert
Community Expert
October 12, 2011

Have you tried temporarily uninstalling all plugins/add-ons/startup

scripts to see if any of them might be causing a conflict?

Concur. This sounds like a memory leak in a plug-in.

I've been using Frame since 3.1, on every version of Windows, and two different Unix systems, and have never seen a 60 minute implosion.

To rule out plug-ins, I'd try installing the trial version of FM10 on a machine on which I'd never had an account before, and which I.T. has never messed with (i.e. installed some standard enterprise environment, which might include who knows what FM extensions).

Michael_Müller-Hillebrand
Legend
October 12, 2011

Dave,

Have you heard of anyone else having the same issue?

Can you avoid the problem by closing FrameMaker after 59 minutes and restarting the application?

What is different with the "random machines that don’t exhibit the problem"?

- Michael

TigdaveAuthor
Inspiring
October 12, 2011

I've not heard of anyone else having this problem, which utterly astonishes me given that about half of the machines I have tried to install FrameMaker on over the years have exhibited the problem. I have been unable to isolate the differences in machines that make one machine have the problem and another one not.

If I close Frame at 59 minutes I can restart it and use it for another 59 minutes. As a matter of fact, I have had to resort to a 57-minute repeating countdown alarm on my wristwatch so I can save and then close. I must say that when the alarm goes off and I've got a head full of ideas, screen captures, and cross-references that I am trying to commit to three or more open books in a 50-book, 12000-page multilingual manual set, the urge to swear a very loud blue streak is overwhelming, as you can imagine. My wife can hear me at the other end of the house. No one should have to work like this.

A further development: It might be releated to the autosave function. If I set the autosave to 10 minutes, it freezes at 10 minutes. Set the autosave to 30 minutes - it freezes at 30 minutes. Set the autosave to 60 minutes - it freezes at 60 minutes. Set autosave to 120 minutes (the maximum value) - it freezes at 60 minutes. Turn the autosave off - it freezes at 60 minutes. The most work I can get out of it is 60 minutes.

When the time comes to generate a set of PDF files of my large manual set, I currently use the scripting in Solaris FrameMaker 8, and it takes about eight hours to run unattended. I'd like to migrate to FrameMaker 10 to do the same thing (now that Windows FrameMaker has scripting), but there's no point if Frame 10 only has an attention span of an hour.

Arnis Gubins
Inspiring
October 12, 2011

The tie-in to your autosave setting seems wierd. I've been using various versions of FM for years on many different wintel plaforms, have autosave set to 5 minutes, often use it all day (& night with automation) and have never seen a freeze like you describe. As Mike suggests, if you have any plug-ins or scripts installed, try uninstalling them, set the autosave to a low value and see what happens.

Also, you don't mentione what sort of hardware resources you have on the platforms where this happens. How much RAM, how much free space in the TEMP folders, how much free space in your working folders, do you have full permissions in your environments, do you have aggressive anti-virus apps that might be grabbing the auto-save, etc.?