"The action could not be completed. Try again.” How many times before calling it a day?

The end-user just called you and stated that no matter how many times he keeps trying, the result is pretty much the same.

Ok, so it seems that the suggestion is not good enough. What can you do if all you have is this error message and a complaining user? Well, there is often a log file of some kind which you should be able to open up and correlate the error occurrences with some kind of a timestamp. Looking at the Event Viewer events is also a good first stop in case some relevant message is logged for that matter.

As a troubleshooter, though, you do not want to rely upon the unpredictability of those sources of data as far as your problem is concerned. You should be able to open your bag of tools and start digging in until you find the root cause. Depending on the nature of applications and technologies under your scope, this bag of tools may vary a lot. Let me describe my approach for this particular issue.

After figuring out that no additional information was being logged anywhere, I used the good ol’ Process Monitor and asked the user to reproduce the issue, as it happened every time.

Let’s follow the trace and try figuring out what was happening:

At this stage, the worker process was loading this 401-1.htm file, so this was probably during the security handshake in which there is a credentials challenge and response process. No harm done here, eventually the credentials are accepted and the request proceeds.

There you go, the request is being processed. Apparently, the worker process is now trying to connect to a SQL Server instance in a server named SRV09. If you’re not acquainted with the solution architecture, this is a good clue of where the data is being stored and retrieved from.

Next I had to scroll down a bit as there were tons of MUI-related events which do not add much. And then, I found these 3 lines:

Something must have gone wrong within those 30 milliseconds.

Let’s see what follows:

Indeed, something has gone wrong... Where? Well, this HKCR\CLSID\{0C7FF16C-38E3-11d0-97AB-00C04FC2AD98} is the SQLOLEDB CLSID, meaning that we can move on to SQL Server and figure out what is going on there.

By moving on to SQL Server, I mean starting a SQL Server trace on this SRV09, ensuring that OLEDB Errors is selected, as well as those basic events you’ll find in the usual templates concerning the SQL Statements execution.

Weird: according to https://technet.microsoft.com/en-us/library/cc917589.aspx, this exception stands for Too many arguments were supplied for procedure %. *ls, something we would not expect to happen in a Windows SharePoint Services/SQL Server environment. Anyway, by checking the statement which starts before the exception and gets completed immediately after it, we saw that the call did not really match the Stored Procedure signature.

In particular, the SP was expecting fewer parameters, thus the exception above. Given this mismatch, I suspected of an incomplete WSS patching or update, a plausible reason for this, as the code might have been changed along with the database schema and Stored Procedure implementation. Bulls-eye!! A few weeks before, this particular WSS server had been applied the latest Service Pack, and apparently that did not succeed, but no one noticed until this user tried to add a new field to a list.

See? No logs, no events, no hands on the steering wheel, just valuable information popping out of these great tools...

Regards,

Manuel Oliveira