Thanks Benjamin for letting some light into the topic, Chris for saying you’re seeing related errors in your world, and as always to Götz for stepping in faster than those of us in the New World can! 
To quote Benjamin:
In my experience, I get consistent crashing with images having plenty of tie points, but I believe too few where I need them, these regions being in the distance, which only exacerbates re projection errors
You’re certainly right – the tunnel you describe makes it hard (or, maybe, impossible) to get fully supported access in an unbroken chain extending to the furthest reaches. Based on my recent jaunts with RC, however, I’d be willing to bet that the problem is not the number of tie points. In my case, I was able to turn off the objects with poor point counts, and the crashing stopped. But in your case, where you have plenty of points but also registration instability, I’d be willing to bet that the problem is how RC picks the initial views during alignment.
In other words, yours is a classic failure case for sequential SfM – not starting the reconstruction with the best initial view, when the order of views matters. That causes the alignment to fall into local minima before it can converge on the actual best RMSE for the given views. Tie points establish the network of neighbors, but initial view selection is often independent.
The good news is that a global SfM approach doesn’t have these initialization problems. Can you test your data set with a (free) system like Simon Fuhrmann’s excellent MVE? (https://www.gcc.tu-darmstadt.de/home/proj/mve/). Simon’s work is very good and he has a nice Windows front end to make things easy, although there are many equally capable systems (Theia, OpenMVG, and others) you could also use.
Perhaps the best ‘production ready’ global SfM system is Pierre Moulon’s wonderful OpenMVG:
https://github.com/openMVG/openMVG
If you use one of these, just make sure you use the global alignment option, not incremental.
All of these have the advantage that they’re free, and they’re open source so you can see what they do and extend them. They have the disadvantage of not being as well optimized for the GPU as RC, so if you’re running on a single PC it will take a lot longer. However, the final mesh results from my tests demonstrate that while the open solutions are slow compared to RC, they can generate better surfaces than RC: both cleaner and more accurate to ground truth. That may be important, or even decisive for you as it seems you’re working for a scientific result.
As Götz and I have discussed in other threads, Global SfM methods solve for all positions at once, so they are much less brittle in cases like yours. It appears that RC uses a sequential solver, but I’ve asked for clarification on this and never got a response. Since RC isn’t open source, we can’t check for ourselves.
While the backscatter isn’t helping the focus, any of those points that get recognized during feature search will be discarded in the next image as the dust moves, so they’ll fail the homography test. If the dust is enough to cause blur, that’s a different story – blur is destructive to reconstructions in exactly the slippery way you describe your current trouble.