(Error sending message (type=24), General communication error)

(Error sending message (type=24), General communication error)


we use MC 14.5.4 and have a big problem since 3 weeks with our Zebra Win-Mobile devices, Android and all other devices are not affected.

All working WinMobile devices are online, but if i reset a device and move it to a folder, it goes offline after a short time and doesn't come online anymore. 

The funny thing is, when i change the device name in the Soti Agent on the device, it comes back online, changes the device name on MC and then goes offline again.

I suspected the certificates, but they were not changed. 

The only change was a MC update, from 14.4 to 14.5

TLS 1.0 1.1 and 1.2 is also aktive on both deployment servers

I hope someone can help me.. THX 



ERROR: Socket: The connection has been gracefully closed
EVENT: SCC: Failed to connect to soti.schaeffler.com, port=5494, error=1

Global way of cooperation

4 Answers

Order By:   Standard | Newest | Votes
JCMOD@SOTI | posted this 20 November 2020

Hi ReneKn,


Thank you for posting in SOTI Central.


An interesting issue to read here. Ideally, you need to raise a Support Case and then provide DS Verbose Logs along with the PKCtrlSv.log. We would then try to identify the problem within the logs, one problem could be a Pulse Timeout problem for example. But we would only be guessing without the logs.


What I suggest you do is perform a fresh enrollment of an affected device with the latest agent (you may need to rebuild with the newest version with the Add Device Rule), then reproduce the problem and collect those logs. 


Additionally, if it's possible. I suggest setting up WireShark in a controlled environment, this might be helpful in understanding the issue further. For example, it could be an SSL Handshake problem.


If you can easily reproduce the problem, then you can test a few areas of interest. For example, change your network to a 4G network? Does the newest agent help? Is it reproducible in other environments?



Technical Support | SOTI Inc. |1.905.624.9828 | support@soti.net | www.soti.net |

  • 0
  • 0
ReneKn | posted this 20 November 2020

thanks für your answer!! 

oo yes thats true, I have a lot of experience with MC, but i have never see this behavior.

what exactly do you mean by Pulse Timeout.. ?

i use the newes agent for the enrollment.

WireShark is a good idiea...!!

we use only wlan on this devices and the connection is stable.



2020/11/17 13:25:09.000(0xadc11f5e): EVENT: SCC: Connecting to ws003908.schaeffler.com, port=5494
2020/11/17 13:25:09.000(0xadc11f5e): EVENT: SSL: TargetName: 9E320EBE.ws003908.schaeffler.com
2020/11/17 13:25:10.000(0xadc11f5e): ERROR: Socket: The connection has been gracefully closed
2020/11/17 13:25:10.000(0xadc11f5e): EVENT: SCC: Failed to connect to ws003908.schaeffler.com, port=5494, error=1
2020/11/17 13:25:10.000(0xadc11f5e): DEBUG: WriteMCConnectionStatus: Status = 2
2020/11/17 13:25:10.000(0xadc11f5e): DEBUG: WriteMCConnectionStatus: Registry write SUCCESS
2020/11/17 13:25:10.000(0xadc11f5e): EVENT: SCC: Connecting to, port=5494
2020/11/17 13:25:10.000(0xadc11f5e): EVENT: SSL: TargetName: 9E320EBE.
2020/11/17 13:25:12.000(0xadc11f5e): ERROR: Socket: The connection has been gracefully closed
2020/11/17 13:25:12.000(0xadc11f5e): EVENT: SCC: Failed to connect to, port=5494, error=1

2020/11/17 13:25:53.000(0xec6616d2): ERROR: CerDelete: Certificate (Issuer='MobiControl Root CA', SN='23dea345b0b57ef5') was not found.
2020/11/17 13:25:52.000(0xadc11f5e): DEBUG: ProcessMessage: type 24
2020/11/17 13:25:52.000(0x8de61962): ERROR: Schedule: Reload
2020/11/17 13:25:52.000(0xec6616d2): DEBUG: CMemComm::Write: this 198DE410, dwBufLen 8, m_bServer 1, pMem->m_DataLen 0
2020/11/17 13:25:52.000(0xadc11f5e): ERROR: Failed waiting ACK


this is all what i found.. 

Global way of cooperation

  • 0
  • 0
JCMOD@SOTI | posted this 20 November 2020

Hi ReneKn,


Server Side:

Pulse Timeout is used by DS to keep the device status up to date. This value indicates how frequently the DS sends the pulse to the device to confirm the device is online. This setting can be changed in MCAU > Deployment Server > "Send Test Messages to Devices Every". Under heavy load, the DS is extremely busy and cannot send out such a frequent pulse leading to pulses being delayed. The device will still expect the pulse in 60 seconds, as defined by the parameter, and device disconnection can occur if it doesn’t detect one. 


Client-Side (Agent):

The same principle to devices too, there are ways of modifying it. But it applies mainly to Android deployments.


Regarding your issue, can you double-check that your DS Certificate Binding matches the FQDN of the DS? TargetName: 9E320EBE.ws003908.schaeffler.com jumps out to me. Can you also double-check an affected device and then check the PDB.INI and MCSETUP.ini, do you see any problems with FQDN's not matching up?


On top of that, this issue is reproducible on a newly enrolled device? Is the issue easily reproducible in general too?



Technical Support | SOTI Inc. |1.905.624.9828 | support@soti.net | www.soti.net |

  • 0
  • 0
Raymond Chan | posted this 20 November 2020

Have you also upgraded  (i.e. generated) your MobiControl root certificate when upgrading your MobiControl server to v14.5.4?

What is the length (i.e. the number of bits)  of your SSL certificate bind to the domain ws003908.schaeffler.com?  Is it a single domain or wild-card certificate?

  • 0
  • 0

Give us your feedback
Give us your feedback