I have a simple WinForms solution in VS 2010. Whenever I build it, output file (bindebugapp.exe) ends up locked, and subsequent builds fail with a message like
'The process cannot access the file 'binDebugapp.exe' because it is being used by another process.' The only way to build the project is to restart VS after every build, which is very awkward.
I have found this old blog post http://blogs.geekdojo.net/brian/archive/2006/02/17/VS2005FileLocking.aspx - it seems that the problem is really old. Does anyone know what is happening here, or at least some workaround?
Update
I don't actually run the file. Locking happens after build, not after debug (i.e. start VS - build - build - fail!)And I tried turning antivirus off. It doesn't help.
Update 2
Process Explorer shows devenv.exe having loaded the file (in DLLs, not in Handles). It seems like some glitch during build prevented the unloading, but the (first) build completes without any messages other then '1 succeeded, o failed'/
Nevermind
NevermindNevermind
88711 gold badge1010 silver badges1515 bronze badges
16 Answers
Had the same issue, but found a solution (thanks to Keyvan Nayyeri):
But how to solve this? There are various ways based on your project type but one simple solution that I recommend to Visual Studio add-in developers is to add a simple code to their project's build events.
You can add following lines of code to the pre-build event command line of your project.
StormenetStormenet
16.1k77 gold badges4848 silver badges6464 bronze badges
It is not a virus issue. It is visual studio 2010 bug. It seems the issue is related to using visual studio gui designer.
The workaround here is to move locked output file into another temporary one in pre-build event. It make sense to generate temporary file name randomly.
In case of using constant temporary file names you will just postpone locks:
That workaround works exactly once
I have also found a solution with 2 temporary files that works exactly 2 times.
Vladimir DatsyukVladimir Datsyuk
The problem occurred to me too.
My scenario was this : Running windows 7 (But might also happened in Windows XP) and while working on a project with WPF User Control I could build all of the times, Until opening the XAML file of the User Control - From there, I've got one build, and then the files are locked.
Also, I've noticed that I was running Visual Studio (Devenv.exe) as Administrator, I've started to run Visual Studio without Administrator privileges and the problem was gone!.
Let me know if it helped you too. Good luck.
Shani ElharrarShani Elharrar
I've seen this on either a greedy virus scanning software, or if app.exe isn't shutting down properly. Make sure the process isn't still running.
McAdenMcAden
11.1k44 gold badges3030 silver badges5555 bronze badges
What about virus scanners on your machine? Can you see any processes that are holding handles to your file (use Process Explorer to find out)?
Maybe there is 'app.exe' visible in your process list, i.e the last version you debugged is still running? When you develop applications which have multiple threads, this may happen if you don't
join all of them.
I had the same problem and I found out, that VS only locks the exe when I opened a Form or UserControl in VS before building.The solution was quite easy, I just had to close any Form/UserControl before I build the solution and it worked.
EnyraEnyra
7,6821111 gold badges3030 silver badges4343 bronze badges
Base on the great Stormenet answer, I put up a small script that should work in all cases.
Here is the code to put in the pre build event text box
Here is the script to copy in the file
$(SolutionDir)BuildProcessPreBuildEvents.bat (of course you can modify this path):
Community♦
Patrick from NDepend teamPatrick from NDepend team
10.6k22 gold badges4646 silver badges6060 bronze badges
There is also a known issue 533411 where the usage of automatically updating build numbers can cause the locking issue. Workaround from bug report
Temporary workaround would be disable assembly version update after the rebuild. In AssemblyInfo.cs file, remove the wild card from the AssemblyVersion attribute, for example: Robert MacLeanRobert MacLean
replace this: [assembly: AssemblyVersion('1.4.*')] [assembly: AssemblyFileVersion('1.4')] with this: [assembly: AssemblyVersion('1.4.0.0')] [assembly: AssemblyFileVersion('1.4.0.0')]
28.4k2424 gold badges9494 silver badges143143 bronze badges
I had this problem and resolved it with some custom code. See here: Visual Studio 2010 build file lock issues
Compile the utility in the accepted answer and reference it during the build step as described to workaround the problem. I still turn off VS 2010 at lunch to clean up the morning's work.
The reason for the custom code was that the often recommended solution only worked once and then the renamed files were also locked, preventing the rename. Here we just append the>33 gold badges4949 silver badges8181 bronze badges
The only thing that worked for me was to quit Visual Studio 2012, delete the BIN and OBJ folders for the project having problems, and to open Visual Studio again.
Problem solved.. Until next time.
willemwillem
9,8921818 gold badges6464 silver badges103103 bronze badges
If your $(TargetPath) points to a DLL that uses COM ensure you have a default constructor. Not sure why the default constructor is not inferred there. Adding the default constructor worked for me in this scenario.
OnyximoOnyximo
Closing visual studio, reopening, and reloading the most recent solution works around the problem for me. (Visual Studio 2013 Ultimate)
JayJay
11.1k33 gold badges3030 silver badges6060 bronze badges
I ran into the same thing developing xamarin apps in VS2017.
It happened to be Windows Defender locking the exe/dll with devenv.exe.
You can go to Win Defender and add
to the process exclusion list.
michael gmichael g
This is the solution I find out
Note: You can re enable this option again with no problems.
Massimiliano Kraus
2,48244 gold badges1616 silver badges3333 bronze badges
RamankingdomRamankingdom
1,24311 gold badge77 silver badges1616 bronze badges
I managed to fix this problem by disabling McAfee LiveSafe real time scanning. My .exe file would lock up like the OP describes and I would have no way to remove the file, which meant I could not build the solution. After disabling the McAfee feature the problem was gone.
Then I of course went on to fully uninstall McAfee, which was only installed because my PC is new and it came with the program already installed.
Shared File Is Locked
Konrad SkagerbergKonrad Skagerberg
I have created a new blank solution and added all the old files to it. This somehow solved the problem.
NevermindNevermind
88711 gold badge1010 silver badges1515 bronze badges
Not the answer you're looking for? Browse other questions tagged visual-studio or ask your own question.
This question already has an answer here:
Is there any way to check whether a file is locked without using a try/catch block?
Right now, the only way I know of is to just open the file and catch any Hossein Narimani Rad
System.IO.IOException .
21.9k1212 gold badges6868 silver badges9898 bronze badges
ricreericree
12.2k1313 gold badges3030 silver badges2727 bronze badges
marked as duplicate by Rob♦ c#May 9 '16 at 5:08
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
12 Answers
No, unfortunately, and if you think about it, that information would be worthless anyway since the file could become locked the very next second (read: short timespan).
Why specifically do you need to know if the file is locked anyway? Knowing that might give us some other way of giving you good advice.
If your code would look like this:
Then between the two lines, another process could easily lock the file, giving you the same problem you were trying to avoid to begin with: exceptions.
Lasse Vågsæther KarlsenLasse Vågsæther Karlsen
300k8686 gold badges536536 silver badges729729 bronze badges
When I faced with a similar problem, I finished with the following code:
Soul_Master
5,08466 gold badges5050 silver badges8686 bronze badges
DixonDDixonD
4,75933 gold badges2424 silver badges4646 bronze badges
The other answers rely on old information. This one provides a better solution.
Long ago it was impossible to reliably get the list of processes locking a file because Windows simply did not track that information. To support the Restart Manager API, that information is now tracked. The Restart Manager API is available beginning with Windows Vista and Windows Server 2008 (Restart Manager: Run-time Requirements).
I put together code that takes the path of a file and returns a
List<Process> of all processes that are locking that file.
UPDATE
Here is another discussion with sample code on how to use the Restart Manager API.
Markus Safar
4,92044 gold badges2020 silver badges3838 bronze badges
Eric J.Eric J.
122k4848 gold badges277277 silver badges499499 bronze badges
You can also check if any process is using this file and show a list of programs you must close to continue like an installer does.
Markus Safar
4,92044 gold badges2020 silver badges3838 bronze badges
AralmoAralmo
Instead of using interop you can use the .NET FileStream class methods Lock and Unlock:
FileStream.Lockhttp://msdn.microsoft.com/en-us/library/system.io.filestream.lock.aspx
FileStream.Unlockhttp://msdn.microsoft.com/en-us/library/system.io.filestream.unlock.aspx
Sergio VicenteSergio Vicente
You could call LockFile via interop on the region of file you are interested in. This will not throw an exception, if it succeeds you will have a lock on that portion of the file (which is held by your process), that lock will be held until you call UnlockFile or your process dies.
Sam SaffronSam Saffron
91.5k6969 gold badges288288 silver badges482482 bronze badges
A variation of DixonD's excellent answer (above).
Usage:
Unlocking factions in game's menu is his work.NTF Launcher:NTF comes with a launcher making playing the md just a matter of 2 clicks. The faction war 3.7 release. Select campaign, campaign mode (sp or mp) and you are good to go! For the same reason editing user.script.txt is not needed any more to play NTF. 3.5 launcher is made fully in Visual Basic, using no batch or script files, in an attempt to help users experiencing problems with their anti-virus.
Markus Safar
4,92044 gold badges2020 silver badges3838 bronze badges
TristanTristan
Here's a variation of DixonD's code that adds number of seconds to wait for file to unlock, and try again:
Markus Safar
4,92044 gold badges2020 silver badges3838 bronze badges
live-lovelive-love
19.8k1010 gold badges9292 silver badges9090 bronze badges
Then between the two lines, another process could easily lock the file, giving you the same problem you were trying to avoid to begin with: exceptions.
However, this way, you would know that the problem is temporary, and to retry later. (E.g., you could write a thread that, if encountering a lock while trying to write, keeps retrying until the lock is gone.)
The IOException, on the other hand, is not by itself specific enough that locking is the cause of the IO failure. There could be reasons that aren't temporary.
Sören KuklauSören Kuklau
15.4k55 gold badges3838 silver badges7272 bronze badges
You can see if the file is locked by trying to read or lock it yourself first.
Please see my answer here for more information.
Community♦
Brian R. BondyBrian R. Bondy
261k102102 gold badges548548 silver badges595595 bronze badges
Markus Safar
4,92044 gold badges2020 silver badges3838 bronze badges
thom schumacherthom schumacher
Markus Safar
4,92044 gold badges2020 silver badges3838 bronze badges
Bart CalixtoBart Calixto
13.1k88 gold badges6464 silver badges104104 bronze badges
Not the answer you're looking for? Browse other questions tagged c#.netiofilelock or ask your own question.
Windows won’t allow you to modify files that open programs have locked. if you try to delete a file and see a message that it’s open in another program, you’ll have to unlock the file (or close the program).
In some cases, it may not be clear which program has locked a file. Sometimes, a program or background process may have finished with a file, but not unlocked it properly when it was done. In that case, you must unlock the stubborn file or folder in order to modify the file.
Note: Unlocking certain files and deleting them can cause problems with open programs. Don’t unlock and delete files that should remain locked, including Windows system files.
Unlock a File with Process Explorer
You can unlock a file by using the excellent Process Explorer task manager. We’ve covered Process Explorer in detail before, so here we’ll just dive right into how to unlock a file. You won’t need to install it first—it’s a portable app—but you will need to run it with administrative privileges. You actually can do this from within Process Explorer by clicking the “File” menu and selecting “Show Details for All Processes.”
Next, click the “Find” menu and select “Find Handle or DLL.” (Or press Ctrl+F.)
Search for the name of the locked file or folder.
Select the locked file or folder and you’ll see the handle in the details box at the bottom of the Process Explorer window.
Right-click the handle and select “Close Handle.” If multiple processes are listed in the search window, you’ll have to repeat this step to close the handle for each process.
You can now delete or modify the file normally.
IObit Unlocker
IObit Unlocker is a useful utility for unlocking files, and it’s free. It even puts a command for unlocking files right on the context menu. After you install the program, you can right-click a stubborn file or folder and select “IObit Unlocker” to open the app with that file selected.
You’ll see a list of processes that have locked the file or folder. You can quickly unlock the file by clicking the “Unlock” button. This method unlocks the file while leaving the process running. Note that this may cause problems if a process expects exclusive access to a file.
You can also click the “Forced Mode” checkbox and then click “Unlock” to forcibly close whatever program is locking access to the file. You’ll lose any unsaved data in any program killed this way.
Once the file is unlocked, you can delete, move, or rename it normally. In fact, the IOBit Unlocker application has easy “Unlock & Delete”, “Unlock & Rename”, and “Unlock & Move” options. Just click the arrow to the right of the “Unlock” button.
Restart Your Computer
Generally, a file won’t be locked after you restart your computer—unless the program that locked it is a startup program that locks the file as soon as you log in. If you have a stubborn file or folder and don’t want to use any of the tricks here, you can try restarting your computer. You should be able to delete, move, or rename the file as soon as Windows comes back up.
RELATED:Three Ways to Access the Windows 8 or 10 Boot Options Menu
If the file is being locked by a startup program, you can boot to safe mode to delete it instead. If you’re on Windows 7, press the F8 key during the startup process and select Safe Mode to boot into safe mode. If you’re using Windows 8 or 10, you’ll have to access safe mode from the boot options menu. Delete (or move) the file in safe mode and restart your computer.
There are a variety of other ways to delete locked files. For example, you could use a program to schedule a file deletion when you next restart your computer—the file will be automatically deleted when you reboot. But we’ve found it much easier using one of the methods we’ve detailed here.
Learning has never been so easy!
Investigating virtual machine file locks on ESXi/ESX (10051)
Details • A virtual machine cannot power on. • Powering on a virtual machine fails. • Unable to power on a virtual machine. • Adding an existing virtual machine disk (VMDK) to a virtual machine that is already powered on fails with the error:
Failed to add disk scsi0:1. Failed to power on scsi0:1
• When powering on the virtual machine, you see one of these errors: o Unable to open Swap File o Unable to access a file since it is locked o Unable to access a file since it is locked o Unable to access Virtual machine configuration • In the /var/log/vmkernel log file, you see entries similar to:
WARNING: World: VM xxxx: xxx: Failed to open swap file : Lock was not free
WARNING: World: VM xxxx: xxx: Failed to initialize swap file • When opening a console to the virtual machine, you may receive the error:
Error connecting to .vmx because the VMX is not started
• Powering on the virtual machine results in the power on task remaining at 95% indefinitely. • Cannot power on the virtual machine after deploying it from a template. • The virtual machine reports conflicting power states between vCenter Server and the ESXi/ESX host console. • Attempting to view or open the .vmx file using the cat or vi or command reports the error:
cat: can't open '[name of vm].vmx': Invalid argument
Solution The purpose of file locking To prevent concurrent changes to critical virtual machine files and file systems, ESXi/ESX hosts establish locks on these files. In certain circumstances these locks may not be released when the virtual machine is powered off. The files cannot be accessed by the servers while locked, and the virtual machine is unable to power on.
These virtual machine files are commonly locked during runtime:
• VMNAME.vswp • DISKNAME-flat.vmdk • DISKNAME-ITERATION-delta.vmdk • VMNAME.vmx • VMNAME.vmxf • vmware.log Initial quick test To get your critical virtual machine running: 1. Migrate the virtual machine to the host it was last known to be running on and attempt to power on. 2. If unsuccessful, continue to attempt a power on of the virtual machine on other hosts in the cluster. When you hit the host holding the file locks, the virtual machine should power on as the file locks in place are valid. 3. If you still cannot power on the virtual machine continue with the steps below to investigate in more detail. To identify and release the lock on the files, follow the relevant steps for your version of ESX below.
ESX troubleshooting steps
ESXi troubleshooting steps
Further troubleshooting steps
ESX troubleshooting steps Identifying the locked file To identify the locked file, attempt to power on the virtual machine. During the power on process, an error may display or be written to the virtual machine's logs. The error and the log entry identify the virtual machine and files: 1. Where applicable, open and connect the VMware Infrastructure (VI) or vSphere Client to the respective ESX host, VirtualCenter Server, or the vCenter Server host name or IP address. 2. Locate the affected virtual machine, and attempt to power it on. 3. Open a remote console window for the virtual machine. 4. If the virtual machine is unable to power on, an error on the remote console screen displays with the name of the affected file.
Note: If an error does not display, proceed to these steps to review the vmware.log file of the virtual machine:
a. Log in to the ESX host as root using an SSH client. b. Confirm that the virtual machine is registered on the server and obtain the full path to the virtual machine, run this command:
# vmware-cmd -l
c. The output returns a list of the virtual machines registered to the ESX host. Each line contains the full path of a virtual machine's .vmx file. The output is similar to:
/vmfs/volumes/UUID/VMDIR/VMNAME.vmx
Note: Record this information as it is required in the remainder of this process. This is the path.vmx referenced in the remainder of the article. It is also case sensitive.
d. Move to the virtual machine's directory:
# cd /vmfs/volumes/datastore/VMDIR
e. Use a text viewer to read the contents of the vmware.log file. At the end of the file, look for error messages that identify the affected file. Locating the lock and removing it A virtual machine can be moved between hosts, because of this the host where the virtual machine is currently registered may not be the host maintaining the file lock. The lock must be released by the ESX host that owns the lock. This host is identified by the MAC address of the primary Service Console interface.
Note: Locked files can also be caused by backup programs keeping a lock on the file while backing up the virtual machine. If there are any issues with the backup it may result in the lock not being removed correctly. In some cases you may need to disable your backup application or reboot the backup server to clear the hung backup.
This lock can be maintained by the Service Console for any hosts connected to the same storage.
Start by identifying the server whose VMkernel may be locking the file. To identify the server:
1. Report the MAC address of the lock holder by running the command (except on an NFS volume):
# vmkfstools -D /vmfs/volumes/UUID/VMDIR/LOCKEDFILE.xxx
Note: Run this command on all commonly locked virtual machine files (as listed at the start of the Solution section) to ensure that all locked files are identified.
2. For servers prior to ESX 4.1, this command writes the output of the command above to the system's logs. From ESX 4.1, the output is also displayed on-screen. Included in this output is the MAC address of any host that is locking the .vmdk file. To locate this information, check /var/log/vmkernel . Look for lines similar to:
Hostname vmkernel: 17:00:38:46.977 cpu1:1033)Lock [type 10c00001 offset 13058048 v 20, hb offset 3499520
Hostname vmkernel: gen 532, mode 1, owner 45feb537-9c52009b-e812- 00137266e200 mtime 1174669462] Hostname vmkernel: 17:00:38:46.977 cpu1:1033)Addr <4, 136, 2>, gen 19, links 1, type reg, flags 0x0, uid 0, gid 0, mode 600 Hostname vmkernel: 17:00:38:46.977 cpu1:1033)len 297795584, nb 142 tbz 0, zla 1, bs 2097152 Hostname vmkernel: 17:00:38:46.977 cpu1:1033)FS3: 132:
The second line (in bold) displays the MAC address after the word owner. In this example, the MAC address of the Service Console or vswif0 interface of the offending ESX host is 00:13:72:66:E2:00. After logging into the server, the process maintaining the lock can be analyzed.
In versions of ESX equal or greater than 4.0 U3, 4.1 U1 there is a new field which can identify a read only or multi writer lock owner.
You will see an output similar to:
[root@test-esx1 testvm]# vmkfstools -D test-000008-delta.vmdk
Lock [type 10c00001 offset 45842432 v 33232, hb offset 4116480 gen 2397, mode 2, owner 00000000-00000000-0000- 000000000000mtime 5436998] , gen 33179, links 1, type reg, flags 0, uid 0, gid 0, mode 100600 len 738242560, nb 353 tbz 0, cow 0, zla 3, bs 2097152 o If the command 'vmkfstools -D test-000008-delta.vmdk ' does not return a a valid MAC address in the top field (returns all zeros ). Review the field below it, the RO Owner line below it to see which MAC address owns the read only/multi writer lock on the file. In the above example the offending MAC address is: 00:1A:64:C3:35:DC. o In some cases it is possible that it is a Service Console-based lock, an NFS lock or a lock generated by another system or product that can use or read VMFS file systems. The file is locked by a VMkernel child or cartel world and the offending host running the process/world must be rebooted to clear it. o Once you have identified the host or backup tool (machine that owns the MAC) locking the file, power it off or stop the responsible service, then restart the management agents on the host running the virtual machine to release the lock. 3. To determine if the MAC address corresponds to the host that you are currently logged into, see Identifying the ESX Service Console MAC address (1001167). If it does not, you must establish a console or SSH connection to each host that has access to this virtual machine's files.
After identifying, unregister the virtual machine from the existing host and register it on the host holding the lock and then attempt to power on the virtual machine. You may have to set DRS to manual to ensure that the virtual machine powers up on the correct host.
If the virtual machine still does not power on, complete these procedures while logged into the offending host.
4. Check if the virtual machine still has a World ID assigned to it:
For ESX 4.x, run these commands on all ESX hosts:
# cd /tmp
# vm-support -x
The output is similar to:
Available worlds to debug:
wid=world_id name_of_VM_with_locked_file
On the ESX host where the virtual machine is still running, kill the virtual machine. This releases the lock on the file. To kill the virtual machine, run this command:
# vm-support -X world_id
Where the world_id is the World ID of the virtual machine with the locked file.
Note: This command takes 5-10 minutes to complete. Answer No to Can I include a screenshot of the VM, and answer Yes to all subsequent questions.
After stopping the process, you can power on the virtual machine or access the file/resource.
Determining if the file is being used by a running virtual machine If the file is being accessed by a running virtual machine, the lock cannot be usurped or removed. It is possible that the host holding the lock is running the virtual machine and has become unresponsive, or another running virtual machine has the disk incorrectly added to its configuration prior to power-on attempts.
To determine if the virtual machine processes are running:
1. Determine if the virtual machine is registered on the host run this command as the root user:
# vmware-cmd -l
Note: If the virtual machine is registered on more than one ESX host, see Virtual machines appear to be running or registered on multiple ESX Servers (1005051).
2. Assess the virtual machine's current state on the host, run this command:
# vmware-cmd path.vmx getstate
o If the output from this command is getstate() = on, the virtual machine has become unresponsive. To address this issue, see 1007819. o If the output from this command is getstate() = off, the ESX host may be unaware of the file lock. 3. To stop the virtual machine process, see Powering off an unresponsive virtual machine on an ESX host (1004340). If the ESX specific steps above identified the owner of the lock, proceed to these troubleshooting steps . ESXi troubleshooting steps Identifying the locked file To identify the locked file, attempt to power on the virtual machine. During the power on process, an error may display or be written to the virtual machine's logs. The error and the log entry identify the virtual machine and files: 1. Where applicable, open and connect the VMware Infrastructure (VI) or vSphere Client to the respective ESXi host, VirtualCenter Server, or the vCenter Server host name or IP address. 2. Locate the affected virtual machine, and attempt to power it on. 3. Open a remote console window for the virtual machine. 4. If the virtual machine is unable to power on, an error on the remote console screen displays with the name of the affected file.
Note: If an error does not display, proceed to these steps to review the vmware.log file of the virtual machine:
a. Log in as root to the ESXi host using an SSH client. b. Confirm that the virtual machine is registered on the server and obtain the full path to the virtual machine, run this command:
# vim-cmd vmsvc/getallvms
The output returns a list of the virtual machines registered to the ESXi host. Each line contains the datastore and location within of a virtual machine's .vmx file. The output is similar to:
[datastore] VMDIR/VMNAME.vmx
Verify that the affected virtual machine appears in this list. If it is not listed, the virtual machine is not registered on this ESXi host. The host on which the virtual machine is registered typically holds the lock. Ensure that you are connected to the proper host before proceeding.
c. Move to the virtual machine's directory:
# cd /vmfs/volumes/datastore/VMDIR
d. Use a text viewer to read the contents of the vmware.log file. At the end of the file, look for error messages that identify the affected file. Locating the lock and removing it A virtual machine can be moved between hosts, because of this the host where the virtual machine is currently registered may not be the host maintaining the file lock. The lock must be released by the ESX/ESXi host that owns the lock. This host is identified by the MAC address of the primary management vmkernel interface.
Note: Locked files can also be caused by backup programs keeping a lock on the file while backing up the virtual machine. If there are any issues with the backup it may result in the lock not being removed correctly. In some cases you may need to disable your backup application or reboot the backup server to clear the hung backup.
This lock can be maintained by the VMkernel for any hosts connected to the same storage.
Note: ESXi does not utilize a separate Service Console Operating System. This reduces the amount of lock troubleshooting to just the VMkernel. For example, Console OS troubleshooting methods such as using the lsof utility are not applicable to ESXi hosts.
Start by identifying the server whose VMkernel may be locking the file. To identify the server:
1. Report the MAC address of the lock holder by running the command (except on an NFS volume):
# vmkfstools -D /vmfs/volumes/UUID/VMDIR/LOCKEDFILE.xxx
Note: Run this command on all commonly locked virtual machine files (as listed at the start of the Solution section) to ensure that all locked files are identified.
2. For servers prior to ESXi 4.1, this command writes the output of the command above to the system's logs. From ESXi 4.1, the output is also displayed on-screen. Included in this output is the MAC address of any host that is locking the .vmdk file. To locate this information, check /var/log/messages. Look for lines similar to:
Hostname vmkernel: 17:00:38:46.977 cpu1:1033)Lock [type 10c00001 offset 13058048 v 20, hb offset 3499520
Hostname vmkernel: gen 532, mode 1, owner 45feb537-9c52009b-e812- 00137266e200 mtime 1174669462] Hostname vmkernel: 17:00:38:46.977 cpu1:1033)Addr <4, 136, 2>, gen 19, links 1, type reg, flags 0x0, uid 0, gid 0, mode 600 Hostname vmkernel: 17:00:38:46.977 cpu1:1033)len 297795584, nb 142 tbz 0, zla 1, bs 2097152 Hostname vmkernel: 17:00:38:46.977 cpu1:1033)FS3: 132:
The second line (in bold) displays the MAC address after the word owner. In this example, the MAC address of the management vmkernel interface of the offending ESXi host is 00:13:72:66:E2:00. After logging into the server, the process maintaining the lock can be analyzed.
In versions of ESXi equal or greater than 4.0 U3, 4.1 U1 there is a new field which can identify a read only or multi writer lock owner.
You will see an output similar to:
[root@test-esx1 testvm]# vmkfstools -D test-000008-delta.vmdk
Lock [type 10c00001 offset 45842432 v 33232, hb offset 4116480 gen 2397, mode 2, owner 00000000-00000000-0000- 000000000000mtime 5436998] , gen 33179, links 1, type reg, flags 0, uid 0, gid 0, mode 100600 len 738242560, nb 353 tbz 0, cow 0, zla 3, bs 2097152 o If the command 'vmkfstools -D test-000008-delta.vmdk ' does not return a a valid MAC address in the top field (returns all zeros ). Review the field below it, the RO Owner line below it to see which MAC address owns the read only/multi writer lock on the file. In the above example the offending MAC address is: 00:1A:64:C3:35:DC. o In some cases it is possible that it is a Service Console-based lock, an NFS lock or a lock generated by another system or product that can use or read VMFS file systems. The file is locked by a VMkernel child or cartel world and the offending host running the process/world must be rebooted to clear it. o Once you have identified the host or backup tool (machine that owns the MAC) locking the file, power it off or stop the responsible service, then restart the management agents on the host running the virtual machine to release the lock.
3. To determine if the MAC address corresponds to the host that you are currently logged into, see Identifying the ESX Service Console MAC address (1001167). If it does not, you must establish a console or SSH connection to each host that has access to this virtual machine's files.
After identifying, unregister the virtual machine from the existing host and register it on the host holding the lock and then attempt to power on the virtual machine. You may have to set DRS to manual to ensure that the virtual machine powers up on the correct host.
If the virtual machine still does not power on, complete these procedures while logged into the offending host. Konjiki no gash bell 101 banme no mamono filme bd full.
Note: If you have already identified a VMkernel lock on the file, skip the rest of the steps in this section.
4. Check if the virtual machine still has a World ID assigned to it:
For ESXi 4.x, run these commands on all ESXi hosts:
# cd /tmp
# vm-support -x
The output is similar to:
Available worlds to debug:
wid=world_id name_of_VM_with_locked_file
On the ESXi host where the virtual machine is still running, kill the virtual machine. This releases the lock on the file. To kill the virtual machine, run this command:
# vm-support -X world_id
Where the world_id is the World ID of the virtual machine with the locked file.
Note: This command takes 5-10 minutes to complete. Answer No to Can I include a screenshot of the VM, and answer Yes to all subsequent questions.
After stopping the process, you can power on the virtual machine or access the file/resource.
For ESXi 5.0, the esxcli command-line utility can be used locally or remotely to display a list of the virtual machines which are currently running on the host.
Obtain a list of all running virtual machines, identified by their World ID, Cartel ID, display name, and path to the .vmx configuration file using this command:
# esxcli vm process list
The output is similar to:
VirtualMachineName
World ID: 1268395 Process ID: 0 VMX Cartel ID: 1264298 UUID: ab cd ef .. Display Name: VirtualMachineName Config File: /path/VirtualMachineName.vmx
Two worlds are listed. The first world number (in this example, 1268395) is the Virtual Machine Monitor (VMM) for vCPU 0. The second world number (in this example, 1264298) is the virtual machine Cartel ID.
On the ESXi host where the virtual machine is still running, kill the virtual machine. This releases the lock on the file. To kill the virtual machine, run this command:
# esxcli vm process kill --type soft --world-id 1268395
For additional information, see Mapping a virtual machine world number to a virtual machine name (1001101).
5. In ESXi 4.1/5.x, to find the owner of the locked file of a virtual machine, run this command:
# vmkvsitools lsof | grep Virtual_Machine_Name
You see output similar to:
11773 vmx 12 46 /vmfs/volumes/Datastore_Name/VirtualMachineName/ VirtualMachineName-flat.vmdk
You can then run this command to obtain the PID of the process for the virtual machine:
ps | grep Virtual_Machine_name
You can kill the process with this command:
kill -9 PID
To generate a core dump after killing the running virtual machine (but hung and nonresponsive), use the command kill -6 PID or kill -11 PID.
Note: In ESXi 4.1 and ESXi 5.x, you can use the k command in esxtop to send a signal to, and kill, a running virtual machine process. On the ESXi console, enter Tech Support mode and log in as root. For more information, see Tech Support Mode for Emergency Support (1003677).
a. Run the esxtop utility using the esxtop command. b. Press c to switch to the CPU resource utilization screen. c. Press Shift+f to display the list of fields. d. Press c to add the column for the Leader World ID. e. Identify the target virtual machine by its Name and Leader World ID (LWID). f. Press k. g. At the World to kill prompt, type in the Leader World ID from step 5 and press Enter. h. Wait 30 seconds and validate that the process is no longer listed. Determining if the file is being used by a running virtual machine If the file is being accessed by a running virtual machine, the lock cannot be usurped or removed. It is possible that the host holding the lock is running the virtual machine and has become unresponsive, or another running virtual machine has the disk incorrectly added to its configuration prior to power-on attempts.
To determine if the virtual machine processes are running:
1. Determine if the virtual machine is registered on the host, run this command as the root user:
# vim-cmd vmsvc/getallvms
The output lists the vmid for each virtual machine registered. Record this information as it is required in the remainder of this process on the ESXi server.
2. Assess the virtual machine's current state on the host, run this command:
# vim-cmd vmsvc/power.getstate vmid
3. To stop the virtual machine process, see Powering off an unresponsive virtual machine on an ESX host (1004340). Further troubleshooting steps These steps are applicable to both ESX and ESXi Using the touch utility to determine if the file can be locked The touch utility is designed to update the access and modification time stamp of the specified file or directory. As such, the command can be used to test the file and directory locking mechanism in the VMFS filesystem, where the procedure is expected to fail on locked files. Using touch is the preferred method because the changes to the resource are minimal.
To test the file or directory locking functionality, run this command:
# touch filename
Note: Performing a touch * command performs the operation on all files in the current directory.
The touch * command can result in these outcomes:
• If the touch * command succeeds, then the command successfully made changes to the date/time stamp and has verified that the file can and has been locked (then unlocked). At this point, retry the virtual machine power-on operation to see if it succeeds. • If the touch * command fails with a device or resource busy message, it indicates that a process is maintaining a lock on the file or directory. This may be on any of the ESXi/ESX hosts which have access to the file. If the message is reported, proceed to the next section. • If another error message is reported, it may indicate that the metadata pertaining to file or directory locking on VMFS may not be valid or corrupt. If this is the case, collect diagnostic information from the ESXi/ESX host and submit a Support Request. For more information, see Collecting diagnostic information for VMware products (1008524) and How to Submit a Support Request. Removing the .lck file (NFS only) The files on the virtual machine may be locked via NFS storage. You can identify this by files denoted with .lck-#### (where #### is the value of the fileid field returned from a GETATTR request for the file being locked) at the end of the file name. This is an NFS file lock and is only listed when using the ls -la command because it is hidden file(in versions of ESX/ESXi prior to 5.x). For more information, see Powering on a virtual machine on NFS or trying to remove an NFS Datastore fails with errors 'Unable to access a file since it is locked' or 'Resource is in use' (1012685).
For more information on NFS file locking, see the VMware NFS Best Practices Whitepaper.
Caution: These can be removed safely only if the virtual machine is not running.
Note: VMFS volumes do not have .lck files. The locking mechanism for VMFS volumes is handled within VMFS metadata on the volume.
Determining if the .vmdk file is in use by other virtual machines A lock on the .vmdk file can prevent a virtual machine from starting. However, since virtual machine disk files can be configured for use with any virtual machine, the file may be locked by another virtual machine that is currently running.
To determine if the virtual machine's disk file is configured for use on more than one virtual machine, run this command:
# egrep -i DISKNAME.vmdk /vmfs/volumes/*/*/*.vmx
Notes:
• This command attempts to locate the specified disk name among all .vmx configuration files for the virtual machines that are visible to the ESX/ESXi host. A Device or resource busy message is printed for each virtual machine that is running but not registered to this ESX host. You must run this command on each ESX/ESXi host in the infrastructure or specifically on hosts that have access to the storage containing the virtual machine's files. • If any additional virtual machines are configured to use the disk, determine if they are currently running. Powering off the other virtual machine using the disk file releases the lock. You must determine which virtual machine should have ownership of the file, then reconfigure your virtual machines to prevent this error from occurring again. • As part of their operation, many virtual machine backup solutions temporarily attach the virtual machine's .vmdk files to themselves. In such cases, if the backup fails and/or the host shuts down, the backup virtual machine may still have another virtual machine's .vmdk file(s) attached. If that is the case, the other virtual machine is usually powered on first, which then creates a locked file condition when the backup virtual machine is attempted to be powered on. Check using Edit Settings on your backup solution's virtual machine to see if it has a disk attached that belongs to a different virtual machine. If it does, power down the backup virtual machine, select the appropriate disk and choose Remove to remove the disk from the virtual machine.
Warning: Do not delete files from disk.
If the .vmdk file is not in use by other virtual machines, confirm that there are no VMkernel or Service Console processes locking the file, per the above section, Locating the file lock and removing it. If a host can be determined but the specific offending VMkernel child process ID cannot be identified, you must reboot the server to clear the lock.
Note: You can also try to migrate the virtual machine to another host and power it on. If that ESX host has the lock for the virtual machine, it should allow you to power it on.
Rebooting the ESX/ESXi host which is locking the files By this stage, you have already investigated for identifiable VMkernel and Service Console processes which have maintained locks upon the required files, however an unidentified child process still maintains the lock. You have identified the server via the vmkfstools -D command in earlier steps, the lsof utility(ESX only) yields no offending processes, and no other virtual machines are locking the file.
The server should be restarted to allow the virtual machine to be powered on again.
Note: Collect diagnostic information prior to rebooting if you wish to investigate the issue further through analysis by VMware Technical Support.
Migrate the virtual machines from the server and restart it using these steps:
1. Migrate or vMotion all virtual machines from the host to alternate hosts. 2. When the virtual machines have been evacuated, place the host into maintenance mode and reboot it. Note: If you have only one ESX/ESXi host or do not have the ability to vMotion or migrate virtual machines, you must schedule downtime for the affected virtual machines prior to rebooting. When the host has rebooted, start the affected virtual machine again. Check the integrity of the virtual machine configuration file (.vmx) For more information on checking the integrity of the virtual machine configuration file, see Verifying ESX/ESXi virtual machine file integrity (1003743).
Note: If a virtual machine does not power on, it may be pointing to two disks in the .vmx file. Remove one of the disks from the virtual machine and attempt to power on again.
Note: For related information, see Cannot power on a virtual machine because the virtual disk cannot be opened (1004232)
Opening a Support Request If your problem still exists after attempting the steps in this article, contact VMware Technical Support and file a Support Request: • Gather diagnostic information. For more information, see Collecting diagnostic information for VMware products (1008524). • File a support request with VMware Support and note this Knowledge Base article ID (10051) in the problem description. For more information, see How to Submit a Support Request. Additional Information For translated versions of this article, see: • Español: La máquina virtual no funciona por bloqueo o por falta de archivos (1032063) • 日本語: ファイルがロックされているために仮想マシンがパワーオンされない (1033280) • Portuguese: Máquina virtual não liga devido a arquivos bloqueados (2032408) This Article Replaces 1004925 Update History 03/05/2010 - Added note to restart the Management agents before restarting the ESX host. 11/04/2010 - Added lsof steps. 12/15/2011 - Added link to KB article 1003743 07/23/2012 - Added additional symptom 08/24/2012 - Added not regarding .vmx 09/13/2012 - Added additional symptom References
1 Comment
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |