On which excel version dit it happen?
2010. Like I said, I had iterative calculations enabled.
That’s what I was the most afraid of!
I included many “filters” into the spreadsheet in order to avoid the endless iterations due to some inconsistent values the loop may run into.
Although I tested it with many samples of SV, time settings and all and even the most absurd settings I could imagine, I could not be totally sure of it.
Could you post your file?
Ideally, if you can, please post 2 files: the first just before the entering of the crash value and a second after the crash.
Isn't this some sort of inconsistence? There are two possible orbits then, or am I thinking wrong?

I know what you mean.
In fact, in my mind the purpose of this data was not to compute the burn but just information to help for the setting of the spreadsheet because it could be useful, in some case, to know if the chaser line of Apside is aligned with respect to the target line of apside.
So I arranged the math for the angle to be always less than 90° since it eliminates the problem of a possible apside inversion.
Example: Let’s say the tgt LOA angle is 32.8° and assuming that the LOA is equal to the AgP. Let’s say that for some reason you would like to compute a burn to make the resulting orbit aligned with the target. If the Pe and AP are on the same side than the targets, the chaser AgP must be 32.8° too. But if the resulting computed orbit has inverted the apside (chaser Pe superposed to target Ap, and chaser Ap superposed to target Pe), the resulting AgP is 212.8° instead, which could be confusing especially if the user is not familiar with the complementary angles. The LOA angle would still show 32.8°.
May be it would be better if I would change the “LOA angle” to “relative LOA angle” which would display the difference in the target LOA and chaser LOA directly.
Oh, and I turned the inside of IMFD to the outside and didn't find any program which would be capable of calculating a burn from the spreadsheet data. The deltaV-prog shows ApA and PeA, but lacks AgP.

A second problem is as following:
Due to the nongravity field perturbation, LPe is a very unstable data. So it is almost impracticable as an IMFD setting. Although Pe/Ap heights are unstable too, those are a bit less sensitive.
I didn’t have enough time to test the spreadsheet into the simulation (I admit I should take that time) but my idea is that you can set IMFD with respect to the spreadsheet GET and Pe/Ap data. The respect of the GET should make the resulting mean LPe be quite right, no matter of the osculating LPe shown instantaneously.
As I said in a previous post, I prepare a new tab with the displays of the delta V’s components, in LVLH and/or velocity frame to be used in IMFD delta velocity program.
Anyway I’d like to thank you Meik84 and eddievhfan1984 for the time you spent in testing the spreadsheet and reporting these bugs.