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?
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"?
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.
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.?
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).
I've been using FrameMaker since version 2.0. I can't remember when the freezing problem started. The freeze was only on the Windows version, never on the Mac or Solaris versions which I have also used extensively. I can't remember ever having the problem running Frame 5.5.6 on Windows 95 or 2000.
One of the Adobe troubleshooting sites also recommends starting Windows in safe mode and then starting the Adobe product, to see if it is conflicting with any other programs or utils that run in full mode. I tried this on my work machine. In Windows safe mode, FrameMaker refuses to even start, and give some error message about "catastrophic licensing failure" (their words). When running in Windows full mode I get the same freezing problem. This one is a Lenovo machine with 55 Gb of free disk space, 4 Gb RAM, Trend Micro anti-virus, Windows 7 Enterprise. I also tried a FrameMaker 10 trial installation on this machine - it, too, freezes at 60 minutes. I set the the autosave time to 3 minutes, and it froze at 3 minutes.
I did another test yesterday on my home Asus machine with at least 20 Gbytes free disk space, 500Mbytes RAM, Windows XP SP2, AVG anti-virus. This machine has never had any version FrameMaker installed on it. I installed Frame 7 and its PDF driver. I started FrameMaker up fresh with no plug-ins or configuration mods whatsoever. I simply created a new document in a sparkling new Frame installation and let it sit - at 60 minutes it froze. I think that pretty much rules out plug-ins and FM extensions. I then switched off my AVG anti-virus program and reduced the autosave time to 3 minutes - it froze at 3 minutes. Today on this machine I created a new user account with administrator privileges (the old account also had administrator privileges) and set the autosave for 2 minutes - and now it appears that Frame is not freezing! Perhaps we have narrowed down the problem enough to ask the question: Why doesn't the autosave feature like certain user accounts? I don't know if I have a workaround yet - changing user accounts on my work machine might be problematic.
500Mb of RAM in an XP system is a very tight fit. I suspect that your machine is thrashing to the paging file when FM is running. However, that may have nothing to do with your autosave issue. Perhaps something in the permissions for the Groups or the individual user is preventing FM from creating the autosave file. Have you checked at the system level to see if an autosave file has been created? Also, have you tried turning autosave off?
Like I said, the machine with only 500 Mb of RAM was only one of several FM test machines, testing with a very small document of 5 words or less; there was no disk thrashing involved.
Like I said, turning autosave off makes it freeze at 60 minutes.
When the freeze happens, it doesn't make an autosave file. (As a matter of fact, on the machines that are okay it doesn't make an autosave file either; maybe something is wrong with it.) It's almost as if it can't write to the folder, but it CAN write to the folder because I can save the file at will. Maybe it is trying to write a temporary file somewhere else.
It's occurred to me that I haven't tried changing the group settings in the FM preferences. Maybe that will turn up something. At least by reducing the autosave time it only takes two minutes to test each scenario, rather than 60 minutes.
You are not the only one suffering from this. I have a WinXP laptop with 2G memory. I have admin (full) permissions on the laptop. It has 10s of Gig available in TEMP and work areas, including networked drives. The problem occurs with or without anti-virus software running. The problem occurs right after reboot with everything except the minimal services and absolutely necessary startup software having run, or it occurs after the laptop has been up for weeks with tons of usage.
The problem happened with me on framemaker 7. Just recently I deleted everything for framemaker 7 and installed framemaker 8, with nothing extra, and it happened the first time I ran framemaker 8. I installed the necessary bits for PDF and it still occurs. I have done nothing else to framemaker 8 and for the past two months it keeps doing it. I know of no plug-ins or add-ons, but would appreciate any pointers on how to look for them if the audience insists they may be the problem.
More on the problem itself: Besides occurring at exactly 60 minutes, it occurs every 60 minutes. You can bring up the Print... dialog at 59 minutes, wait a couple minutes, close the dialog, and keep working for another 58 minutes until you have to open the dialog again. Otherwise, it will hang at 120 minutes, precisely.
And if you put the laptop to sleep at, say, 30 minutes after the last hang should have occurred (or since starting framemaker 8), it will hang 30 minutes after waking up the laptop. Thus, there is some timer inside of framemaker 8 that fires every 60 minutes and is not tied to wall-clock time.
If anyone has any suggestions, I am very interested. I am currently forced to use framemaker 8 for a specification document our company is creating. The hangs are incredibly painful, especially if I forget to save/quit before the hang occurs.
2 GB is pretty skinny to run FM on IMHO
You don't mention if you have the auto-save turned on or not. What about your power management settings on the laptop - have you tried the "always on" setting to see if that had any effect?
Actually, my laptop has 3G RAM (that'll learn me for not checking system properties before posting). Power management is always on; it's a workstation laptop. Anything else about my laptop's configuration you would like to know?
I did not mention the auto-save because the OP's description matches exactly what I see. I only mentioned additional behaviors not previously mentioned. To clarify, I default to auto-save off, and get the hangs at 60-minute intervals, and if I set auto-save to anything less than 60 minutes, I get the hang at intervals matching the auto-save setting.
Further information on the framemaker runaway: Note that the process is running away. It is not freezing or hanging, the hang is only a side effect of some code inside framemaker going into an endless loop and taking 100% of the processor.
After a reboot, I started framemaker without opening a document. I went into preferences and set auto-save on and to 2 minutes. Exactly 2 minutes (to the second) after I clicked on the preferences dialog's Set button, the runaway started.
With no .fm files open, framemaker just started, plenty of free RAM, and power management full throttle, framemaker still tries to do something at the auto-save interval that sends it into a tail-spin. Any suggestions?
This certainly is weird behaviour, however, since this is happening with older (i.e. non-supported) versions of FM, there's probably not much that Adobe will do about it. However, if you try the FM10 trial version and still see the same freeze/runaway happening, then it's something that they should repsond to.
Thank you for your time. I agree that it is weird and not to expect Adobe to do anything about it. I was here on the off chance someone among the vast audience might have worked around something similar before. If I have some free time after a few more weeks yet of having to use FM 8, I will try the FM 10 trial to satisfy my curiosity. Thanks again.
Very strange indeed. If we look at the available information, we can notice:
Therefore I would conclude:
I guess you must check further, whether there are any differences to working installations.
Not that I'd wish this fiasco on anybody, but I'm so glad that I'm not the only one with the problem. Maybe Adobe will look at it now. The problem still exists in the FM 10.0.2 patch, however, so don't expect me to recommend FM to anyone else - I'd be too embarrassed.
Thanks, rhbeers, for the printer pop-up workaround. Letting the printer pop-up sit for a minute is certainly preferable to shutting down all my documents and FM and then restarting.
Just to re-iterate another workaround that appears to work: If you create a new Windows user account AFTER installing FM, that user account does not exhibit the problem. That is, if you run FM while logged in as the new user, FM does not freeze.
I know what you mean, Tigdave. After searching many times across many months after many FM hangs, stumbling upon your thread warmed my FM-frozen heart. (Suffering FM alone is far worse than sharing in our FM suffering?)
Your "create a new Windows user account" workaround worked for me. Thank you for sharing that discovery. Although most of my FM work is on protected documents and cannot use the new account, using the new account and having an autosaving framemaker survive for a few hours of how-to document writing was quite refreshing. Cheers!
@Tigdave & @rhbeers - you never say if you've have Adobe Tech support ever look at what's going on. Perhaps that might be a better route to take. The fact that creating a new user account seems to fix the issue & that nobody else in the FM community seems to be experiencing this issue leads me to believe that there's something restricted or damaged in the account profile.
@rhbeers - I don't get what a "protected" document is & why you can't work on it. Are you in some sort of restricted environment like government or military? That may play a part in your FM's peculiar behaviour.
We use rights management software for classified documents. One way to control access to these documents is by setting which users can edit them (and which users can change these settings). I cannot edit those with the other account.
I have not attempted contacting Adobe Tech support because folks said it was not worth trying for FM 8. Please provide a contact link or means if you disagree.
I wonder if this "rights management software" is the cause of your troubles somehow. BTW - how could your IT set you up with another profile & not give you the rights you need to work on things? Seems counter-productive...
Anyway, if you never contact Adobe Support, then they'll never know that there's an issue - these are strictly user-to-user forums & while Adobe staff stick their head in once in a while, you can't count on them paying any attention to issues raised here.
I had this stored from another forum thread when they announced a revamp to support:
Contact Adobe Support for Adobe Captivate, Adobe RoboHelp, Adobe FrameMaker, Adobe Tech Comm. Suite & Adobe E-Learning Suite by dialing :
Via Phone: USA 1-800-833-6687 Option 2 > Option 5 > Option 3
Via Email: mailto:TCS.SUPPORT@adobe.com
You can dial this number for any customer service and technical question.
You can also use the bug reporter here: https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform
The rights management software is not the cause because it is not installed yet. It will be a New Years gift from IT. Forgive me for not using future tense when talking about this limitation.
The workaround requires only a new local account. No IT ergs were wasted in the testing of Tigdave's workaround. Their productivity remains as high as ever.
Thank you for the contact information. I will try it out.
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.
> 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 ...
You may want to report that fix to Adobe at the bug report form. That
way, they may be able to fix it in future versions, or at least know how
to help others that report the problem. The bug report form is here:
Great find, tigdave! It fixes the problem on my system. Agreed that it needs to be reported. I am going to report it for the version I have, but it is only 8.0p277. If you have a version 10 to report on too, maybe we can draw more attention to it.
Thank you for finding this workaround. That bug cost me quite a bit of work the past three weeks while trying to meet a deadline.
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.
This didn't work for me but I am experimenting with the work around from http://forums.adobe.com/message/3458994 in which DWM is disabled. I would get the "not responding" message at the "Automatic Save every" time if set, or 60 minutes whichever was soonest.
Since disabling DWM I have exceeded the Automatic Save time. I have been using this for a couple of days now and there have been no problems. I do encourage you to gice it a try, DWM can be enabled again, so you really have nothing to lose. BTW. Yowill either need to stop the DWM service every time you use FrameMake or disable the service!
Europe, Middle East and Africa