The majority of NLE crashes/hangs due to damaged media happen with "Long GOP" formats such as H.264 or H.265 (HEVC). In those cases, individual frames do not exist. They are reconstructed upon playback. Usually, what crashes is the attempt to reconstruct the frames from a damaged or "junk-quality" Long GOP video file.
So in most cases there is no single damaged frame, but that individual GOP comprising many frames is malformed.
BTW, if it also crashed in Resolve, how exactly did he remove the frame?
I have examined many such cases on FCP, Resolve and Premiere (I have licenses for all three). Sometimes there is a difference in how each handles some anomalous situation. But none are able to reliably handle all cases.
Professional camera formats (XAVC-L, XAVC-S, AVC-LongG, XF-AVC) use the same Long GOP codecs as everything else — H.264, HEVC, etc, but only a tiny, published, fixed set of parameters, with one vendor accountable for both encoder and decoder and NLE developers testing against exactly that list. That's what makes them reliable.
Everything else, such as security cameras, OBS, phones, screen and Zoom recordings, and random converters, lives in an unconstrained space. The standards are strict about what a decoder must accept but nearly silent about what an encoder may produce. It is the "Wild West" and goes largely unpoliced.
A keyframe every 600 frames, a frame rate that drifts under load, reordering depth that changes per scene, a container index never meant for seeking: all are perfectly legal. The number of legal combinations is effectively unbounded, nobody can test it, and no authority enforces good behavior. The consumer-world standard is "plays in a browser," which is a far lower bar than "can be edited."
A player decodes forward from the start and quietly drops or repeats a frame when timing is wrong. But an NLE must jump to any frame, count frames exactly, scrub, play backward, and fill a constant-rate timeline. "It plays fine" proves the stream more or less decodes, but it says nothing about editability.
In a Long GOP file, only the keyframes are pictures. The other 90-plus percent are instructions for modifying previously decoded frames, meaningless on their own. So a corrupt reference contaminates every frame until the next keyframe; most problems are timing and structure, not corrupt frames. Indeed there is no frame to remove since Long GOP uses pseudoframes that are reconstructed during decoding. The "frame" in an NLE error is merely where the decoder gave up, not where the fault is.
Because such files can't be validated in general, the fix is what broadcasters do: admit a narrow set of formats and convert everything else on ingest. Transcoding to constant-frame-rate ProRes isn't about quality. Rather it collapses an untestable space into one the NLE's developers could test. Likewise, tightly-constrained H.264/H.265 camera formats such as Sony's XAVC-S and XAVC-HS tend to be reliable.
Major broadcasters use high-end, expensive QC tools, but no low-cost, reliable video file validation utilities exist. Those expensive pro QC tools have lots of tuning parameters where a video engineer tweaks them for what to admit vs. reject. It is theoretically possible to write one (and I have attempted this several times), but it led to endless tuning to avoid "false positives" yet still detect real problems.
Most problems come from things like security DVRs, OBS/screen recorders, and Zoom. However, ffmpeg or utilities that call ffmpeg can easily encode problematic long-GOP formats. There is no roaming "codec police" to issue infractions for this. It isn't possible for NLEs with their hardware-accelerated, performance-critical threads to handle all the junk codecs. You can't make a finely-tuned high-performance car engine run on contaminated gasoline. It's up to the owner to provide high-quality fuel. The best action is accepting and understanding how widespread poor-quality codecs are and avoiding those or transcoding before it reaches the NLE.