Frame 2015 crashing repeatedly

[susan_colm]

I just updated to patch #2 based on other crash-related posts, but I'm still crashing. I've got a landscaped file, book minimized to the left, one file open, and a large referenced Adobe Illustrator file almost filling the page. The size of the AI file is 1.65 MB. Frame seems to have trouble repainting the page. Very slow. The crash comes when I try to copy and paste a small text box from one spot to another. Frame hangs, I see "not responding" in the title bar, and then it crashes closed. I looked for the %appdata% crash log file referenced in another discussion but can't find it. How can I fix/avoid this?

Susan Colm

Hypertherm Inc.

[Jeff_Coatsworth]

It’s a hidden folder – you’ll need to turn on the View hidden files option in Explorer

[susan_colm]

I was aware of that, so I went into Tools > Folder Options > View tab and made sure that "Show hidden files, folders, and drives" is selected, but I still don't see the %appdata% folder. What am I doing wrong?

[Jeff_Coatsworth]

Depending on your FM version & O/S, the path is C:\Users\user_name\AppData\Roaming\Adobe\FrameMaker\12

[susan_colm]

Found it. Thanks. How can I send you the .txt files (there are 8 just from today)?

[Jeff_Coatsworth]

E-mail them to the engineers at fmerror@adobe.com<mailto:fmerror@adobe.com> – don’t expect a response unless they find something unusual about your error. Meanwhile, what are you doing that’s causing the error? Are you all patched up – there’s been several updates since FM2015 came out.

[susan_colm]

I've applied patch #2, since I saw others in this community reporting crashes and that patch was supposed to help. I'm at version 13.0.0.433. Frame 2015. Windows 7 Enterprise (v6.1 - Build 7601: SP1).

[Jeff_Coatsworth]

And is it crashing on a particular document or all docs? If you create a new one from the FM templates, does it crash?

[susan_colm]

I've got a landscaped file, book minimized to the left, one file open, and a referenced Adobe Illustrator file almost filling the page. The size of the AI file is 1.65 MB. Frame seems to have trouble repainting the page, for example if I select the AI and try to move it within its anchored frame. Very slow. The crash comes when I try to copy and paste a small text box from one spot to another. Frame hangs, I see "not responding" in the title bar, and then it crashes closed. I've discovered that if I'm careful not to select the AI file as well as the text box on top of the AI file, I can reduce the number of crashes. Other apps I have open include Outlook, Internet Explorer, OneNote, Acrobat, Notepad, and Adobe Illustrator. I don't typically have memory issues unless I also have SolidWorks open. But it almost seems like I'm having memory issues.

I'm working over a network. But I have 350 GB of free space/RAM on my hard drive. 64-bit.

[Arnis_Gubins]

Did you import the AI file as a native file or did you save it in another format first? FM only imports native AI by accident, as the internal structure is similar to PDF but also contains much more information that is not defined for a true PDF. FM tries to convert  all imported PDFs to an EPS format for internal use. You could be hitting something in one of these conversion steps. Try creating either an EPS or a PDF from Illustrator and import that by reference instead.

[susan_colm]

Native AI file.

This would be news to us, that we shouldn't import AI files by reference. It's all we do and have been for years with no problems. I really can't believe that's the problem.

As I said, if I'm careful to make sure I haven't inadvertently selected the AI file along with the text box before copying and pasting, I don't crash. It's when I select the AI and the text file together by mistake, copy, and try to paste that I crash. But the AI file is only 1.65 MB, not enough to use up my memory and crash, right?

I emailed the .txt crash log files to fmerror@adobe.com. Did those files provide any insight?

[Jeff_Coatsworth]

You’re talking to a user-to-user forum here; nobody but Adobe engineers can decipher those log files.

[Arnis_Gubins]

Just because you can, doesn't always mean you should...

As I said, the internal format of AI native files and an ISO-standard PDF are close, but they are not the same. See responses from Dov Isaacs (Adobe staff) on this topic for more details: Re: Graphic Error  and Re: FM 12.0.3 patch released

However, that being said, it doesn't sound like this is the root of your problem. Is the AI file on a networked drive or local? Sometimes, overly aggressive anti-virus software messes with FM when accessing networked files and can trip it up.

Have you tried turning off the graphic displays (<esc> v v)? This speeds up FM operation in a graphics intensive document. If this makes things more stable, then it might possibly be a memory related issue if you have a number of applications open.

It's also possible that it's a peculiar bug. There were issues copy/paste issues with the changes during the prior pre-release program, so not all of the glitches may have been identified.

[susan_colm]

I'll try the <esc> v v method and see what happens, thanks.

[susan_colm]

I can't use <esc> v v because then I can't see the graphic to which I am attaching text boxes (with callout text inside them).

That said, I kept Windows Task Manager > Performance tab open while I recreated the crash, and there was no impact on CPU Usage or Memory during the event.

I recreated the crash by simply selecting the graphic and then attempting to paste a text box while the graphic was selected.

[Arnis_Gubins]

It wasn't clear what you were doing with the graphic and text frame. You can't "paste" a text frame into a graphic. You need to select the Anchored Frame that contains the graphic and then paste the text frame into that. It will then be placed on the top layer of the all of the contents within the Anchored Frame.

[susan_colm]

Arnis, I wasn't trying to paste into a graphic. I was trying to paste on top of it. But thank you all the same.

In any event, Adobe has notified me that this behavior is a bug:

Hi Susan,

We are working on this issue and have logged a bug # 4111649 (for your reference).

Thanks
Kunal

[Arnis_Gubins]

Susan,

Regardless of it being a bug, you still selected the incorrect object when trying to paste something on top of it. You should select the parent container (i.e. the Anchored frame) and then paste into that. FM pastes each entry on top of the previous one in the container (like a stack of plates). You can then use the Bring to Front/Send to Back options to change the stack as required.

This method of pasting (selecting the AFrame) works reliably and doesn't crash FM2015.

[Mike-Hardy]

Your crash might be related to the crash that is described in this recent thread:

consitently crash pasting text frame into graphic frame

[susan_colm]

Thanks Mike-Hardy, I will reply to that thread to make sure they look at my log files in connection with that fix.