Windows 7 x64 compiler exception

Hi, I’m trying to use Unity trial 2.5.1 on Windows 7 x64 and when I open my project Unity gives this error:

ERROR: Could not start compilationWin32Exception application name=<path>/mono.exe etc....

WARNING: Compilation failed because the compiler couldn't be executed!

so I cannot have my project compiled.

I’m running Unity and all the Mono framework executables in Administrator mode with the UAC disabled.
I’ve also tried to make them run in compatibility XP SP3 mode but it doesn’t work.

If someone have some ideas in how to fix this it will be very appreciated.

THANKS !!! :slight_smile:

did you put it into c:/program files?

Do you mean "C:\Program Files" and not "C:\Program Files (x86)"?

[EDIT] However because of the 32bit nature of Unity executable the folder in wich it is placed is "C:\Program Files (x86)".

Has this been solved?

I just ran into the same problem, only difference being that my computer runs Windows Vista x64, and my Unity version is 2.5.0f5 Pro. It is installed in the “Program Files (x86)”-folder.

Everything has been working fine for several months, but today the error just popped up as I was coding peacefully…

I have seen that error only due to one thing actually: messing with scripts while unity was compiling them, killing the compiler. When that happens you must restart unity to restart the mono instance and compiler too.

If you have it in c program files, ensuer you run it with admin priviledges and that the project is NOT in there but your documents folder or alike.

Hmm, that might be the case. However, I have both restarted Unity several times and rebooted the entire computer without any results.

Well, I haven’t been running Unity as admin, so I tried that now - but no luck. :frowning:
The project has its own directory under C:/.

Thank you for the input. I really appreciate it, 'cause I’m seriously at a loss here…

You could try to just move out the unity folder of the c program files folder (if x86 or the normal is of no importance, both are pretty hefty shielded if UAC is enabled) and see if it helps.

May I ask for your UAC state? is it enabled or disabled? (the later is likely the standard for devs …)

You guessed it, UAC is disabled. :slight_smile:

You think it might be related to UAC somehow?

As long as it is in the program files folder, yes, thats potentially possible as the two program files folder have a special status in the security mechanisms of Vista

I actually only install stuff on c:\program files or its x86 counterpart that I don’t care losing on a partition fail.
All others are on D or F program files, so still installed by the same logic but not under the same security measures

I recently ran into an issue with Dark Basic Pro where it was running and compiling my programs just fine, then all of a sudden the compiler threw a bizarre error (also on Windows 7 x64).

In that instance, DBP wasn’t installed into c:\Program Files, but onto my E drive.

The solution was to exclude the DBP installation directory and (for good measure) the directory I keep my projects in from the Microsoft Security Essentials software.

Once I did that, it worked fine again. So if you’re running AV software, try adding the Unity directory and the location of your projects to the excluded list and see if it helps.

Security software naturally can impact things too. I’ve Nod32 and never had any problems. But for write performance and write correctness reasons (unity stores and modified a lot of meta data) I excluded said places myself as well

I might have finally found what this is about. If I remove a source file, any source file, from my project, it compiles. So my theory is that there is some kind of upper limit to how many files the C#-compiler can handle.

Can anyone confirm or deny this theory?

would be new to me but perhaps its runs out of heap memory when generating the assembly alike the crashes you get / got with FASM until the 1.6.3 update.

Hey Kata,

You hit the nail on the head. There is no numerical limit, but at 2.5.1 the length of the argument string that can be passed into the compiler is limited. This means that if Unity sees a lot of scripts that need to be compiled, and throws them all at the compiler at once, you’ll see this problem. We’ve changed this for 2.6.

Just for the record, the only other thing I have seen that causes the compiler to not work is if your environment variables contain non-ascii characters. Seems like the version of Mono we use can’t process your environment if typing SET in a command shell on the PC returns any characters above 255 (hence it’s probably using unsigned chars where it should be using unsigned shorts.)

HTH,
Graham

Thanks for the reply! I upgraded to 2.6 today, good to know I can forget my worries about writing too much code!

I reply even if this thread is old, my case can maybe help others.

I had the same problem because ThreatFire, my antivirus, had quarantined “Mono.exe”
Yes, ridiculous !