Home Dashboard Directory Help
Search

Tracker.exe: Response file ... not found. by ateece


Status: 

Closed
 as Won't Fix Help for as Won't Fix


35
1
Sign in
to vote
Type: Bug
ID: 540902
Opened: 3/10/2010 6:53:15 AM
Access Restriction: Public
1
Workaround(s)
view
27
User(s) can reproduce this bug

Description

At the end of my builds (which are marked as partially succeeded) I get 103 errors of;
Tracker.exe: Response file C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\a23629cf042a4b358c6d971f991281a5.rsp not found

- I am using the x86 build engine because the 64 bit build engine crashes when using WIX
- For every build the GUID changes
- If I monitor C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp I can see that no RSP files are ever created
- This error does not show in the build log even with diagnostic logging on
- The build log does show TrackerLogDirectory = obj\Release\
Details
Sign in to post a comment.
Posted by Binary Ben on 11/18/2011 at 1:11 PM
I can isolate this specifically to adding both an x86 and an x64 variant of a WIX3.5 project so that I build both flavours of the build simultaneously in a Team Build on a Team Agent. This problem has only been introduced since I added the mirrored partner (x86) version to the build. I'd suggest that a recreate would be to create a project that is an AnyCPU output, add a WIX project that installs the dll, then create another WIX project that installs the x64 variant and then run this on a team build agent.
Posted by Microsoft on 8/4/2011 at 12:13 PM
Thanks everyone for your reports.

We have a fix in the pipeline for this issue, which we hope to make the next release.

The trigger for the error is that the GenerateResource task must be run during the build in such a way that we embed FileTracker (a tool we have been using for up-to-date check) in the process itself.

This occurs when targeting 4.0 (or 3.5 on a 32-bit machine) and when targeting 3.5 on a 64-bit machine (running 64-bit MSBuild).

To work around the error, you can either set TrackFileAccess=false:
<PropertyGroup>
     <TrackFileAccess>false</TrackFileAccess>
</PropertyGroup>
- or -
/p:TrackFileAccess=false (on the MSBuild command line)

If you're on a 64-bit machine and targeting 3.5 exclusively, the error should also go away if you start using 32-bit MSBuild.

TrackFileAccess=false works around the error by turning off the use of FileTracker. The downside is that that means the you will no longer be able to use FileTracker-based up-to-date check, so your VS 2010 C++ projects and your GenerateResource task invocations will now always build, even when there have been no changes. This generally causes a cascading rebuild for the managed compilers as well, since they consume the .resources files.

Chuck England
Program Manger - VSPro
Posted by 9rune5 on 1/18/2011 at 10:47 PM
I added a WiX to our project file, and now we're also struck by this error. We have two targets: Release|Mixed platforms and Release|x64.

MS: Please fix.
Posted by Will Sullivan on 10/6/2010 at 9:07 AM
This connect is still active: https://connect.microsoft.com/VisualStudio/feedback/details/508650/tracker-response-file-not-found?wa=wsignin1.0# also has a workaround.
Posted by Will Sullivan on 10/1/2010 at 12:16 PM
Add me to the list of people getting this stupid error.
Posted by ThomasIsr on 7/29/2010 at 12:01 PM
Chuck,

Should I take you last comment to mean that there is no longer any point in supplying you with a process Monitor log file? I am happy to try to produce one, if you will take a look at it, but don't want to waste my time if you won't. In case you would like a log file, please let me know how to get that to you.

Also: Just to make sure that you understand the ramifications of this: I am using team build and so the information that the build appears to have failed (though you claim it is fine) will go into the TFS database and I guess pretty muc make the concept of team builds pointless since they will all appear to have failed. (Can't even begin to think about how this will mess up Lab Management).

Is there some way to get team build to ignore this specific problem??
Posted by Microsoft on 7/20/2010 at 9:58 AM
It appears that this issue is closely related to, and believe to be the same issue as another issue that has already been reported internally. The issue is that tracker attaches itself to a a process and monitors the build. After the build is complete, some threads are still cleaning up and cause false errors to occur.

The issue does not fail the build, but unfortunatley indicates that something may have gone wrong.

There is no clear way that we can fix this issue at this time, that would not have major testing implications.

As such, we are not planning to fix this at this time. We will continue to consider a fix for a furture release of the product.

Thanks,

Chuck England
Visual Studio
Program Manager - MSBuild
Posted by MGlickVA on 7/13/2010 at 12:51 PM
I also have this problem. If I use TFS Build only build x86 or only build x64 I don't received this error. However, if I configure it to build both platforms, I receive the error. I have the same problem for multiple project/solution build configurations.
Posted by Microsoft on 7/7/2010 at 4:33 PM
Petr,

I have followed the suggested repro steps to the letter, but I do not see the indicated error.

In order to take action on this, we would need to be able to reproduce this, or have enough to go on from logs or other diagnostic information to point us to where the issue is.

During the build, the response files are written to a temp directory. If these fail, due to for example a permission error, then you would see an error similiar to the one described.

We would like to be able to address the issue, but if we cannot isolate this issue to a specific cause, then we have not choice but to resolve the issue as "No Repro".

If you are still able to reproduce the issue, can you attach Process Monitor (you can download from here: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx), start the build, and then save "all" events as a .PML file? In addition, we would need the diagnostic log from that build (msbuild /v:d). A copy of the project zipped up would be nice as well, so that we know we have the exact project that goes with the build.

We are currently working to reduce the number of open issues. As such, we need to get this information by 7/14/2010 in order to continue looking at the issue. If we have not received the information by that time, we would need to resolve the issue as "Not Repro".

Thanks,

Chuck England
Visual Studio
Program Manager - MSBuild
Posted by Petr Vones on 6/25/2010 at 5:02 AM
I think I found a reproducible test case for this issue.
Environment:
Windows Server 2003 R2 SP2 Std 32 bit (running inside Virtual PC)
Visual Studio 2010 Professional (C#, F#, Pex, Moles)
Logged as an Administrator

Steps to reproduce:
1. Create New Windows Forms Application (targeting .NET 4.0, "Create directory for solution option" is unchecked)
2. Add new AboutBox to the project (via Add New Item -> Windows Forms -> About Box)
3. File | Save All
4. File | Close Solution
5. Run "Visual Studio Command Prompt (2010)"
6. Change current directory to the directory the WindowsFormsApplication1.sln file is located
7. Type and run command: MSBuild WindowsFormsApplication1.sln /t:Rebuild /p:Configuration=Release

The build output in console window ends with:

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:01.04
Tracker.exe: Response file C:\Documents and Settings\Administrator\Local Settings\Temp\64c9e90b5f314835b713df01b467f3d7.rsp not found.
Posted by Petr Vones on 6/25/2010 at 4:09 AM
Same issue:

Tracker.exe: Response file C:\Documents and Settings\Administrator\Local Settings\Temp\614afab70f0b4b8dbb5e6079a2861cc3.rsp not found.

Windows Server 2003 R2 Std 32 bit
VS 2010 Professional
no TFS, just complex MSBuild build scripts to build multiple solutions started from Command Prompt
Posted by PashaPash on 5/20/2010 at 3:53 AM
Same issue,
Tracker.exe: Response file C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\fbf6fbf2fa1c4659b155a662ff3cc349.rsp not found.

Building on Win 2008 x64, TFS 2010.
Build platform set to Auto.
Posted by MarcoPiazzi on 5/11/2010 at 8:54 AM
We have the same issue:
Tracker.exe: Response file C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\383db15ea1c044f2a83c1c14f3b77328.rsp not found.
We are using TFS/VS2010 Ultimate RTM x64.
I have set the build platform to x86.
Posted by G Howlett on 4/7/2010 at 4:19 AM
I have exactly the same issue. Tracker.exe: Response file C:\Users\TFSService10\AppData\Local\Temp\27ed2ecb195c4dc79678f2d48e39069d.rsp not found.

I am using WiX 3.5.1602.0 x64 - TFS/VS2010 RC.

When doing a Team build I also have to set the build platform to x86 (not Auto) in advance settings, however doing so produces the error you describe.
Posted by Microsoft on 3/16/2010 at 12:21 PM
This issue unfortunately does not meet the bar to fix for VS 2010 RTM, however we are interested in investigating it further, in order to possibly find a fix for a future release.

If you could gather and attach a Process Monitor trace of your computer during a failed build, that may help us narrow down the issue.

Thanks,
Sara
Posted by ateece on 3/11/2010 at 3:21 AM
This problem is only affecting one of our solutions (the biggest). Other solutions are not being affected.

Are there any other logs that I can look at/copy?
Posted by Microsoft on 3/10/2010 at 8:36 PM
Thanks for reporting the issue.
In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided.

Could you please attach a demo zipped project file to this feedback through our site to help us reproduce the issue?

Thanks again for your efforts and we look forward to hearing from you.
Visual Studio Product Team
Sign in to post a workaround.
Posted by Chuck England - MSFT on 9/22/2011 at 7:38 AM
To work around the error, you can either set TrackFileAccess=false:
     <!-- for example in the project file -->
     <PropertyGroup>
         <TrackFileAccess>false</TrackFileAccess>
     </PropertyGroup>
- or -
     /p:TrackFileAccess=false (on the MSBuild command line)

TrackFileAccess=false works around the error by turning off the use of FileTracker. The downside is that that means the you will no longer be able to use FileTracker-based up-to-date check, so your VS 2010 C++ projects and your GenerateResource task invocations will now always build, even when there have been no changes. This generally causes a cascading rebuild for the managed compilers as well, since they consume the .resources files.

If you're on a 64-bit machine and targeting 3.5 exclusively, the error should also go away if you start using 32-bit MSBuild.

File Name Submitted By Submitted On File Size  
Tracker Error.zip (restricted) 3/18/2010 -