Vcvarsx86_amd64.bat Causing GenerateProjectFiles to Exit Without Error

Hi,

I am having issues generating project files. I have narrowed down the issue to vcvarsx86_amd64.bat. For some reason GenerateProjectFiles.bat does not make it past this call (line 37).

I have VS2013 professional installed with update 3. I am using Unreal 4.4. I have also put the two required folders in place.

My environment variable are set:

18491-ue1.png

My registry values are set:

GenerateProjectFiles.bat is able to find my VS120COMNTOOLS variable. I know this because I added an echo:

18493-ue3.png

In the above snippet from my modified GenerateProjectFiles.bat, I add some additional debugging echos. I never make it to the second echo.

I have attached my DxDiag information, if you’d like to see my specs.[link text][4]

Any suggestions? Someone please help me.

Hi Mike,

Sorry for the delayed response. Do you receive an error message when running GenerateProjectFiles.bat, or does it simply close without creating the project files?

Hi,

It closes right away and does not create any project files nor does it output anything to the console window. I put in manual “pause” statements as a means to track where it exits, based on my investigations, the call to “vcvarsx86_amd64.bat” causes the GenerateProjectFiles.bat procedure to exit.

Which specific version of 4.4 are you trying to build? Did you make sure you used the required dependency files for that specific version (the files for 4.4.0 may not work with 4.4.3, for example).

Could you please download the attached file and place it on your desktop. Remove the .txt extension and run the file. It will create a new file named info.txt. If you could please attach that file here it will help us try to narrow down what may be happening.

Here is the info.txt file: [link text][1]

I am not actually sure which version of 4.4 I am using, I attached a screen clip of the branch I cloned. Is there a way to find out which specific version I have cloned?

18900-ue44.png

If you made a fork directly from the 4.4 branch within the last few days, it is most likely version 4.4.3. Did you download the required dependency files from the links in the readme for that branch? If so, you should have the correct files.

The info.txt file you provided was missing some information. Did it not provide the PATH, INCLUDE, and LIB environment variables? Could you check your PATH environment variable to see if it includes the value C:\Windows\system32;? That has been missing for some users and has caused issues when building the Engine without it. There also should have been a second section for the x86-amd64 toolchain below the 32-bit toolchain.

Hi, I cloned about a week or two ago, I will re-try cloning and re-downloading the deps if you tell me to.

That said, since PATH did not show up in the info.txt file, I think its fair to assume there is some other problem, right?

System32 is indeed in my Path variable.

Here is a screen clip of my Path variable.

18911-uepath.png

I noticed that my Path variable is not in caps, could this be an issue? Are environment variables case-sensitive?

EDIT: So I took a look at your batch file, I noticed again that the procedure did not make it past the “vcvarsx86_amd64.bat” (which is why PATH wasn’t outputted), leading me to believe again that something is up with the “vcvarsx86_amd64.bat” procedure…

This is what I get when running the same batch file, so something is definitely going wrong. I am going to see if I can find out what could be causing the process in both cases to apparently early out.

Sorry for the delay in getting back to you. There are a couple things we would like you to try.

  • Double-check to make sure your Visual Studio installation contains the vcvarsx86_amd64.bat file. It should be located at C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat. If it is there, which it should be, run it manually from a command window.
  • What is your %Path2% variable set to? It is a bit unusual to see that as the first setting in your Path variable.

No problem, thanks for coming back :slight_smile:

vcvarsx86_amd64.bat does indeed exist

About %Path2% lol. So my %Path% variable exceeded the 2048 character limit for a environment variable, which caused windows to go insane. To fix this, I moved some of the variables from %Path% into a variable called %Path2%. I then reference %Path2% in %Path% and that seems to work.

Here is a horribly unformatted text file containing my %Path% value: [link text][2]

Here is %Path2%
[link text][3]

Note that the contents of %Path2% are the first contents of %Path%, so it seems to be expanding correctly.

Also I should mention, since posting this question, I have moved on to another development machine which has a humble 2 versions of Visual Studio installed (2010 & 2013). I was able to compile and run the engine perfectly on this machine.

If you would like to continue debugging this issue for your own knowledge or to create a resource for others who may have this problem down the line, I still have the issue on my original machine, so I can help you in any way I can.

(To be clear, the above response was from the bugged machine)

If not you could just stop and I won’t be upset or anything.

Your call how we proceed :slight_smile:

Hi Mike,

At this point we suspect that the Path variable is where things are going bad. The vcvarsx86_amd64.bat file tries to add several entries to to the Path variable. If your Path variable is at its character limit, the batch file is unable to successfully add those entries. I am going to try to find a way to test this to verify it is what is happening.

Tim

You know what, I think your right. It all makes sense now, thinking of other problems I’ve had on this machine, this is very likely to be the problem.

I found this “solution” on stackoverflow basically what it does is it will create a bunch of small environment variables for each value in the %Path% variable. Then it clears the %Path% and adds references to the shortened environment variables. This seems like it would work (I haven’t done it yet, its a similar idea to my %Path2%), but it also seems pretty sketchy. Surely there is a better way to deal with this problem.

There’s gotta be. I can’t imagine the average Joe doing this when they run into this problem.

Is there to your knowledge a better way of dealing with %Path% length problems?

I have not yet experienced an instance where I maxed out the available character limit in a Path variable, so I haven’t been in this situation before. It certainly makes sense to replace portions of paths that appear repeatedly in the Path variable with shorter variable names. I generally try to avoid messing with environment variables unless I have no choice, but I think if I were going to try this to see if it will help, I would prefer to do it myself instead of having it done automatically by someone else’s program.

Unfortunately I was not able to find a “safe” way to test the theory that the problem is in the Path file being at its character limit. I wanted to find a way to temporarily artificially fill up the variable without causing any other problems to occur, and I didn’t really feel comfortable with any of the options that I came up with. I suppose one good thing that came out of this is that I now have a concrete reason for telling people that they should remove duplicate paths from their Path variable.