The expression could not be evaluated: 19InvalidTextEncoding

I have a customer wanting to pull back results with the below session relevance:

(values of results of bes properties whose (name of it = "AddRemovePrograms" ))
of (members of bes computer groups whose (name of it as lowercase = "win workstations"))
whose (hostname of it as uppercase starts with "SS123")

Example return should be like this:
UltraVNC Server Office, 1.1.96, UVNC BVBA, SS123AV0123E, USERID
Microsoft Visual C++ 2012 x64 Additional Runtime - 11.0.60610, 11.0.60610, Microsoft Corporation, SS123AV0123E, USERID
Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.17, 9.0.30729, Microsoft Corporation, SS123AV0123E, USERID
IntelÂŽ PROSet/Wireless WiFi Software, 18.40.2.0828, Intel Corporation, SS123AV0123E, USERID
ThinkVantage Communications Utility, 3.0.34.0, Lenovo, SS123AV0123E, USERID
Microsoft Silverlight, 5.1.50901.0, Microsoft Corporation, SS123AV0123E, USERID

But I get “The expression could not be evaluated: 19InvalidTextEncoding”. I grabbed some examples that may have special characters that don’t come back in XML well. Any thought on how to get this to come back right?

Just did another test. The subject error comes back if I use the Session Relevance Tester. But if I use the console presentation debugger, I get: “Error: WindowsCharacterSetResult: Error 1113 (No mapping for the Unicode character exists in the target multi-byte code page.) in TranscodeU8ToU16.”

This kind of result is usually because of a value that isn’t the expected encoding (in your case the string isn’t UTF8) and thus it cannot transcode the value. I presume you are using 9.5 due to the error message, and as the values are assumed to be UTF8 in the DB. Do you have all 9.5 clients? Are any endpoints relevant for the fixlet message in BES Support warning about endpoint encodings?

Our desktops are still on 9.2 clients. I’ll look into the encoding options. Thanks!

I’m not seeing the “endpoint encoding” fixlet you speak of. @cmcannady told me of a fixlet we had that set some settings along those lines. Are these the settings?

setting "_BESClient_DeploymentEncoding_IANAName"="UTF-8" on "{parameter "action issue date" of action}" for client
setting "_BESClient_ClientEncoding_IANAName"="UTF-8" on "{parameter "action issue date" of action}" for client

I did some testing with those settings on my laptop and it didn’t fix the issue that I can tell.

The settings are wrong for DeploymentEncoding for sure as it cannot be UTF-8. Also seeting the ClientEncoding to UTF-8 is wrong as well as it needs to be a windows codepage.

On an “english” system its most likely windows-1252

If you are using a 9.5 server release the values are actually in your masthead (the 9.2 clients also respect them).

The fixlet I mentioned is in BES Support #2283 and warns of local codepage limiting content.

1 Like

That’s not showing relevant to any of our workstations. Some servers and such, but no workstations.

thoughts?

Any other ideas? One thing I was thinking of was using CDATA tag, but I get “A singular expression is required”

("<![CDATA[" & values of results of bes properties whose (name of it = "AddRemovePrograms" ) & "]]>")
of (members of bes computer groups whose (name of it as lowercase = "win workstations"))
whose (hostname of it as uppercase starts with "SS123")

thinking that may wrap any special characters.

You can’t use “&” to concatenate a plural result. If you wanna go down that path, try

("<![CDATA[" & concatenation "%0d%0a" of values of results of bes properties whose (name of it = "AddRemovePrograms" ) & "]]>")
of (members of bes computer groups whose (name of it as lowercase = "win workstations"))
whose (hostname of it as uppercase starts with "SS123")

or concatenate with "<br>" or other tag if you’re outputting HTML.

I don’t have any clients with this kind of transcoding error now, but I wonder if you could check the “retrievable” values with ‘exists string ()’? Something like

(values whose (exists it as string) of results of bes properties whose (name of it = "AddRemovePrograms" ))
of (members of bes computer groups whose (name of it as lowercase = "win workstations"))
whose (hostname of it as uppercase starts with "SS123")

Time to kick this thread back up…

We never found a resolution for this. I did however find one of the records that were causing the issue. @JasonWalker I did look at wrapping the relevance in your CDATA and it still comes back with “The expression could not be evaluated: 19InvalidTextEncoding” error.

Here’s how that device looks in the console.

Are you still using 9.2 agent on the computer of the screen capture?
What exactly is the agent version (like 9.2.5)?
Does that computer report recently?
What is the “reporting character set of client” of that computer?

The first post indicates your workstations are in “win workstations” group so I suppose the computer of the screen capture is also Windows.
When 9.2 Windows Agent is used with 9.5 Server, agents are supposed to transcode all reports to UTF-8 before sending them to server and data stored in the server must be in UTF-8. But if your agent is 9.2.5 or earlier, you need to restart your agent to send report in UTF-8.

The problem keeps popping in and out. The record I just found this on was agent version 9.5.4.49 (and was for all the logs I could gather). Here’s something funny the admin for that box said. I asked him to turn the box back on and he said as it was coming up, it went into a check disk. Tells me the box didn’t shut down properly. Which begs the question:

If the agent is in a state of posting status, then shuts down hard, does the relay take that partial response and continue sending it up to the root? Could that partial response corrupt the record for that machine?

When he turned the machine back on, the records updated and I could see the content in the console again and I could query for its data.

The agent forms the report and then attempts to transit it to the relay, this operation itself is interruptible and the client will abort reporting if a shutdown of the service or OS happens. If the device hard crashes then the connection should be aborted and the relay should throw away the report as the HTTP transaction didn’t complete.

If there is a concern about what is in the DB, then sending the endpoint a Refresh through the console will re-write the entire DB record for that endpoint.

I’m finding that the device that are online, everything is fine in the DB. Most of the issues I have seen are test machines in the lab that they shut off hard OR other field devices that were shut down hard.

Can’t send a refresh to a device that’s off.

I encountered similar on one of mine today, getting message “Unhandled error: WindowsCharacterSetResult: Error 1113 (No mapping for the Unicode character exists in the target multi-byte code page.) in TranscodeU16ToU8” in the client log and the client stopping immediately after starting the service.

I tried removing the __BESData folder, no joy, then I found in the Registry that one of my client settings was set to an unreadable garbage value (in my case, Wow6432Node\BigFix\EnterpriseClient\Settings\Client\_BESClient_Resource_StartupNormalSpeed had “value” set to a bunch of unprintable bytes).
Deleted that registry value, and the client’s starting normally now.

Not sure how it got corrupted, but the last report from this client was three days ago while installing patches. The uptime was 23 days, this client was not hard-rebooted.

That is very unusual. What version of the client were you using?

Only observed this on one client out of about 500 that patched last weekend.

As part of the patch deployment baseline, they also upgraded from 9.5.4 to 9.5.6. I don’t know whether the value was corrupted before, during, or after the upgrade to 9.5.6. I’ll dig through the logs a little more tomorrow and see whether it ever had a successful startup as 9.5.6, that may give some clues.

Ok so this occurred during a maintenance window where there were several Windows patches along with the BES Client upgrade. The system did not reboot, and applied the following:

windows6.1-kb4038777-x64.msu
ndp46-kb4040973-x64.exe
npp.7.5.1.Installer.exe (Notepad++)
windows6.1-kb4040980-x64.msu
A custom installer for Collabnet Subversion 1.9.7
lync2013-kb4011107-fullfile-x86-glb.exe
BES Client upgrade (from 9.5.4 to 9.5.6)

When the client started again for the client upgrade, it started giving the InvalidTextEncoding and crashing at startup.

I’m not the only one!!! That said, we haven’t seen these in a while. I went on a search and destroy for these bad records and got everything to a good state. Hasn’t come back up again.

Was it always the _BESClient_Resource_StartupNormalSpeed setting?