Open Cross Section Model doesn't work in heads-up prompt.

I've seen this behavior a few times in the past myself. I believe the problem was always associated with one or more corridor references were derived from the corridor, leading to a loop. Instead of a fatal loop, I get the impression that it just quits trying to resolve and gives you that gobbledygook. Now, at the time that you attach an element that is derived from the corridor, it usually reports that it can't do so. On the other hand, it's conceivable to attach an element that isn't derived from the same corridor, and then snap it to the corridor, thus breaking it.

Can you open Corridor Objects and remove references?

Also, I know that there are measures in the software that prevent you from using Corridor A as a target surface for Corridor B, so that you don't have such a computation loop, there have been times I've suspected that I've made it happen (accidentally), probably in a way similar to the experience with the corridor references.

Consider removing all target aliases that might be violating these principles.

I hope that helps. That's all that comes to mind as far as troubleshooting this issue. Feel free to reject this as an answer if this doesn't solve your problem.

And sorry if I touched on something that was already discussed. I was entirely unclever and didn't read the entire thread. It looks now like you have it working after all.

I removed all the point control, parametric constraints, and external references from the corridor and it still had that same gobbledygook in the information. I had sent Beebe all my files because there were a lot of references but we weren't able to figure out a way to fix it.

I would guess that you removed all the point controls, parametric constraints, and external references from the corridor through the Corridor Objects summary window.

If you've done any target aliasing, that won't show up in the Corridor Objects window. In order to confirm that there is no target aliasing, you would need to use the Define Target Aliasing tool. Key-in is CORRIDOR TARGETALIAS OPEN.

Now, an easily default assumption for anyone that isn't working on the project is that your active terrain (including any usage of target aliasing) is existing, based only on fixed points taken from a survey. In this assumed case, the active terrain would not cause a problem. On the other hand, if it is derived from the corridor that is targeting it, I believe that could cause this problem.

As a matter of fact, it might be worth a shot to entirely detach all references (other than the file that holds the alignment and profile) to guarantee that there is no connections to anything that may be based on the corridor that's causing the problem. Of course this will affect all other corridors in the same file, so if all of the corridors are in the same file this would be a destructive operation.

Another option is the keyin CIVIL DISPLAY BROWSER. When you do that, look for TargetAliasNameSet. Expand entries until you see a CorridorRule entry. Take a look at that entry. Note the name of the corridor. If that's the one that matches the broken corridor, DO NOT DELETE THE CORRIDOR ENTRY, but delete its parent TargetAliasNameSet entry. In this example, if the corridor "drain-east" was giving me trouble, I would delete the entry that says TargetAliasNameSet // DGNEC::158d200000::ECXA::1. (With an earlier edit I'd misread the function of TargetAlias.)

I first tried to delete everything (point controls, etc.) and deleting the target aliasing with no success.   You second suggestion like you said would be pretty destructive to the other corridors that are in there.  But I tried the third option and delete the file you said to but it didn't seem to help but I did notice that it was red:

There were also a lot of others that were red, I assume this means this is a problem.  I have never used this before to look at my corridors so any information to help me understand all this will be very helpful.

Earlier today, but after that last post I added here, I ran into what might be a similar situation myself.

Last night, my colleague had rearranged an alignment with the use of Complex Redefine. My impression was that it would entirely replace (at every level) the old alignment. Apparently it doesn't work that way. It keeps the name of the alignment, and apparently it keeps the profile too (which is obviously not particularly valid after the realignment anyway). I was under the impression that the corridor that was previously set to follow this local road alignment would be fine, with just a few adjustments.

What I found instead is that it wouldn't reassociate with the modified alignment. I used the civil display browser keyin. I looked everywhere through the red highlighted entries but couldn't find anything that would let me reassociate the corridor with the new alignment. Eventually I clicked the button to the right that allows you to repair all relationships. In this case, it devastated my corridor. (Not that I care, really; it was a really short corridor with no references other than the mainline's corridor surface.)

What I might suggest is to make a copy of the corridor file (the entire file) you're working in, and just delete or modify entries that you want to test. If it turns out that was a bad thing to do, you should still be able to undo (Ctrl+Z) or if not, you'll still have your backup file.

Basically I haven't spent a lot of time with this objectspace browser in a way that I would know how to best use it. I only know that it keeps some associations there, some of which I've had to delete to solve a problem. (In at least one case I found that a better solution was less destructive than what I did here.) For example, one time I had issues with a dynamic cross section view, so I went in there and deleted the entry under DynamicCrossSectionSpace. From there, I had to create a new dynamic cross section view, but at least it worked.

In your first screenshot, was that red CorridorRule entry your Corridor 4? If so, I would delete that. It won't delete your corridor; it'll only delete Corridor 4's connection to any aliased target (good or bad, I imagine). But like I said, you might want to keep a copy of the file as it is right now, just in case, especially if you want to tinker with it. It will have no effect on your backup file, and it won't have any effect on any other file that's attached (because those are read-only). It'll affect only the file you're in, and only its elements' associations with other elements.

If you figure out what the problem was, or discover anything else new, I'd be happy to hear about it.

Earlier today, but after that last post I added here, I ran into what might be a similar situation myself.

Last night, my colleague had rearranged an alignment with the use of Complex Redefine. My impression was that it would entirely replace (at every level) the old alignment. Apparently it doesn't work that way. It keeps the name of the alignment, and apparently it keeps the profile too (which is obviously not particularly valid after the realignment anyway). I was under the impression that the corridor that was previously set to follow this local road alignment would be fine, with just a few adjustments.

What I found instead is that it wouldn't reassociate with the modified alignment. I used the civil display browser keyin. I looked everywhere through the red highlighted entries but couldn't find anything that would let me reassociate the corridor with the new alignment. Eventually I clicked the button to the right that allows you to repair all relationships. In this case, it devastated my corridor. (Not that I care, really; it was a really short corridor with no references other than the mainline's corridor surface.)

What I might suggest is to make a copy of the corridor file (the entire file) you're working in, and just delete or modify entries that you want to test. If it turns out that was a bad thing to do, you should still be able to undo (Ctrl+Z) or if not, you'll still have your backup file.

Basically I haven't spent a lot of time with this objectspace browser in a way that I would know how to best use it. I only know that it keeps some associations there, some of which I've had to delete to solve a problem. (In at least one case I found that a better solution was less destructive than what I did here.) For example, one time I had issues with a dynamic cross section view, so I went in there and deleted the entry under DynamicCrossSectionSpace. From there, I had to create a new dynamic cross section view, but at least it worked.

In your first screenshot, was that red CorridorRule entry your Corridor 4? If so, I would delete that. It won't delete your corridor; it'll only delete Corridor 4's connection to any aliased target (good or bad, I imagine). But like I said, you might want to keep a copy of the file as it is right now, just in case, especially if you want to tinker with it. It will have no effect on your backup file, and it won't have any effect on any other file that's attached (because those are read-only). It'll affect only the file you're in, and only its elements' associations with other elements.

If you figure out what the problem was, or discover anything else new, I'd be happy to hear about it.

The repair all relationships worked!!! Thank you very much.