Error: 17805, Severity: 20, State: 3 Invalid buffer received from client.

Howdy Folks,
Our site has been experiencing this issue for a couple of months now.. Hopefully someone else can assist, as Ive got to a point where I think issue lies within the application or a Microsoft bug. Web searches have reveled a number installations that have also had this error but its has not revealed an actual fix.

I understand this error code basically means data being returned to the client is getting either corrupted or the data is too large to fit into the buffer on the client side. Client in our case is the terminal server, here after called a application server

As the user base has increased form 5 to 20, I have noticed that the issue is occurring more frequently in comparison to when the company first started using the application /database. Its just about daily now...

The db server also has 8 other db's residing on it - but they are all less than 300 meg.

The attached PowerPoint doc has the trace info & the surrounding code for each process that has suffered a buffer error over a period of a week.

DB Server Environment: Win2000 SP4, SQL2000 SP3a, MDAC 2.7 SP1 refresh.
Application Environment: Written In house in VB.NET Framework 1.1 setup as a published app on a terminal server running windows 2000 SP4

Common features of the issue, that have been omitted from trace output for visibility reasons are:
- Involves 1 particular DB (thats accessed by VB app) & its developement db
- All connections are coming from 1 application server
- Issue does not relate to any particular site connecting to the application server using this application

I have reviewed & fixed several potential server side causes but this error still is occuring with in the environment:

MDAC versions must be common on application & server:
- Removed from equation by updating MDAC version on App server to be the same as DB Server: 2.7 SP1 Refresh

Network related
- Considered unlikely; we are also not experiencing network card errors on either server; also all db's would be experiencing connectivity errors.

Which leaves us with Application related options to review:
- Compilation error of application
- App parameter definitions to stored procedures are the correct data type
- Ensure values being passed do not exceed 4000 characters as that has also been known to create this error message
- I've asked the developer to review MS KB 827366 article, as it may be a valid test
- In regard to MSKB 832977 - I am not using pssdiag & have a later version of the MS Analyzer. But what I thought was interesting, is the statement that this problem occurs more frequently when an application submits a large remote procedure call (RPC) input buffer, especially when the RPC input buffer is greater than or equal to 8 KB. However, this problem may occur even if the input buffer is less than 4 KB
- A is using datatypes varchar & char - not nvarchar & nhar

Any assistance with this issue would be appreicated as server performance is being effected - these processes hang around for 1 - 5 mins before terminating (refer duration times in the powerpoint traces)

Thanks In advance

Suze.I think Reads column referrs to physical reads. If that's the case then the number is pretty high and may be the reason for the client timeout. Sporadic behavior of the same query may be caused by inconsistent execution plan generated. Do you use dynamic SQL a lot?|||Thank you for your question...

The number of reads appears only on the first slide, the other 7 don't have any reads - just the really long duration.
Because of this long duration & the audit logout entry for the same process id directly after the buffer error, I've assumed that the process is timing out. But in saying that users are not reporting that they have been kicked out of the application or receiving any error messages - so maybe way off in that assumption.

We are using SP's passing in parameter's. The developer reckons this means its not being built at runtime. As you might be able to tell, I'm a newbie - so I don't know if this means they are dynamic sql or not... are you able to advise.

Best Regards|||The 4000-limit was revealed in my previous environment when SP3 was applied. The FE code was...of course, JAVA, what else can cause this. And they were parsing the call to the stored procedure without TYPEing the parameters, which resulted in every character-based parameter to be interpreted as NVARCHAR. Now, the article (827366) is also referring to the possibility of data type size misalignment, where the value supplied may be outside of the boundaries allowed for a specific data type (just a hunch).|||I like the sound of your hunch. Unfortunately I can't provide the developer any proof - being a newbie in all. Anyway, I think I've done the next best thing by sending the developer the MSKB article 827366 again & Ant profiler to use so he can see what his code is doing - hopefully this will give him the visibility he needs.

Thanks again & Best Regards
Suze.