Cross-References constantly crash ID 18.3

[Nedlaw]

I am having a growing and continuing problem with 18.3 cross-references, and I don't think I'm alone.

Using 18.3 on Win 11/64Gb memory. (And yes, my nVidia driver is updated too.)

24 hours ago, a single cross-reference crashed the program. It has only gotten worse since then in a cascade and brought production to a HALT. I have tried (not necessarily in order):

1. Bringing files into and out of IDML
2. Creating a new book file.
3. Rebooting the program. Rebooting the computer. (several times each)
4. Copy/Pasting existing page text into new fresh (template) document files.
5. Deleting and re-installing ID.
6. Deleting and re-downloading the fonts I'm using (to make as sure as possible that THEY were not corrupted).
7. Trashing preferences.

(That's just a sample.)

Now I'm at wit's end -- and I have very few wits to waste! I have never had problems like this with ID previously, and none that I couldn't solve with a reboot, copy/paste, IDML, and a quick preference-trashing.

It began when I tried to make a new Xref to an H1 head in another file (CRASH), but after copy/pasting text and creating 2 new versions of (what I thought were) the two problem files (CRASH), the problem just got worse and worse (CRASH CRASH), now affecting previously unaffected files. Of course, by copying/pasting I had to re-create the cross-file Xrefs in the new files and in the files that refer to them... but now (CRASH) even trying to update an existing Xref in a previously working file crashes the program. I'm working on a technical document -- of course with deadlines, and hey, it's the weekend -- and there are a lot of cross references required. Have I mentioned CRASH? (I've loyally sent off the crash DB each time to Adobe.)

The files are unusable because the program is now unusable because it's unable to do Xrefs, and I believe that the program -- not corrupted document files -- is at fault (although files may have become corrupted by the multiple crashes). Something triggered this "out of the blue."

Unless someone has a good suggestion about how to get the program and its cross-referencing function stable again and back working.... I may have to complete the project using "another program" (shudder), but the project must be completed). Here me, O Adobe!

I hope someone from Adobe corporate/tech support sees this. There are others having the same or very similar issues. I see their plaintive posts here in the forum as they wrestle with cross-references that just stop working and that crash the program.

Any suggestions from the community? Boy, am I listening.

Thanks as always to the community.

-j

[Bevi Chagnon - PubCom.com]

@Nedlaw, my condolences. 

What a nightmare!

I don't have much to recommend because you've already done what I and others would do.

I will pass this bug along to the programming team where, hopefully, they'll be able to track this down.

One suggestion: do you still have the previous version of InDesign installed —18.2 or even 17 — and can you drop back your project to it?

If 18.3 overwrote the previous 18.2, you can reinstall the older version from your Creative Cloud management app:

1. In the Apps section, locate InDesign.
2. Click on the ... at the far right and select Other Versions.
3. You should see a list of all of the micro-updates for 18 and 17. Choose whichever one you remember worked well before the crashes started.
4. I would open the best IDML version you now have in the older version and see if it's more stable.

Sure hoping this helps get you back on the deadline!

[Nedlaw]

Excellent suggestion!! I will create a set of IDML files with 18.3, then revert to 18.2 and import.

Thanks.

-j

[Bevi Chagnon - PubCom.com]

Crossing my fingers for you... <grin>

For anyone else reading this post, it's common to crash after a new update so prepare for the possibility. Here's what our studio does and what we recommend to our InDesign clients:

1. In the Creative Cloud manager app, TURN OFF the option to automatically update InDesign and Acrobat. You need to decide when's best to update, and it definitely is NOT when you're mid-project on a looming deadline.
2. When you do the update and are opening previously-made files, open a copy of your last best one from the old version of InDesign. Give it a new name.  You want to keep that last good version in case you have to drop back and recover, and it's best not to have it possibly corrupted by the new version of InDesign (if it has a bug).
3. Make incremental backups of your working files. Don't keep overwriting the old ones as that just embeds any corrupted bits and bytes. And the end of the workkday, our designers do a File / Save As / and new name to create a fresh copy of the file's code. Not only does this give us a decent backup to fall back to when needed, but it also prevents the file from becoming buggy and corrupted.

So you might end up with 50 versions of the layout file on your drive — ABC Project v-1, ABC Project v-2, etc. — just delete the older versions after the job is done, printed, and the client has paid the bill. Archive only the last version.

Software is buggy, whether from Adobe, Microsoft, or any of our other manufacturers. And creative design software is the buggiest!  So CYA with these easy steps and you'll have many fewer system crashes and corrupted files.

Hope this helps!

[Nedlaw · Accepted solution]

All good advice for the future. Horse meet barn door. Trying to fix things now. Here is what I see in one of the two main troublesome files...

Cross-reference dialog. There are many, many working Xrefs. Obviously, a bunch of Xrefs have been scotched by something. I was actually able to fix Cross Reference 68. When I tried 67, we crashed. Again.

The crashes survive IDML. Something is persistent in the IDML code that causes ID to go down in flames when I try to fix the problem. Merely touching a correction causes the crash. Let's look at one specific instance causing the problem.

This is one questionable paragraph with a couple of problematic Xrefs. Xref 68 was "Become a Query Ninja" on page 1 (numbering is off for obvious new import reasons). However, Xref 67 -- Appendix B -- is scotched and caused a crash when I touched it. I mean literally touched it. Cross-Ref dialog box opens, when you scroll to the paragraph, Ka-BOOM. That is the ID side of the problem. It is unable to handle what's going on in the files brought in from IDML.

Here is the Story Editor version of that same paragraph:

I can't explain the odd spacing here and there -- like between the A and ppendix -- that may be some invisible junk byte insertion at the file level. (I don't have a good viewer to look at the hex code.) I would think that deleting the words "Appendix B" and attempting to replace them with a fresh new Xref would do it... but CRASH.

Here is the XML code from the IDML file. I am not the world's greatest XML programmer. I did not try to trace all the hierarchical references. But I did find where Appendix B is mentioned in the IDML code -- and remember, the IDML is propagating the error. (Sorry about the size of the clip, but it needed to be legible.) There may be other IDML code snippets that will help reveal the issue -- I'm happy to supply them if someone will point me to where they may be.

In the code, I can see that the page numbers seem to be missing (or maybe these are markers to them; I'm not exactly sure how IDML works, but I have seen actual page numbers listed in other Xrefs).

I'm hoping that someone can look at these examples of the code and deduce the problem, then (a) tell me how to correct the IDML file-side of the problem (remember, IDML is propagating the issue) -- even if I have to fiddle with the IDML; I'm a techie, I can do that -- and (b) help diagonose the problem on the ID side and fix whatever initial bug caused this and is preventing ID from being able to repair the problem itself.

ID should be able to repair this, from all I can see. But something there -- in the IDML -- is still there when I import the file under a new name and causes the same crash, a file-handling condition that ID cannot cope with (for whatever reason).

Thanks as always to the community. I will continue to tinker as best I can. If I find something, I will report.

-j

[Nedlaw]

Experiment:
I opened the problem file from IDML. It converted to INDD.

I deleted all problematic Xrefs. They converted to text.

I saved the document at that point as IDML (to a different name).

I then opened the IDML and had it convert to INDD. There were NO suspicious Xrefs in the file (according to the Xref dialog).

I attempted to add an Xref ("Appendix B" in the paragraph above.)

I chose the destination file. I did not get further than scrolling to the style of the paragraph (AppendixNumber).

CRASH.

Something is seriously wrong here.

UPDATE:

I'm beginning to suspect that this problem only affects cross-file Xrefs. I'm able to make internal Xrefs even in the problem files without issue.

So: What could be present in an IDML file that would make ID unable to perform a cross-file Xref?

Update:
I was able to do a cross-file Xref to the chapterTitle of another file from my regular paragraph (paragraphROP).

When I tried to do the same Xref to the same external file from the same working file that had just succeeded -- but did it from within the Note style paragraph, it crashed.

Is it possible that it is the STYLES that have been compromised?

Yet Another Update:

When I examined the IMDL styles doc for the Note style, it didn't show anything abnormal (to me). Back in the trouble document, I created a new paragraph (not a note), rewrite the text of the note, including Xrefs, which worked, converted that paragraph to a note, deleted the original note, and pasted in the new note (Am I clear? I did a swap.) No problem. I saw another Xref in a regular paragraph that had been converted to text -- one of the scotched Xrefs. In another location, I recreated the link, deleted the original, then pasted the new link in successfully. Now, I'm thinking that somewhere a couple of the INDD files got subtly damaged in a way that ID could not cope with and that damage is propagated -- invisibly -- by the IDML format. At least I haven't found the damage. At this point, the work-around seems to be to rewrite any passage that includes a non-working Xref, delete the original, and paste in the rewrite. Laborious, but I can think of more laborious options. Weeding my garden, for instance.

-j

[Eugene Tyson]

You had a thread on this the other day - and ignored my advice

https://community.adobe.com/t5/indesign-discussions/bug-id-18-3-repeatably-crashes-on-cross-referenc...

Can you confirm you at least tried to Move Pages to a new document (instead of copy and paste)?

Copying and pasting copies trouble over.

Moving pages doesn't copy the text, it rebuilds it.

[Nedlaw]

I explained in my reply that I believed Move Pages would be likely to move the problem. So, no, I did not Move Pages. I apologize and meant no disrespect. Thanks for the amplification. Had I known that, I would have done it.

-j

[Eugene Tyson]

I was just wondering why you didn't try it. Seemed strange to me.

Any luck with it? 

[Nedlaw]

Update: Apparently repaired.

Summary of how:

All the files in the book would open (I just could not do Xrefs which crashed ID). Cross-Ref dialog was filled with these angry guys. Any attempt at editing crashed the program.

 

1. In turn, I opened each file singly and one-by-one and deleted the bad Xrefs (this hammered them into text sometimes leaving behind "see on page <?>").
2. I saved each file one-by-one as IDML.
3. Once that was done, I opened one file at at time from IDML, gave it an incremented file name, then saved as INDD, and closed it.
4. Then I re-opned a single troubled file. There were no longer any bad cross-references in it (they had been deleted).
5. While each file was opened (in turn), I went through the cross-references one-by-one in the text (not in the Cross-Reference dialog, although I used that dialog). First, I made sure that any Xrefs that still worked actually referred to the proper file version (some still referred to the previous version and not the incremented version). These I replaced completely, including surrounding text.), and then added any Xrefs that had been convered to text that I came across as new Xrefs.
6. It had appeared to me that some of the bad Xrefs were bad only when they were within their  styled paragraph -- adding a new paragraph of the same type, copying any plain text and adding a new Xref in the equivalent place, and then deleting the old paragraph seemed to work. I did not know if it was a corruption in the surrounding text or in the style or in the Xref itself -- so I replaced all of that for each problematic instance.
7. When I came upon an Xref that referred to an external file, I opened that file from IDML and saved it to a version-incremented file name, then went back to the file I'd been working on, and made the cross-reference to the second file. These seemed to work.
8. Eventually, I re-built a set of cross-references that correctly referenced the incremented target files.

Yes, this was laborious. Whatever had caused the original problem in the original two troubled files, and that persisted through IDML and back, seemed to resolve when I killed the corrupted Xrefs, saved to IDML and back, and recreated the Xrefs. The corrupted Xrefs could not be edited -- only deleted and replaced. I had to review all the (existing) cross-references in the (still unfinished) book. 

However, because I have no idea what caused the original problem, I have no idea how to avoid it in the future (other than by a hefty new backup regine, as was suggested). I still think this was a bug triggered by some horizon contdition that I crossed -- maybe an extra-long editing session. Who knows?

Thanks as always to the community.

This appears to have resolved the problem -- until it occurs again.

-j