I created an assignment file with around 20 different stories. The next time I opened InDesign the writer had input text to most of the story files. One story file was a couple of pages of text, the rest were just a few lines of copy, nothing huge. Every time I tried to update the ICML files InDesign crashed. I didn't matter if I only tried updating one story or all of them, it always crashed. I was working on a PC when this happened. I moved over to my Mac to try and updated the ICML files and it crashed there too.

The actual InCopy ICML files on the server were fine. The writer never realized there was a problem. All of the copy was sitting there, so I was able to go back and re-import all the copy.

I did all the basic stuff to resolve the issue like restart, trash the prefs, convert to INX, and try on different computer. Nothing worked, crashed InDesign every time.

I'm currently using CS5, but this same issue came up last year on another project in CS4 as well.

Has anyone had this happen and/or know of a fix other than re-importing all the story files?

No, unfortunately I haven't found an answer to why or exactly what causes the issue. My fix has been to recreate the document. You can import the ICML files for the content, but you need to create a new file. Whatever gets corrupt carries through if simply you do a Save As.

I can't even re-import stories. If your document has too many images, or anything too complicated, this software just crashes your InDesign app.

If I HAVE to use InCopy in my workflow, I have the editor send me each assignment (not too big, because the app can't handle it) and test each one, so they aren't wasting all this time entering corrections.

I discovered that I can place the InCopy story into a new empty document and then copy and paste it back into the layout. I have to unlink the IC story in the layout to do this, but once I have it up to date, I reexport it over the top of the existing ICML. A bit of a time-consuming work around, but at least I don't lose the edits. It's less cumbersome than exporting every single document to IDML--which I'm not sure will work in this instance. Luckily, I have flowed the whole complex text stream into a single story, so this work around isn't too bad. For multiple stories, it would be time-prohibitive.

I have exported the next lesson (of many) into IDML and back before exporting it to InCopy, but I'll have to wait to see whether that fixes it. My editor is out of the office today.

I'm just curious . . . do either of you have tables, anchored text boxes, or spanning text in the affected stories? In my exerience so far, ID CS5 is very finicky when tables are in use and even worse when tables and spanning text are combined in the same story. My layout has all three, and I'm also using the Side Heads plugin (which loses its configuration when I export to IDML--which is why I'd like to avoid that). I skipped from CS3 to CS5, so I can't say for CS4, but CS5 seems to be really unstable in complex story flows. I suspect the problem may just be the app itself--considering that the editor can open, edit, and save the stories in InCopy--even edit within the ID layout--with no problem, and the stories themselves don't seem to be corrupted.

I've had a good day if I can work all day without crashing ID CS5 at least 3 times.

My files were created from scratch in CS5 on this particular project. This is the first time I've had problems with updating InCopy stories in CS5, but it isn't the first time I've had problems with ID CS5. Just about every time I work with tables in CS5, I've had problems with unexplained crashes. That's why I think it may have something to do with the tables, the embedded text frames, or the spanning text (or a combination of all three).

CS5 has been for me a true trial. I've already uncovered two reproducable bugs in the application (at least one of them had to do with long tables). I suspect this is another bug.

Unless we submit bug reports with specific details on how to produce the bug, Adobe is unlikely to notice the issue. That's why it's important for those of us with the problem to try and compare notes and see if we can track down exactly what is causing the crash.

Did you see my question about if you were using tables in the affected workflows? Anchored objects? Spanning text? What makes your particular layout different than a simpler document?

Well, it does sound like we're all using tables and anchored objects. I know that I've successfully used anchored objects in an IC workflow without any issues, so maybe it's the tables--which wouldn't surprise me since I've already run into a couple other table-related bugs in CS5.

My layout has all three, and I'm also using the Side Heads plugin (which loses its configuration when I export to IDML--which is why I'd like to avoid that).

FYI, The newest version has an option to import Side Head definitions, so you can happily export IDML, and then re-import the definitions from your original file in one click...

I skipped from CS3 to CS5, so I can't say for CS4, but CS5 seems to be really unstable in complex story flows. I suspect the problem may just be the app itself--considering that the editor can open, edit, and save the stories in InCopy--even edit within the ID layout--with no problem, and the stories themselves don't seem to be corrupted.

There's a good chance that there's corruption in the style definitions...

I've been working on a big project for the past month without any problems until now. The document that died was 42 pages with text and tables only. I tried exporting to IDML and reopening, but that didn't work, it never has. I have about 40 other documents that are still working fine, but they are all much smaller in page count. That may just be coincidence, not sure.

Yep - me too. I am struggling again with InDesign crashes when opening an indd book file that has exported InCopy stories. Stories which have been edited and are ready for update back into the .indd file. Opening the .indd is fine, but when I try to check out/update the InCopy stories, InDesign crashes... hard and has corrupted the file now. Yippee!

So frustrating! I am ready to write off InCopy as an editing tool as it has always caused issues. Before there would be crashes and corruption of data when the InCopy editor would have a newer or older patch build of IC than the exported story. Now, who the heck knows why we have this issue. Ugh!

I have a book file with multiple indd docs, interactivity built-in, InCopy stories, tables, anchored graphics, links, embedded video, the whole package... and now, it is corrupt! Good news, I can open the .indd file in InCopy and see the edits perfectly. Updating the .indd file is just not going to happen. Now, on to plan B... again.

Sure wish Adobe could get this right. It would be an awesome tool if it worked. As of now, its just a good, yet expensive Concept!

It's a work around, but it does work . . . open a new document and place the IC files that need to be updated into the new document. Select all the text in the story, copy it, then open your original ID file, DO NOT UPDATE the stories. Unlink them and then select with in the story, select all, and paste over. Make sure you paste the correct IC story into the correct story block in the ID file. Once you have all the undated stories in the ID document, export the document to IDML (InDesign Mark Up Language) and then open the IDML file and save over the old ID document. Re-export your IC docs and the crashes should stop.

I've managed to correct all the files that were crashing on me through this route. However, the IDML export seems to be necessary even if you've created the document from scratch. One thing that might prevent this hangup with complex files is creating the file with all it's complexity and then exporting to IDML before exporting to IC. Just a thought.

I don't save Crash Report, but no problem: today the problem will persist...then send the error to you today!

The error occurred persistently in a file mathematics book (hundreds of eps linked, from the MathType). I have updated link by link - to find out what the link was freezing Indesign - when he crashed an updated ICML / frame that had multiple groupings (more complex object).

Well, we conclude: you should not place elements with multiple groupings because it crashes (??) assumed this policy.

But for my happiness, I find that the problem is not mathematics book: it is an intermittent error, and it always happens with books of mathematics, biology, history ....

Problem: When InDesign open *.indd associate with *.icma and *.icml files: Indesign warns that the *.indd associated with is damaged (asks if I want to open anyway) both selecting "open" or "cancel" the software close

unexpectedly.

At other times he warns anything, only requires the update of icmls (the icon appears outdated on assignments panel), if you choose to update, it starts to update, and then closes Indesign.

I am not sure, but does this indicate you have had 67 recent crashes, only 22 of which have been from InDesign? THat is, have other apps been crashing on your machine? If so, perhaps there is a problem unrelated to InDesign?

Do you have the same problem if you opened the associated INDD file from InDesign, not the IDAP or ICMA?

Some might call me crazy, but in order to progress with my project I ended up having to create my own work around this crashing bug.

The problem with my situation was that the reviewers had already made their comments in InCopy and it wasn't until I tried opening the .indd file and updating the stories that we received the crash... every time.

My workaround - if the reviewers had made their comments in InCopy, hopefully with track changes enabled, in order to see their comments I did the following:

I opened the .indd file in InDesign CS5.5 (version 7.5.2). DO NOT UPDATE the document with the ICML stories. Instead I unlinked the .icml stories from the main document. I then opened the .icml files in InCopy 5.5. I was able to see the edits that were made by my reviewers and copy and paste them between InCopy and InDesign at that point.

I know, I know. This is totally a crazy thing to need to do when we have such a powerful tool (InDesign and InCopy). It comes down to, you must do what you must do to get the job done. I truly had no other option presented at the time. The project had to complete and the reviewers were not HAPPY to even think about reviewing the content again via PDF shared review.

The best advice I received from other forum users when I proposed the crashing issue was that it could be because of anchored objects being deleted or moved by an InCopy editor. Because InCopy is strictly a text editing tool, there may be an issue that causes InDesign to get frustrated when an edit moves or deletes an anchored object or frame. I had lots of anchored object, interactive objects, etc. in my document. To track down whether an anchored object moved or was deleted by a user was unsurmountable... my workaround, while painful, at least got the job done this time.

Any future projects will be moved back to CS4. That version atleast works with InCopy stories and Interactivity. I am sure one day this will be resolved... just wonder when.

ETC Steph, I've been working around this crash for awhile. You may be doing needless work in your workaround. Exporting the INDD file to IDML (Indesign mark up language), and opening that file, will fix the crash. You do not have to unlink the IC files, they will update without crashing when you open the IDML You ony have to do this once. Save the opened IDML file over your INDD file and that should permanently fix that document. The bug is in the Indesign file, not the InCopy stories.

I do believe the bug has something to do with anchored objects as that is a predominant part of the files that crash for me. However, I exported my template to IDML and resaved it for future layouts and that seems to have fixed all the new documents. Some corruption was introduced when I created the initial template, and it was being passed on to all documents based on that template. Once I fixed the template, the documents based on it ceased to crash on IC update. As long as your documents are not repaired, the bug will just keep compounding, especially if you make copies of those documents to create new ones. It's a time consuming fix, but not as time consuming as breaking the links and copying the stories back over.

One last note, you can flow the IC stories into new ID files without a crash--at least I could. That's how I figured out that it was the ID file that had the corruption and not the IC stories. So technically, you don't need to use InCopy. You could just open a blank doc in ID, flow in the IC stories and copy them into the old doc. That's what I was doing until I realized that the ID file just needed to be repaired. Now I do that whenever I have a doc that crashes on update.

I did try the InDesign Mark Up Language "cleaner" as part of my troubleshooting, and it didn't work for me. I love the idea of just flowing the InCopy text into a blank .indd document though. Something I didn't try. Where were you two weeks ago when I was pulling my hair out with these crashes. Thanks for the information "E Diane King".

I will try everything that you proposed, but am still really angry with Adobe ...\

Miss CS4 ...

My problem is that am working with LiveEdit (InCopy and InDesign without CMS) and every four documents, three corrupt! shortly (few months) will be thousands of pages! Wanna see how to work with many files corrupted ...

Are you working off templates, resaving documents to create new? Sometimes you can introduce a corruption while creating your initial template and then compound it as you base documents off the initial corrupted document. If you can keep your base templates as error-free as possible by rebuilding them through the IDML export once you have them set up, you can prevent compounding corruptions in multi-file workflows.

I know where you're coming from as I'm working on a three-year curriuculum with hundreds of documents and thousands of pages, multiple anchored objects in every document, and a style sheet that makes full use of the split/span column feature. Unfortunately, using complex, long-document features in their first generation in InDesign can be risky. You have to learn to live with the bugs that have not been fully vetted before release of the feature.

In CS5 and 5.5, there are some great new features that I suspect were not fully beta-tested before the software was released. I'm sure Adobe tries to fully test the features, but they are only human and surely can't think of every possible way that their users are going to try to use the features they provide. As angry as I've been about the bug-filled release of ID CS5, I have to grudgling admit that the more complex the application becomes, the more likely it will be that we will run into these kind of bugs and corruptions with each new release. I have high hopes for CS6, but mostly because I hope that Adobe will have had the decency to work out the bugs in 5 and 5.5 before they add more cool features that don't play nicely with the features they have already released (that don't play nicely with previous features). It's a compounding problem as long as users like us continuely expect innovation with each release.