This is just a shot in the dark, because there are so many software and hardware possibilities. Please don't vote "down" my answer, as I'm only trying to help you troubleshoot, even if I can't offer a sure solution.
From a software point of view it comes to mind that whatever processing is being triggered after the zero crossing is detection, is not always completing quickly enough to be ready for the next detection. You didn't say whether the 0 crossing detection triggers a hardware interrupt, or is simply sensed and dealt within a sampling loop. The interrupt methodology would almost certainly make matters worse if you didn't take steps to ensure the interrupt service routine (ISR for short) could not be interrupted again before completing. But even in a simple loop, it is possible for an error in program logic to cause a stack "blowup", if a subroutine can call itself to respond to an event (recursion) without some limitation. To test for things like this, you may have to add an LED or two to your system which can be programmatically controlled with very little overhead. This will allow you to do things like turn a LED on when you go into a routine, and off when you complete. Or if recursion is allowed, light the LED when a static limit counter is exceeded. At least this will tell you if it is always the same routine or point in the program you're getting stuck in. It can be a long arduous task to successively break a problem like this into possibilities, to finally isolate the problem code. But once you have something like an extra LED or two to trigger, you can slowly agin the insight you need to pinpoint the problem.
Now, there is also the possibility that there is an insidious hardware issue here. A rule of thumb for me (though its not always easy to know) is that the more random the nature of a failure, the more likely it is to be a hardware issue. Conversely the more predictable a failure, the more likely it is programming. Now you said 'after a while" it locks up and crashes. If this "while" is always 1.745 seconds (just an example number), then I'd suspect programming. But if its "anywhere from instantly to many seconds later", then I'd consider some hardware issues. For example, if the problem is truly load dependent, it may be that under load the motor is generating more EMI or noise spikes on the power bus, either of which could make its way back into your electronics or MCU.
Good luck, and I hope some of this helps.