I am automating testing with test complete and CCNet. I am getting the error message "process cannot access the file because it is being used by another process" while deleting some folders.
Is there any tools which can be used to unlock the file? I need to automate the unlock operation from CCnet
Haven't tried it myself but Unlocker might solve your problem. According to the FAQ it has a CLI:
Can Unlocker be run in command line? Yes! Unlocker -H for command line options.
Open task manager (ctrl + alt + del keys, select task manager), and see if you can find the name of your most recent application. If you find the application still running, but not visible, that means it switched to a background process, and likely has a bug/infinite loop. End the program task if you find it (you may very well find several) and that should clear up an file-IO errors. Hopefully this helped!
Related
Hi it's been few days having different Google Video Support Pluggin Installer tasks running
It happens the same this folk described here:
v78 of Chrome, Win 10, Every few hours a new instance of the video plugin installer exe kicks off and runs in parallel with the other(s) in place. Each instance takes ~ half a core and there is also always one MsiExec that terminates (similar usage) when the process is manually killed in task manager. The processes originate from \users\\appdata\local\google\update\install{GUID} - deleting the directories / files does no good, the updater downloads it after a few hours and tries again.
Video plugin installer is v 19.9.2600.0, 10,692,592 bytes
I'd like a way to stop this automated install or have it succeed. It seems I can do neither right now.
Any solutions to this in place?
Thank you in advance!
Quick Questions: 1) Are you behind an internet proxy server? 2) What is your security tool / malware suite / anti-virus? Can you
temporarily disable it whilst the installation finishes? 3) Have a look
in the "Deployment Mnemonic" section here? (for various causes of
deployment failure). 4) You can try to log in as another user and install fresh - see if that works. If it does, then you need a Chrome profile cleanup? 5) There is always the reboot. Always try that first to get it out of the way as the "one-size-doesn't-fit-anyone-at-all-really fix".
Technical: If I were to guess the problem is a custom action in the MSI that gets stuck "somehow". How many msiexec.exe entries are in the tast list and what context are they in? (user, system). There can be many msiexec.exe processes. Below is information on how to debug custom action failures (and other failures) by log analysis.
Logging: If this really is an MSI installer (Windows Installer), then you can try to enable MSI logging policy to create a log file for all MSI installations that run by following the instructions in the section "Globally for all setups on a machine" here. You will then find a log file in the TEMP folder after the installer has run (whenever that might be). Look for *.log files with a random name. Just sort the folder by change date to see the most recent files.
Open Temp folder: Windows Key > Tap R > Type: %TEMP% > Press: Enter.
Debugging: You can search the log for "value 3" first to find errors (see Rob Mensching's explanation in that link). You can find more information on interpreting MSI log files in the section "Interpreting MSI Log Files" here: Enable installation logs for MSI installer without any command line arguments
I executed an SSIS package using SSDT and Visual Studio. When I try to execute another package I get an error saying "The process cannot access the file XXXX.ispac because it is being used by another process". I have tried rebooting but that is a pain in the behind. How can I work around this error?
While developing an SSIS package I got the error “The process cannot access the file ‘.ispac’ because it is being used by another process”*.
Tried to close SSDT and run it again but, we still got the same error while compiling. Then, after searching over internet, we got the solution:
Solution :
Go to Task Manager–> Details Tab.
Locate the process “DtsDebugHost.exe“.
Kill this process.
There might be multiple instances of this process. Kill all of them.
After doing this, I tried to compile the package again and it was successful.
You might check your patch level. I saw this much more frequently with the 2015 release of SSDT but hasn't bit me too often since then.
Finding and killing a process
Sysinternals has an excellent tool called Process Explorer. It's free, doesn't require an install and helps you see what all is happening on your computer. In this case, you want to find the process that has its grubby finger on your file (MyProject.ispac) and then kill it.
https://helpcenter.gsx.com/hc/en-us/articles/115015880627-How-to-Identify-which-Windows-Process-is-Locking-a-File-or-Folder
A different approach that doesn't require getting Process Explorer running is to change your build from Development to Release (and back again).
Chicken Sandwich No Pickles asks via comments
How can I convert from Development to Release?
In your tool bar, click where you see Development in the dropdown (or right click the solution in Solution Explorer)
In Configuration manager, you may/may not have a listing available under Configuration. Earlier versions of SSIS projects had dev/release configurations predefined but it looks like newer ones do not. If you do not have another option, make one via <New...>
Copy the values from the Development configuration et voilà!
Now when you debug, ProjectFolder/bin/Release will exist and the dtsdebughost.exe will latch onto that file and release the pointers to ProjectFolder/bin/Development/Project.ispac
Here's a simple script you can run in powershell to kill all ssis debug process "DtsDebugHost.exe" and unlock the ispac file.
unlock_ispac.ps1
# if ssis error with 'The process cannot access the file ‘.ispac'
# run this file in powershell
get-process | foreach {
$pName = $_
if($pName.Name -eq "DtsDebugHost") {
$pName.Kill()
}
}
I'm just a day new at this, so sorry for asking stupid questions...
2 issues...
Can I save a whole project in one file in VS?
I'm trying to run a simple project, but get the error:
Warning 1 Could not copy "obj\Debug\WindowsApplication9.exe" to "bin\Debug\WindowsApplication9.exe". Beginning retry 1 in 1000ms. The process cannot access the file 'bin\Debug\WindowsApplication9.exe' because it is being used by another process. WindowsApplication9
What does "being used by another process" mean?
the project is not open anywhere else when I'm trying to run this, so I don't understand...
Pls help.
Check task manager for an already running WindowsApplication9.exe. You can't build your project if it is still running. Your Me.Hide call sounds like the culprit if your app is running in task manager and you can't see the window.
I had a similar issue to this when attempting to run unit tests. The culprit turned out to be multiple MSBuild processes locking the files. I nuked them via Task Manager, and was able to run my tests again.
Box was sitting on breakpoint last night when I went to bed. This morning there are service updates which shuts down VS. I reopen VS, do some work to prep for debug, then build. Build fails with: error MSB3231: Unable to remove directory "csx\Debug\". Access to the path 'Microsoft.WindowsAzure.Diagnostics.dll' is denied.
VS is running in Admin mode.
Sometimes Azure Emulator doesn't behave as it shoud and keeps running some processes. You can examine this with ProcessExplorer.
In such cases I re-srtart both emulator services, but in your case restart of the Compute emulator should be enough.
In Visual Studio 2013 I was able to fix this same error by unloading the Azure project and then reloading and building, this seemed lot easier than the answers already provided hence the reason I am answering an already answered question
The best solution I have seen to that is to create a “Post Build Event” to remove the read-only attribute:
attrib -R "$(TargetDir)*.*" /S
That should fix the problem
I have this problem constantly. The following has helped me to clear the issue up:
Disable antiviruses
Disable Windows Search
Disable any file-scanning service
Clean the solution.It will resolve the problem.
The problem is usually that another program is holding onto those directories/files. Closing the offending program ought to free up access and let the Azure build tasks run again.
In my case just now, it was Windows Grep. Another possible culprit is IE (see: http://www.dotnetnoob.com/2013/09/the-unable-to-remove-directory.html).
If needed, you should be able to figure out which program it is by using Process Explorer from the Sysinternals suite, which can show you open file handles. From the Process Explorer menu bar, hit "Find" -> "Find Handle or DLL...", enter part of the path that the Azure build's complaining about, and check the resulting list of programs.
Using Visual Studio 2010 beta, when I run my application within the IDE for debugging, it works perfectly the first time. However, after closing the debug session, either by closing the application or clicking the stop debugging button, all subsequent attempts to debug the application fail with:
Error 1 Unable to copy file "obj\Debug\Application.dll"
to
"bin\Debug\Application.dll".
The process cannot access the file
'bin\Debug\Application.dll'
because it is being used by another
process.
Handle.exe from SysInternals does show handles open, but even if I close the handles, the error doesn't go away. Any attempts to delete the file manually result in an "Access Denied" error message.
To fix this, I have to completely restart Visual Studio, afterwhich the Debug session will work once and stop again.
I'm not entirely sure when this started happening, but I'm pretty sure it's fairly recently.
UPDATE: After I force close the handles on Application.dll, I get the following error from VS:
Error 1 Unable to copy file
"obj\Debug\Application.dll"
to
"bin\Debug\Application.dll".
The requested operation cannot be
performed on a file with a user-mapped
section open.
What the heck is a "user-mapped section"??
UPDATE 2: It appears that this problem occurs when I have a Form open in Design view when trying to debug. I'm going to do some more troubleshooting and then post my results.
UPDATE 3: I think I've narrowed it down to a form using a UserControl.
To be honest with you, it sounds like a bug in VS2010. For some reason it isn't closing the open handles when the debugger stops. Killing the VS process automatically closes those handles, allowing you to access the file again. As a work around, you might look at unlocker it's free and works exceptionally well. I know that's not a great answer, but it should be faster than restarting VS. You might to consider sending a bug report too...
Unlocker doesn't work on 64-bit OS, LockHunter does though.
Here is how I solved this problem
*I open the project Properties,
*select the build tab,
*Clear the output path,
*and buid(this will create the dll in the root folder)
*come back to the output path and select browse(browse to the bin directory to either debug/release)and voila!
As per Error: Cannot access file bin/Debug/… because it is being used by another process answer by TarmoPikaro, sometimes Visual Studio creates multiple msbuild.exe ghost processes, which persist after build. These ghost processes seem to be causing file locks.
Solution 1 - Kill ghost MSBuild.exe's
Killing msbuild.exe's is a one time solution, it needs to be done per build basis.
You can kill the processes as follows mrtumnus:
taskkill /f /im MSBuild.exe
Solution 2 - Disable parallel builds in Visual Studio
You can disable parallel build once and for all:
Tools > Options > Projects and Solutions > Build and Run > "maximum numbers of parallel project builds" - by default it has value of 8, switch it to 1.
Of course builds are bit slower now, but mileage may vary depending on your use case.
This is related to
Error: Cannot access file bin/Debug/... because it is being used by another process
I've seen the Windows Indexing Service cause this. Disabling it helped. Virus scanners can also be at fault. Mutliple Application.Close() calls can supposedly cause this, too.
Of course, since it always works the first time, I suppose these are unlikely.
Had the same problem. The following things helped
Closing all design files while debugging
using unlocker
Also my application opens a port. While debugging an exception was thrown and program quit. While ending the program I closed the port. That helped too.
But definitely, bug with VS2010.
I encountered the same problem and in my case I had the file in question open in Visual Studio. Closing all files helped.
I faced the same error and I was stuck in it for many days. Finally resolved the issue.
I was working on a project that had many class libraries added in it. I added the reference of these libraries to my main project and mistakenly added reference to same project to itself. So when I removed self reference, it worked.
I had this issue myself. I had the project properties window open and that apparently creates a file lock. Even after I closed the window the file lock remained and I had to restart VS.
P.S. I'm using VS 2019. Just posting this for anyone having the issue I had and coming to this post.
If you get this error on VS Code;
Click on terminal screen and use "Ctrl + C" for stop running.