I only had one instance, but it looks like masonje’s screenshot from the console had a valid value for that client setting.
Hi, I noticed a similar error started spamming the relay log on the main BES server:
WindowsCharacterSetResult: Error 1113 (No mapping for the Unicode character exists in the target multi-byte code page.) in TranscodeU8ToU16
this happened at a very specific date and time, no historical records previous. Also gets this referencing relays and other machines. I have been meaning to look back and look at the specif machines referenced but have not had a chance.
not sure if this is related but… text encoding…
I’m in the process of upgrading to 9.5.8.38. Most of our environment updated fine. However I have several agents that have this same issue. They are running on Windows Server 2012 R2.
The upgrade log shows success. This issue started immediately post-upgrade.
Unhandled error: WindowsCharacterSetResult: Error 1113 (No mapping for the Unicode character exists in the target multi-byte code page.) in TranscodeU16ToU8
Client shutdown (Unexpected error)
I checked this value that @JasonWalker suggested, but there was no garbage in the value.
Wow6432Node\BigFix\EnterpriseClient\Settings\Client_BESClient_Resource_StartupNormalSpeed
I scrolled down through the rest of the client settings, but didn’t see anything abnormal.
Windows system log shows:
“The BES Client service terminated with the following service-specific error:
The storage control blocks were destroyed.”
Windows app log shows:
"The description for Event ID 7 from source BESClient cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
Unexpected error"
I even get these messages with AV disabled.
Did @HarthT or anyone else find a solution?
Is the endpoint on the same encoding as the server (ie both on codepage 1252) ?
For this type of failure are there ANY high bit (non ASCII) characters anywhere in the settings in the registry?
I scrolled through literally all the of Bigfix registry entries looking for anything abnormal, but didn’t find any ‘garbage’ characters or incorrect looking values. Is there a way I can search?
I cleared the __BESData of the client. I also reset the local relay, clearing all the site data (thinking maybe something with bad encoding was in there somewhere).
Here is the odd thing. I have over 1000 of a particular server type running 2012 R2 that are all from the same base image and have the same Bigfix configuration. They were all upgraded to 9.5.8 the same way at the same time. A handful are experiencing this issue out of the 1000. Strange.
Post 9.5.8 upgrade (install log shows success), the agent won’t even start (it was working perfectly on 9.5.4 pre-upgrade). Here is the start of the client log:
Current Date: January 24, 2018
Client version 9.5.8.38 built for WINVER 6.0 i386 running on WINVER 6.3.9600 x86_64
Current Balance Settings: Use CPU: True Entitlement: 0 WorkIdle: 25 SleepIdle: 460
ICU 54.1 init status: SUCCESS
Agent internal character set: UTF-8
ICU report character set: UTF-8 - Transcoding Disabled
ICU fxf character set: windows-1252 (Latin 1 / Western European) - Transcoding Enabled
ICU local character set: windows-1252 (Latin 1 / Western European) - Transcoding Enabled
At 20:20:01 -0500 -
Starting client version 9.5.8.38
FIPS mode disabled by default.
Cryptographic module initialized successfully.
Using crypto library libBEScrypto - OpenSSL 1.0.2j-fips 26 Sep 2016
Initializing Site: actionsite
Restricted mode
Client shutdown (Failed loading action site)
The local relay appears to be starting as it should:
Wed, 24 Jan 2018 20:33:19 -0500 - 2852 - BigFix Relay version 9.5.8.38 built for WINVER 6.0 i386 running on WINVER 6.3.9600 x86_64
Wed, 24 Jan 2018 20:33:19 -0500 - 2852 - OpenSSL Initialized (Non-FIPS Mode)
Wed, 24 Jan 2018 20:33:19 -0500 - 2852 - Using OpenSSL crypto library libBEScrypto - OpenSSL 1.0.2j-fips 26 Sep 2016
Wed, 24 Jan 2018 20:33:19 -0500 - 2852 - Signature Algorithms: sha256, sha1
Wed, 24 Jan 2018 20:33:19 -0500 - 2852 - Download Algorithms: sha256, sha1
Starting to uninstall and re-install on these machines because I don’t have a good way of identifying the source of the problem.
Finding several more machines with this same issue including Windows 7 computers.
While re-installing does work, I wanted to find the cause. Apparently there is some corrupt data in the registry for the client. I found by navigating to \Bigfix\Enterprise\Settings then deleting all sub-keys and values cleared up the corruption or encoding issue. Now the client starts up properly. The registry sub-keys automatically regenerate sans the bad data.
2 Likes
So if you open a PMR and provide a “bad” registry export this is probably the best way for us to help find out what is going on.
Did this go anywhere? I just found one with same 19InvalidTextEncoding/TranscodeU8ToU16 error. I had the local support export the registry and mail it to me. Here’s a fun part too. I try to remotely connect to the registry and I get this error:
@JonL, did you open a PMR?
No, I didn’t open a PMR because my work-around has been consistent and easy. Definitely corruption/encoding issues. Go to \Bigfix\Enterprise\Settings then delete all sub-keys and values. Now the client starts up properly and re-generates those registry values.
I had about half dozen of these out of our 13k environment when upgrading from 9.5.4 to 9.5.8.
Thanks.
@AlanM, The site admin is holding the machine for me. when I get all the information I think we need, I’ll start up a PMR.
I’d expect that deleting the settings tree from the registry is “mostly safe”. But preconfigured settings (using clientsettings.cfg when installing, or using OSD to apply when reimaging) don’t get an “effective date” value and I’m not sure the client would recreate them.
Has anyone checked for that?