I looked at the code trying to understand what it was doing.
It seems that this code attempts to determine whether a crash is caused by some corrupted code or not.
This is blind-folded approach which walk over the x86 assembly, attempting to determine whether this is something which is never produced by our JIT, returning
CRASH_CORRUPT_CODE, or a bad operand or bad branch target
Technically this is an approximation which has many flaws. x86 is not a fixed size assembly, thus our page start is not guaranteed to start at an instruction boundary. Then walking these random bytes might yield to decoded gibberish, which could also be identified as corrupted code. So we have a risk of having wrongly reported corrupted code. Our JIT code is patched on invalidation, which can yield to bad results as well.
Then this code bit-rot since it was created. We do generate
sbb instructions, which were reported as corrupted code, now exists because we can manipulate 64 bits values in WASM.
The intent behind the current code is good, however, the likelyhood of having correct code being reported as incorrect is high.
I would be happy to help revive something similar in the future, and potentially improve upon it. There is currently some investigation made by the JS team to see how we can refine our crash-stats reports to make more of them actionable.