NVCC can not create temporary file


I’m on Vista-64bit and Visual Studio 2008. I’ve repeatedly installed CUDA 2.1, but nvcc always throws me an error:

1>------ Build started: Project: imageDenoising, Configuration: Release x64 ------
1>imageDenoising : warning PRJ0009 : Build log could not be opened for writing.
1>Make sure that the file is not open by another process and is not write-protected.
1>Compiling with CUDA Build Rule…
1>“C:\CUDA\bin\nvcc.exe” -arch sm_10 -ccbin “C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin” -Xcompiler "/EHsc /W3 /nologo /O2 /Zi /MT " -IC:\CUDA\include -I…/…/common/inc -maxrregcount=32 --compile -o x64\Release\imageDenoising.cu.obj imageDenoising.cu
1>nvcc fatal : Could not open input file C:\Users\MyUsername\AppData\Local\Temp/tmpxft_0000162c_00000000-1

I have tried in admin-mode and a different user, but no success… My collegue has a PC with the same configuration, but it works for him.

Any ideas?

Kind regards

I am facing the same problem with a PC (win vista 32). I don’t have this problem with 5 other PCs (win32, win64 and vista32). It is really strange !!! All PCs run cuda 2.3 and VS 2005 SP1.
Could somebody help me please??

I have the same problem too. I’m using Visual Studio 2005, CUDA 2.3, Vista Business, and I’m compiling with SCons. Running exactly the same command in a cygwin prompt works, however.
Using --keep switch doesn’t leave any temporary files.
Changing TEMP variable doesn’t help.
Using --verbose switch does leave some clues:

nvcc --cuda --keep --verbose --dont-use-profile -ccbin “c:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin” -Xcompiler -O3 -Xcompiler /nologo test.cu
#$ VSINSTALLDIR=c:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/…/…
#$ VCINSTALLDIR=c:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/…/…
#$ c:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/amd64/vcvarsamd64.bat

d:>call d:\temp/tmpxft_00000df4_00000000-2.bat
Setting environment for using Microsoft Visual Studio 2005 x64 tools.
‘x64’ is not recognized as an internal or external command,
operable program or batch file.
nvcc fatal : Could not open input file d:\temp/tmpxft_00000df4_00000000-1
scons: building terminated because of errors.
scons: unknown OSError exception code 0 - ‘C:\Windows\System32\cmd.exe /C “nvcc --gpu --keep --verbose --dont-use-profile -ccbin “c:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin” -Xcompiler -O3 -Xcompiler /nologo “test.cu””’: Error
scons: *** [test.obj] Error 127

So where is it getting the x64 from? I’m guessing it’s interpreting the batch file #2 incorrectly somehow, then it’s skipping the creation of batch file #1 - but how is it fixed?

I found the problem - it turns out SCons was polluting the PATH, LIB, and INCLUDE environment variables with rubbish (part of which was ‘x64’) - clearly they weren’t valid paths.
So check out what these variables are for you.
I’m not sure if it would be the same cause with Visual Studio, but it’s probably likely.

EDIT: Ah, and it turns out SCons is getting those environment variables from [User home directory]\Visual Studio 2005\Settings\CurrentSettings.vssettings (or adapt the path to whatever version you have), which does contain some bizarre pipes and stuff. That file is the source of the problem.

EDIT AGAIN: Well, the pipes actually represent the target platform… eg.
Win32||x64||Pocket PC 2003||Smartphone 2003|
It’s not parsing it properly!

Vista 64 bit, CUDA 2.3, Visual Studio 2008.

SDK samples compile just fine. My project won’t compile due to above mentioned temp file failure in nvcc.

My application uses Qt 4.5 and existed prior to CUDA integration, so I have not followed nVidia’s suggestion of copying their project file and filling it out with my information (not the most useful advice when trying to ADD Cuda support to an existing project).

Added the Cuda Build Rule file (which seems to be at least 90% of the magic voodoo of their sample projects), and nvcc kicks off whenever I drop a .cu file in my project. Then I get the same “fatal - cannot open input file c:\windows\temp\etc” message as above.

Fired up sysinternals Process Monitor and filtered on the reported filename, and it appears that nvcc just has a bug that only happens in certain code paths. In almost all situations, it works with a file called (in my case) “tmpxft_0000092c_00000000-1.bat”, but in the one case that is failing, it leaves off the file extension, and (big surprise) it can’t find “tmpxft_0000092c_00000000-1”.

So I see that these forums are not nVidia support forums, and that we’re supposed to go to the suppliers for help, but the supplier is nVidia, so how do we get anybody at nVidia to see this and fix it? I’m about to have several contracts fail because I can’t even get started on CUDA development, and I don’t see any progress being made on this old problem, even through multiple releases of Cuda.

Indeed the file tmpxft_00000###_00000000-1 wasn’t writen and therefor can’t be found. This is because vsvars32.bat fails (for whatever reason) and nvcc doesn’t check for errors and just keeps going. Any failure in this bat file will probably end in this stupid unhelpful error.

Try to run this bat file and see why it don’t run.

For me something in the spaces in the path or one of the variables ended in aparse error.

What worked for me so far:

In c:program files/microsoft visual studio 9.0\common7\tools\vsvars32.bat put perentacies on variables

I changed the lines around 13 to:

@if not “%WindowsSdkDir%” == “” (
set ‘PATH="%WindowsSdkDir%"bin;%PATH%’
set ‘INCLUDE="%WindowsSdkDir%"include;%INCLUDE%’
set ‘LIB="%WindowsSdkDir%"lib;%LIB%’

There may be other places but so far this is working.


Don’t forget to use the --verbose command line option so you can get more of an idea of the source of the error.

I also cheated and used a debugger to step through the execution of nvcc, so I could grab the contents of the temp file before it gets deleted. :)

I am on Vista x64 Business with VS2008 and am building the nvtt tools with x64.

I had to change these lines from (C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\vcvarsamd64.bat):


@if not “%WindowsSdkDir%” == “” (

set "PATH=%WindowsSdkDir%bin\x64;%WindowsSdkDir%bin\win64\x64;%WindowsSdkDir%bin;%PATH%"

set "INCLUDE=%WindowsSdkDir%include;%INCLUDE%"

set "LIB=%WindowsSdkDir%lib\x64;%LIB%"


to these:

[codebox]@if “%WindowsSdkDir%” == “” goto SetPaths

@set PATH=%WindowsSdkDir%bin\x64;%WindowsSdkDir%bin\win64\x64;%WindowsSdkDir%bin;%PATH%

@set INCLUDE=%WindowsSdkDir%include;%INCLUDE%

@set LIB=%WindowsSdkDir%lib\x64;%LIB%


Now the cuda source files compile in VS2008 just fine.

It seems that the IF statement isn’t getting parsed properly or something. Thanks to somethingsomethingsomethin for the hints!


I solved it by replacing the environmental varialble “TEMP=%USERPROFILE%\Local Settings\Temp” by “TEMP=%SystemRoot%\TEMP”.

i have the same problem here.

win 7 x64, visual studio professional 2008.

i have used cuda_vs_wizard_w64_2.2_beta2 in order to configure my visual studio.
I have read this topic, and i have done everything you said, without results.
i have changed all .bat files mentioned in their folders.

x64 extension for visual studio is installed as mentioned in another topic on this forum.
i’m executing as administrator, firewall and antivirus are disabled, temp-folder permission and control al set to full access for all users.

The error reported follows:

1>“C:\CUDA\bin64\nvcc.exe” -arch sm_10 -ccbin “c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin” -Xcompiler “/EHsc /W3 /nologo /Od /Zi /RTC1 /MTd " -I"C:\CUDA\include” -I"C:\ProgramData\NVIDIA Corporation\NVIDIA GPU Computing SDK\C\common\inc" -maxrregcount=32 --compile -o “x64\Debug\jaco_matrix.cu.obj” “e:\CUDA\prove\matrix_pitched\CUDAWinApp1\jaco_matrix.cu”
1>nvcc fatal : Failed to open output file ‘TEMP=C:\Windows\TEMP/tmpxft_00000bd8_00000000’
1>Internal error

what can i do ?

For me it was a case of vcvarsamd64 failing parsing the “if” statement.
Add --verbose to nvcc, and “echo i am here” style commands to vcvarsamd64.bat to see where the problem lies.

I have hard-coded the if to always execute and it now works for me OK.

It appears that if you have any double quotes in your path it might cause this issue. They are not required because the semicolon delineates paths in the path environment variable.