Why does LTSpice sometimes stop printing midway through a simulation?

LTspice uses a solver that is based on convergence. It also uses a variable time step, meaning the time step is based on accuracy parameters.

If the next time step is not converging it 'backs up' and tries again, to explain this in detail would require a knowledge of numerical methods (of which I only understand the basics). If it fails to converge again and doesnt meet the tolerance requirements it backs up and tries again, which results in the simulation failing to solve for new timesteps.

If you having convergence issues try this (SOURCE: LT spice wiki)

Add a small conductance of 1e10(=10GOhm) parallel to every diode of transistors and diodes.

.options gmin=1e-10   

Increase the allowed tolerance from 1e-12 to 1e-10 for the convergence criteria.

 .options abstol=1e-10  

Increase the allowed tolerance from 0.0001 to 0.003 for the convergence criteria. Never larger than 0.003!

.options reltol=0.003  

Capacitance added from each node to ground. Adding a small CSHUNT to each node can solve some "internal timestep too small" problems caused by high-frequency oscillations or numerical noise. Default = 0.

.options cshunt=1e-15 

Edit: Odds are the cshunt in conjunction with another resistance in the circuit will create an RC circuit and help to limit bandwidth (its hard if the solver wants to simulate more than GHz of bandwidth because it needs to use lots of time steps). A resistor can help reduce floating nodes or nodes that have high impedance but need to be referenced to ground. Both of these methods truncate numerical errors in the solver and reduce the time it needs to solve. A lot of times adding pFs and Mohms are fine because those values are close to that of air or from plane to plane in FR4. In doing so you simulate parasitics and make the circuit behave more like it would in the real world.

If we did have circuit superconductors and could construct ideal circuit elements it would create a lot of problems, like resonators past the GHz range, in all of our PCB's. The real world isn't like that but LT spice is, unless you watch the parasitics.

(I am assuming you are doing a .TRAN analysis.)

First off, you should have provided a schematic to simulate. I know. You think that this is a common problem with a simple explanation. But it is nothing like that, at all. And although you occasionally encounter this problem, it may be that each time it is for a different reason requiring a different explanation. So you do yourself no service by failing to provide a specific example. Instead, you ask us to write a chapter or two -- maybe even a book -- on the topic. And that is asking way, way too much.

In fact, there is a chapter on this topic included in "The Spice Book," by Andrei Vladimirescu. Chapter 10. I recommend you get and read it. Please note that the book isn't about LTspice; instead it is about pretty much all Spice programs. And all of them have problems similar to what you describe.

Many commercial Spice implementations have a number of added heuristics to help them bridge across some of the more important cases. However, like anything, these themselves are often two-edged swords that cut in surprising ways. You may find that one commercial Spice program does a lot better simulating a certain category of situations, while doing now more poorly in others (or, where you need to "specify something specific" in its configuration to get back the older behavior.) The whole subject area requires an expertise that few people (in my experience) possess fully.

(I know exactly ONE person who I consider to be "always well-placed to solve any convergence problem" because I've never yet seen a case where he wasn't quickly able to identify exactly where to add something to make Spice work well on the problem.)

For .TRAN simulations (and those are not the only functions where problems arise), let me list a few thoughts in no particular order that apply to any Spice program, including LTspice:

1. Look for cases in your circuit where the ratio of the largest valued component to the smallest valued component exceeds about nine orders of magnitude. Unusual ranges like this are strongly suggestive of need for a correction of some kind.
2. Insufficient charge storage leads to switching times that approach zero time and this can result in a serious slow-down either at the beginning, or else later during simulation.
3. MOSFETs have more convergence problems that BJTs, as MOSFETs have a self-conductance of zero at DC for their gates. BJTs, of course, don't have that issue. Also, Spice assumes BJTs are conducting during the first iteration, while MOSFETs are assumed to not be conducting (unless their subthreshold NFS parameter is given.) So, if MOSFETs are present, pay particular attention to parasitics and the model parameters. Also note that a circuit with a lot of MOSFETs, initially considered not conducting, causes a circuit to start out quite different than a populated BJT circuit where they are mostly assumed to be conducting. This is a whole area of its own.
4. Many Spice implementations (LTspice included) offer different solution methods. Trapezoidal (and/or modified) and Gear variable-order, are two such basic categories. LTspice offers a way to select between these. You might find that one works where the other works more poorly.
5. Check device models to see if they provide unrealistic conductances.
6. Look into the .OPTIONS for LTspice: ABSTOL and RELTOL. Relax them and see if that helps.
7. Reduce the maximum time step.
8. Use TRTOL and set it to a large value (like 1000, or something.)
9. Instead of relaxing RELTOL, try tightening it up in order to avoid bypassing some otherwise "inactive" device in the schematic.

I've only used a few different Spice programs in the past. So my experience isn't good enough to give you anything close to a survey of them. But none of them I have experienced are free of problem areas. They all have difficulties when faced with certain simulations. Some have better heuristics for some problems, while doing more poorly on other problems. None of them have been, I think, a panacea that solves all problems they face. And all of the better ones (I do NOT consider MULTISIM worth a darn, but I haven't used it in years now so perhaps it is better today) have enough problem areas that no one of them seems "the way to go."

I've written vaguely because you provided no circuit. (I certainly cannot pick out something specific in LTspice, lacking any schematic at all.) Perhaps these thoughts will help. I might have gotten lucky. But... It would be a lot better if you'd provide a specific case.

Look at the status bar. That gives you the simulation progress. If it says Defcon 1 then it is having convergence problems and is trying other slower methods to try to make the circuit converge.