Error "The output byte puffer is too small to contain the encoded data"

[Bernhard Mayer]

Dear fellow X#'ers!

A strange error occurred at two of our customers: New installed Windows 10 clients are throwing errors in different locations of our application, some of them calling/using Vulcan code (e.g. writing data deep to a temporary DBF by using the DBFCDX driver), some calling/using C# ones: The output byte puffer is too small to contain the encoded data, encoding 'Unicode (UTF 8)' fallback 'System.Text.EncoderExceptionFallback'.

Other clients in the same company running the same application resp. accessing the same data (SQL Server) do not encounter these problems, and for now I'm running out of ideas how to solve these issues; I assumed some .NET framework issue but up to now I did not succeed.

- The new clients are using .NET framework 4.8.x.
- Some clients where our application works have 4.6.2 installed.
- Our application is compiled with 4.5 (x86).

Does anyone have a clue? I now it's not really much information but given the various error sources there is not really a specific code I can provide.

TIA,
Bernhard

[Bernhard Mayer]

Those automatic smilies ... it is supposed to be UTF 8.

[Chris]

HI Bernhard,

A quick google search for the error message shows entries like those:

https://stackoverflow.com/questions/132 ... ecoded-cha
https://stackoverflow.com/questions/354 ... ect=1&lq=1

Maybe it's a system locale issue? Do you get a callstack with the error? Can you show us exactly on which code it happens? If it happens deep in X# runtime code, please use the .pdb files of the runtime files as well (just copy them alongside the dlls), so they will provide better callstack information.

[Bernhard Mayer]

Hi Chris!

Thanks for your response; I already had a look at the clients' regional settings, and they seem okay to me.

One error produced the following callstack (still Vulcan):

bei System.Text.Encoding.ThrowBytesOverflow(EncoderNLS encoder, Boolean nothingEncoded)
bei System.Text.UTF8Encoding.GetBytes(Char* chars, Int32 charCount, Byte* bytes, Int32 byteCount, EncoderNLS baseEncoder)
bei System.Text.UTF8Encoding.GetBytes(String s, Int32 charIndex, Int32 charCount, Byte[] bytes, Int32 byteIndex)
bei Vulcan.RDD.DBFCDX._VOPutMemoData(Object itmData, DBFMemoInfo memoInfo, UInt32& ulpNewBlockNumber, COMPTYPE compType, Boolean bAppend)
bei Vulcan.RDD.DBFCDX.PutValue(UInt32 uiField, Object lpitm)
bei VulcanRTFuncs.Functions.VODBFieldPut(UInt32 nFieldPos, __Usual uValue)
bei dbServer.FIELDPUT(__Usual[] $args)

But I don't know whether the error itself is misleading as the same application works flawlessly on other clients.

BR,
Bernhard

[Chris]

Hi Bernhard,

That's strange, I don't see why this should be happening. Except if the data to be written has some strange contents that cannot be properly translated to be written to the memo. What is the exact data that they try to put to the dbf when this error happens? Also does this happen every time they try to put something in this memo? No matter the contents? Only in this dbf or in others as well?

[Jamal]

Hi Bernhard,

>> Vulcan.RDD.DBFCDX <<

Possibly the above RDD is the culprit.

What if you switch to X# DBFCDX RDD? May be you can send your clients a small a test to see if it also occurs.

Jamal

[Bernhard Mayer]

The problem is that other customers are getting this error message in other source parts, too - and this time the error happens somewhere deep in the .NET source code which is used by C# DLLs which is called by a Vulcan code DLL when querying SQL varchar data.

It happens on some clients which were newly installed - and other ("older") clients using the same application and same sql data have no problem at all, hence my speculation about some environmental/regional issue which I failed to find so far. My hope was that someone encountered a similar issue and could provide me a "Just change this setting" or "Uninstall this Windows update" hint.

[Bernhard Mayer]

Interesting: One of our customers could solve his issue by making a complete new installation of the operating system - it seems that the client was upgraded from Windows 7 to 10 and during that upgrade process the .NET Framework was damaged.