This message can appear in the vlogs.
Error: Soap Exception ( mesg-id = 635071590603372501 )
Exception: RestrictionsOccurred [1387]
Stacktrace:
Server stack trace:
at Connectivity.Product.BusinessLogic.ItemBL.CheckRestrictionsByItemIterationIds(ProductRestrictionCodes[] restrictionCodes, Int64[] itemIterationIds)
at Connectivity.Product.BusinessLogic.ItemBL.EditItemRevisionInternal(Int64 itemRevId, Boolean bypassWIPRestriction, String comment)
at System.Runtime.Remoting.Messaging.Message.Dispatch(Object target)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Connectivity.Product.Services.ItemService.EditItemRevision(Int64 itemRevId)
at Connectivity.Web.Services.v18.ItemService.EditItem(Int64 itemRevisionId)
at SyncInvokeEditItem(Object , Object[] , Object[] )
at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
The client can see this:-

"Operation cannot be performed because the item is locked for edit by user ‘<vaultusername>’."
In this situation, it occured whilst a user was editing an Item, but the Connectivity.VaultPro.exe was killed in Task Manager to simulate a client crash mid-way through editing the Item. The error in the vlog is generic. When the Vault client was restarted, Right clicking on the Item and selecting Edit resulted in the above message in the User Interface and the entry in the vlog.
In this situation you would need to wait 30 minutes before being able to edit the Item. The reason this locktime is enforced is because when an Item is edited, it needs to be temporarily locked to allow the user time to complete their task without the risk of another user overriding their edits. Without this lock, it would be possible that a user might start editing the Item, get distracted and then continue editing it, but when they finish editing it, another user may also have tried editing that Item. At this stage Vault could either overwrite the second users edits or display an error saying that the Item has changed. This would lead to confusion. So to prevent this from happening, if an Item is edited, it is locked until either the user cancels their edit or completes it.
I managed to reproduce this by editing an Item, then killing the process in Task Manager, mid-edit. Similar to a crash, the server would have had no message sent to it that the user has either canceled or completed their task. It assumes therefore that the user is still editing, until the 30 minute lockout expires.