One of our CruiseControl.NET projects keeps intermittently failing because a msbuild task fails with
error MSB3231: Unable to remove directory "d:\Somewhere\Dir\Admin". The parameter is incorrect.
The corresponding msbuild script line is just
<RemoveDir Directories="$(DistributionDir)\Admin" Condition="Exists('$(DistributionDir)\Admin')" />
When I look at the state after the failed build, the directory contents was removed successfully, but the empty directory itself is left there. And the next build usually succeeds (having to remove just the empty directory). Note that the problem does not seem to be the usual “some other process (like antivirus) keeps locking the directory”, the error is not “access denied”, but a very strange “the parameter is incorrect”.
I monitored the build with SysInternals Process Monitor, and the result is strange – everything goes as expected, the contents of the directory is enumerated, deleted, and when the top-level directory enumeration finishes with “NO MORE FILES”, the directory is closed, and… nothing. No other operation gets to the process monitor:
10:04:09,9190557 MSBuild.exe 3516 QueryDirectory D:\Somewhere\Dir\Admin NO MORE FILES
10:04:09,9190928 MSBuild.exe 3516 CloseFile D:\Somewhere\Dir\Admin SUCCESS
The next (successful) build attempt is just a boring successful directory removal:
10:31:21,8616463 MSBuild.exe 1760 CreateFile D:\Somewhere\Dir\Admin SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
10:31:21,8616861 MSBuild.exe 1760 QueryDirectory D:\Somewhere\Dir\Admin\* SUCCESS Filter: *, 1: .
10:31:21,8617305 MSBuild.exe 1760 QueryDirectory D:\Somewhere\Dir\Admin SUCCESS 0: ..
10:31:21,8617589 MSBuild.exe 1760 QueryDirectory D:\Somewhere\Dir\Admin NO MORE FILES
10:31:21,8618209 MSBuild.exe 1760 CloseFile D:\Somewhere\Dir\Admin SUCCESS
10:31:21,8621579 MSBuild.exe 1760 CreateFile D:\Somewhere\Dir\Admin SUCCESS Desired Access: Read Attributes, Delete, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
10:31:21,8622118 MSBuild.exe 1760 QueryAttributeTagFile D:\Somewhere\Dir\Admin SUCCESS Attributes: D, ReparseTag: 0x0
10:31:21,8622408 MSBuild.exe 1760 SetDispositionInformationFile D:\Somewhere\Dir\Admin SUCCESS Delete: True
10:31:21,8622676 MSBuild.exe 1760 CloseFile D:\Somewhere\Dir\Admin SUCCESS
It seems for some reason, MSBuild/Windows detects some kind of invalid parameter error before the directory removal is executed, but I have no idea where to look. (I have also tried to run chkdsk, nothing was found. I have also removed and recreated the parent D:\Somewhere\Dir directory, nothing changed.)
So – any idea where the problem could be or how should I investigate further?
(I am not sure where this question should have gone, it is kind of somewhere between SO, Progs SE, Server Fault, Superuser…)
I can't say why it is failing, but if the folder is the only thing left over can the build complete correctly? If so, a workaround would be to specify ContinueOnError="True".
Tried a lot of things, but I couldn't figure out why this sometimes fails when the directory isn't empty; in our case the directory contains symbolic links if that matters. Anyway I don't like using ContinueOnError since that means when there is an actual error you don't know it, or have to do an extra check like <Error Condition="Exists... after every RemoveDir. The solution we use now is to explicitely empty the directory, after which msbuild doesn't seem to have any problems removing it:
<MSBuild.ExtensionPack.FileSystem.Folder Condition="Exists( $(PathtoEmpty) )"
TaskAction="RemoveContent" Path="$(PathtoEmpty)" />
<RemoveDir Directories="$(PathtoEmpty)" />
I've just encountered this error myself, it turned out that I had the offending folder opened in a Windows Explorer and that prevented it from being properly deleted.
May be this comes a little late, but I found the same error and the problem appears to be in the Exists condition. It seems that the evaluation of the condition somehow doesn't release the directory properly conflicting with the execution of the task.
By removing the condition the directory will be removed if it exists but the statement won't fail if it doesn't exist:
<RemoveDir Directories="$(DistributionDir)\Admin" />
The selected answer seems to be a hack,as it stops you from getting the actual error which might be a critical error.
I could use remove content instead of removing the directory as below.
<MSBuild.ExtensionPack.FileSystem.Folder Condition="Exists( $(OutputPath) )" TaskAction="RemoveContent" Path="$(OutputPath)" />
Related
By default TFS Build creates a "Index Sources & Publish Symbols" step in a Visual Studio Build definition. When the step's property "Path to publish symbols" is empty, everything works fine. But when setting the path to a local directory, the step generates the following error:
2015-09-25T11:00:09.7991491Z Executing the powershell script: C:\NewAgent\tasks\PublishSymbols\1.0.4\PublishSymbols.ps1
2015-09-25T11:00:10.0022755Z Find-Files -SearchPattern **\bin\**\*.pdb -RootFolder C:\NewAgent\_work\990dcb3f\Projects
2015-09-25T11:00:10.0491548Z Found 15 files to index...
2015-09-25T11:00:10.0491548Z Invoke-IndexSources -RepositoryEndpoint <repositoryEndpoint> -SourceFolder C:\NewAgent\_work\990dcb3f\Projects -PdbFiles <pdbFiles>
2015-09-25T11:00:10.6272794Z Invoke-PublishSymbols -PdbFiles <pdbFiles> -Share C:\DebugSymbols -Product EntityMapper -Version 20150925.14 -MaximumWaitTime 7200000 -MaximumSemaphoreAge 1440 -ArtifactName
2015-09-25T11:00:10.7348541Z ##[error]Can't infer artifact type from artifact location C:\DebugSymbols.
2015-09-25T11:00:10.7504779Z
2015-09-25T11:00:10.7504779Z Start: AssociateArtifact
2015-09-25T11:00:10.7504779Z ##[error]Artifact Type is required.
2015-09-25T11:00:10.7504779Z End: AssociateArtifact
The pdb files are published to the specified directory, so i don't really understand what is causing the error (which then causes the whole build job to fail).
When the step's property "Path to publish symbols" is empty, everything works fine.
Yes, because if symbols path is not set, the script only index sources, not publishing symbols.
But when setting the path to a local directory, the step generates the error
You need prepare your symbol store. In your case setup folder sharing and permissions.
In my case changing the "Path to publish symbols" from
//myserver/symbols
to
\\myserver\symbols
solved the issue. Don't know why this happend to me but ok... :)
I have a Wix Bootstrapper which installs/updates a number of MSIs. The MSI runs and updates fine, and the Bootstrapper will run fine for an initial install. I attempted to test Updating with the Boostrapper, however, and every time it will not even launch, and spawn a large number of processes and Setup_XXXXXXXXXXXXX_Failed.txt files in the %Temp% folder. each of these failed.txt files contain the following at the end:
[3098:23F8][2014-06-10T11:03:00]e000: Error 0x800705b4: Failed to open parent pipe: \.\pipe\BurnPipe.{087217E1-A4F3-4951-8319-06031945DA08}
[3098:23F8][2014-06-10T11:03:00]e000: Error 0x800705b4: Failed to connect to unelevated process.
[3098:23F8][2014-06-10T11:03:00]e000: Error 0x800705b4: Failed to run per-machine mode
The numbers vary between files but the errors remain the same.
I am running this Bootstrapper Exe with various command line arguments to tell it what MSIs to install and to provide it with Install Location and various arguments for Custom Actions.
This was reported at http://wixtoolset.org/issues/3890/. I just recently fixed it, the next WiX build shouldn't spawn a large number of processes.
However, the underlying problem was that Burn was receiving a command line that CommandLineToArgvW couldn't parse. You need to make sure that all double quotes are properly escaped, and that when using double quotes for spaces that there is an even number of them.
I'm having some strange issues with WiX on my local machine. The problem is intermittent, but after a few rebuilds of the solution, the WiX project starts throwing ICE validation errors.
If I go into my AppData\Local\Temp folder and delete all the temporary folders that contain the MSI, the solution compiles again. A short while later, the problem starts happening again. Having to keep clearing down the temp folders isn't a sustainable or satisfactory solution.
Has anyone else encountered this issue? The validation error codes seem to always be a combination of ICE30, ICE38, ICE64 and ICE91
Update:
As requested, here are the entries from the most recent failure:
error LGHT0204: ICE38: ICE Internal Error 1002. API Returned:
1615. error LGHT0204: ICE38: Error 2235: /OU.AppFramework.Includes.msi, _Profile, UPDATE Directory SET
_Profile=0 error LGHT0204: ICE64: ICE Internal Error 1001. API
Returned: 1615. error LGHT0204: ICE64: Error 2242:
OU.AppFramework.Includes.msi, _Profile, ALTER TABLE Directory ADD
_Profile SHORT TEMPORARY HOLD error LGHT0204: ICE91: ICE
Internal Error 1001. API Returned: 1615. error LGHT0204: ICE91:
Error 2242: OU.AppFramework.Includes.msi, _Profile, ALTER TABLE
Directory ADD _Profile SHORT TEMPORARY HOLD
Interestingly, this failure occurred before I left the office last night, and the solution compiled OK when I came in this morning. As it seems to centre on the temp directory where the MSI is build by WiX, could it be the build process locking the file?
Update 2:
And now we're back to over 600 errors, mostly repetition of this error:
error LGHT0204: ICE30: ICE Internal Error 100. API Returned: 1615.
error LGHT0204: ICE30: Error 2235: AppFramework.Includes.msi,
_ICE30SFN, SELECT Directory_Parent, Directory, DefaultDir, _ICE30SFN, _ICE30LFN FROM Directory WHERE
Directory.Directory=? AND Directory_Parent<>?
Update 3:
The problem still exists even after trying the suggestion by #limpan. There are a couple of warning given by light that are caused by the MSI output folder being locked when light tries to access the MSI:
Warning 549 The directory '\AppData\Local\Temp\2opu3hxf' is in use and cannot be deleted. light.exe
Try adding <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> to your WiX project file.
We've had the same issue for a while, and tried various workarounds including deleting the temporary files and setting the msbuild environment variable. These all appeared to work for a while, but eventually (sometimes after a few days) the problem would come back again.
I noticed that on my machine devenv.exe was the process that was locking the files that light.exe was trying to delete. I also stumbled across an unrelated thread which mentioned this project setting to make the WiX tools run out of process. I thought it could be worth a try and it appears to have cured the problem for us (so far...)
I had this issue as well and solved it in my environment.
Short answer:
Add the environment variable MSBUILDDISABLENODEREUSE=1 and restart Visual Studio
Long answer:
There was a warning during build that I first didn't see since I was too focused on the error:
Failed to delete temporary directory: C:\Users[username]\AppData\Local\Temp\5[uniqueFolderName] light.exe
I tried to remove the folder manually, but it was in use by another process.
It turns out that a lot of MSBuild.exe processes are started during build and then not closed again.
You can read more about the reason for that and what you can do to change that behavior in Stack Overflow question msbuild.exe staying open, locking files.
This thread: it and the solution in this thread:
I hope this answer can help someone else.
For ICE30: ICE Internal Error 100. API Returned: 1615, please try this and see if it works:
Close all instances of Visual Studio (may be just the one that matters but just in case)
Go to C:\Documents and Settings\\****user id****\\Local Settings\Temp\.
Clear all the folders that look like this .. 's12qgaks'. Basically it contains the MSI files
Open the solution and recompile.
Good luck!
I too had faced same the issue. In project properties, go to Tool Settings and click Suppress ICE validation.
For me MSBUILDDISABLENODEREUSE=1 (or /nr:false on command line) did not solve the problem.
But <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> did its job done.
I had the same issue. It turned out to be my Anti Virus software (OfficeScan) It had the intermediate files created by Light.exe locked and the validation process failed. Excluding the temp folder from virus scan or turning off ICE validation is not an acceptable solution.
If anyone has a better solution. I would like to know.
Observations:
On our Jenkins build server, we were seeing lots of msbuild.exe processes (~100) hanging around after job completion with around 20mb memory usage and 0% CPU activity.
Builds using different versions of stylecop were intermittently failing:
workspace\packages\StyleCop.MSBuild.4.7.41.0\tools\StyleCop.targets(109,7):
error MSB4131: The "ViolationCount" parameter is not supported by the "StyleCopTask" task.
Verify the parameter exists on the task, and it is a gettable public instance property.
Nuget.exe was intermittently exiting with the following access violation error (0x0000005):
.\workspace\.nuget\nuget install .\workspace\packages.config -o .\workspace\packages"
exited with code -1073741819.
MsBuild was launched in the following way via a Jenkins Matrix job, with 'BuildInParallel' enabled:
`msbuild /t:%Targets% /m
/p:Client=%Client%;LOCAL_BUILD=%LOCAL_BUILD%;BUILD_NUMBER=%BUILD_NUMBER%;
JOB_NAME=%JOB_NAME%;Env=%Env%;Configuration=%Configuration%;Platform=%Platform%;
Clean=%Clean%; %~dp0\_Jenkins\Build.proj`
After a lot of digging around and trying various things to no effect, I eventually ended up creating a new minimal solution which reproduced the issue with very little else going on. The issue turned out to be caused by msbuild's multi-core parallelisation - the 'm' parameter.
The 'm' parameter tells msbuild to spawn "nodes", these will remain alive after the build has ended, and are then re-used by new builds!
The StyleCop 'ViolationCount' error was caused by a given build re-using an old version of the stylecop.dll from another build's workspace, where ViolationCount was not supported. This was odd, because the CI workspace only contained the new version. It seems that once the StyleCop.dll was loaded into a given MsBuild node, it would remain loaded for the next build. I can only assume this is because StyleCop loads some sort of singleton into the nodes processs? This also explains the file-locking between builds.
The nuget access violation crash has now gone (with no other changes), so is evidently related to the above node re-use issue.
As the 'm' parameter defaults to the number of cores - we were seeing 24 msbuild instances created on our build server for a given job.
The following posts were helpful:
msbuild.exe staying open, locking files
http://www.hanselman.com/blog/FasterBuildsWithMSBuildUsingParallelBuildsAndMulticoreCPUs.aspx
http://stylecop.codeplex.com/discussions/394606
https://github.com/Glimpse/Glimpse/issues/115
http://msdn.microsoft.com/en-us/library/vstudio/ms164311.aspx
The fix:
Add the line set MSBUILDDISABLENODEREUSE=1 to the batch file which launches msbuild
Launch msbuild with /m:4 /nr:false
The 'nr' paremeter tells msbuild to not use "Node Reuse" - so msbuild instances are closed after the build is completed and no longer clash with each other - resulting in the above errors.
The 'm' parameter is set to 4 to stop too many nodes spawning per-job
I had the same issue. One old reference I found was in csproj files
<PropertyGroup>
<StyleCopMSBuildTargetsFile>..\packages\StyleCop.MSBuild.4.7.48.0\tools\StyleCop.targets</StyleCopMSBuildTargetsFile>
Also, I deleted the entire "Packages" folder that's located in the same folder as sln file after I closed the visual studio. It triggered VS to rebuild the folder and let go of the cache of the old version of stylecop
I've had the same issue for a while, builds were taking over 6 minutes to finish after some digging I found our it's node reuse fault so adding /m:4 /nr:false fixing my issue immediately
I have read numerous MSBuild posts, but none seem to refer to a strange problem I am having.
In MSBuild.xml (.NET 3.5) I have the following:
<ItemGroup>
<JavaScriptFiles Include="..\js\jquery.translator-ms-1.0.0-debug-all.js" />
</ItemGroup>
I receive an error:
Error 188 Failed to read in the data for the path/file [..\js\jquery.translator-ms-1.0.0-debug-all.js]. The most common cause for this is because the path is incorrect or the file name is incorrect ... so please check your path and file names.
However, if I use a file in the very same folder as follows with like properties:
The build completes successfully.
Does anyone know the "uncommon" causes for this error?
Possible reasons for being unable to open and/or read a file:
It doesn't exist.
It is open in another process (either for exclusive access, or it's locked).
You don't have NTFS permissions.
You want write access but the file has the read-only attribute.
The combined length of the path and (your quite long) filename exceeds MAX_PATH (260) characters.
The file is on a remote server and there's a network problem.
You've run out of kernel resources (e.g. too many files or handles in general open). This is quite unlikely.
You have a physical disk error.
It turns out that having the "debugger" statement within this JavaScript file was the "uncommon" error in this case.