But the forces which caused the current code to end up in such a sorry state will still be in force and cause the rewrite to end up in the same place.
If you have reason to think you can do better this time - e.g. the team have learned how to avoid unexplainable crashes - then you could apply this knowledge to fix the issues in the current code, which would a much less risk and less time.
In our scenario, The tool had no requirements. A student project did something which a team found useful and saved money. More students were given similar projects. Then an engineer comfortable with coding glued the code from all these students. This happened for 17+ years (converting several person months of work to few hours). The team lead for this team got promoted to a very high position in the firm and he hired a software team to redo everything with coherent code.
For us the first project acted as requirements analysis. In most cases bad software is mainly because of lack of proper requirements. In hindsight, its easier to make complex tool coherent.
If you have reason to think you can do better this time - e.g. the team have learned how to avoid unexplainable crashes - then you could apply this knowledge to fix the issues in the current code, which would a much less risk and less time.