- Home /
Game runs in Editor, Crashes in Build, CharacterMotor.js seems to blame
Short Version: Game runs in editor fine. Game crashes while starting up if when running as a build, with very little warning or information. Removing a slightly modified version of CharacterMotor.js stops the crash, but this source file is needed for the game to run properly.
Longer Version: A Unity project I’m working on seems to be having (recent) trouble running a build with a modified CharacterMotor.js.
Running the game in the editor works great, but when I try to run a build (Windows 7) the game crashes as it loads, rarely giving any notice in the output log.
Most of the time the error log has said little to nothing, but stripping down the project I did manage to get some information dumped. The dump file describes an error (which is vague, I know, a generic memory access fault):
Process Architecture: x86 Exception Code: 0xC0000005
Exception Information: The thread tried to read from or write to a virtual address for which it does not have the appropriate access.
This is about the most I can get out of the error log, although I think I can get a bit more information on the stack at time-of-crash. It took a week of trial and error to narrow down the problem file to CharacterMotor.js, as there is no error log or indication that anything is wrong until the crash itself.
The game runs fine in the editor, and only crashes if I try to run a build (one reason I do not know exactly when this started happening). My best guess would be for time would be after one of the more recent updates, like v4.1 or v4.2.
I’ve been working on this project for quite a while (since version 3.5) – I’ve done many working builds in the past. I’m running v4.3.3f1 currently, but I have been having this issue for a while now.
I narrowed the trouble down to CharacterMotor.js – If I remove it, the game runs (it doesn’t run well, obviously, giving me a ton of errors, but at least the executable doesn’t crash).
If I re-import CharacterMotor, the application will run. The problem is, I’ve customized the script and added new code to it. Adding in any new executable lines of code to CharacterMotor (even a simple variable declaration by itself) will cause the application to crash.
The crashing is not limited to one machine – I’ve tried building on a few computers, with pretty much the same result. I also wonder if it’s CharacterMotor specifically, or if that just happened to be an unlucky file that the build process ends up corrupting. A long session of trial and error suggests that this is the file that’s causing the crash, though.
I’ve heard of similar (but not identical) circumstances where CharacterMotor was corrupted, but most of the “easy” solutions I’ve read do not seem to work. Reimporting All does not do anything. I tried a simple replace-file-with-identical-one trick that was recommended, to no effect.
I haven’t done anything incredibly drastic yet (like c# translation, or making a new script type to replace CharacterMotor) as CharacterMotor touches a lot of other source files, so I want to make sure there is nothing else I can try before embarking on what looks to be very nasty code surgery (especially if I’m not sure it will fix what the problem is…)
I’m running Windows 7 (service pack 1), and Unity v4.3.3. Let me know if there is any further information I can give that could help.
Solved it - and boy is my face is red
An old file (named differently) defined a Character$$anonymous$$otor object in code, this along with the customized one created a conflict.
An easy fix, once I knew what the problem was - the thing is, I even found this advice in the forums, but overlooked that this file was still in the project!
The file was not being used in the scene, and only crashed the system when a built version was run.
Thank you for your response - stripping the build down to prepare it for uploading is what led me to find the problem file.
So let that be a lesson - don't copy and paste files around that share the same class name! And if your build crashes unexpectedly, quadruple-check to make sure you are not redundantly defining classes!