Troubleshooting the vague “Cannot complete this action” owssvr.dll error

 

 

So what can you possibly do when you try to do something simple in SharePoint, like editing a view, and you see the following error in your browser?

 

Error

Cannot complete this action.

Please try again.

Troubleshoot issues with Microsoft SharePoint Foundation.

 

 

The only other clue you have is the presence of "/_vti_bin/owssvr.dll?CS=65001" in your address bar.

There is no correlation ID to focus on. And no matter how long you comb through the ULS logs, there are just no clues whatsoever.

What do you do?

 

The first thing I did in this scenario was to try to amp up the level of verbosity in ULS logging to verboseEX. Steps:

1.       During a server maintenance window, log onto the central admin server as a Farm Admin

2.       Open the SharePoint 2010 Management Shell (or PowerShell)

3.       Run the following commands:

a.       New-SPLogFile        [Note: this starts a new ULS log]

b.      Set-SPLogLevel -TraceSeverity VerboseEX        [Note: this sets all logging to super high levels]

4.       Note the time on the server

5.       Begin to reproduce the problem

6.       After problem has been sufficiently reproduced run the following commands

a.       New-SPLogFile

b.      Clear-SPLogLevel          [Note:  This sets the logging level back to normal/default]

7.       Create a new folder to handle ULS logs (example here:  D:\Logs)

8.       Run this command:
Merge-SPLogFile -Path "C:\Logs\FarmMergedLog.log" -Overwrite -StartTime "10/11/2013 16:00" – EndTime "10/11/2013 16:15"

·         NOTE: path, date, and times may vary

·         NOTE: this command is supposed to collect the ULS logs from every server in the farm and merge them into one biiiiiiiiig logfile.   It's important to give it a specific time range.  Details.

 

But to my dismay, even verboseEx level ULS logs were totally disappointing. No clues to be found there. Zero.

 

When ULS logs disappoint me, I'm usually pretty quick to turn to DebugDiag. So we installed DebugDiag 2.0 on the WFE (this farm fortunately only had one WFE and that makes it easy to guess which WFE your traffic is going to) and began to set up the crash rule to log all exceptions per my steps here.
The log file that DebugDiag generated while we reproduced the problem showed something unexpected in one of the stack traces of a thread that was throwing a first chance exception.

 

Child-SP RetAddr Call Site

000000002c9bddb0 000007ff0024c51d Microsoft.SharePoint.SPListCollection.GetListByName(System.String, Boolean)

000000002c9bde30 000007ff0024c0d5 .(Microsoft.SharePoint.SPWeb)

000000002c9bde80 000007fef389ea69 .()

000000002c9bdf10 000007fef374a55c Microsoft.SharePoint.SPSecurity+<>c__DisplayClass4.<RunWithElevatedPrivileges>b__2()

000000002c9bdf90 000007fef36189a2 Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated)

000000002c9bdfe0 000007fef3618a9d Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(System.Threading.WaitCallback, System.Object)

000000002c9be080 000007ff0024986b Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated)

000000002c9be0e0 000007ff00249698 .()

000000002c9be150 000007ff00249549 ..ctor()

000000002c9be1a0 000007ff002490bd .()

000000002c9be210 000007feee7059b0 SusQtech.Products.UrlManager.HttpModule.(System.Object, System.EventArgs)

000000002c9be290 000007feee6f671b System.Web.HttpApplication+SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

000000002c9be2f0 000007feeede3971 System.Web.HttpApplication.ExecuteStep(IExecutionStep, Boolean ByRef)

000000002c9be390 000007feeedd43b2 System.Web.HttpApplication+PipelineStepManager.ResumeSteps(System.Exception)

000000002c9be520 000007feeedb5df9 System.Web.HttpApplication.BeginProcessRequestNotification(System.Web.HttpContext, System.AsyncCallback)

000000002c9be570 000007feeeeddde1 System.Web.HttpRuntime.ProcessRequestNotificationPrivate(System.Web.Hosting.IIS7WorkerRequest, System.Web.HttpContext)

000000002c9be690 000007feeeedd9ab System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr, IntPtr, IntPtr, Int32)

000000002c9be810 000007feeeedcc14 System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr, IntPtr, IntPtr, Int32)

000000002c9be870 000007fef833b1fb DomainNeutralILStubClass.IL_STUB(Int64, Int64, Int64, Int32)

 

We retracted the SusQTech URL Manager solutions, ran IIS reset, and confirmed that the problem went away. I recommended to the server admin that he contact support from the vendor and see if they had newer versions or private fixes that might avoid the problem.

 

Although we didn't try it this time, we might have been able to find the same information (see which httpmodules were at play here anyway) with some IIS level failed request tracing.