windows agent down with error code '10054' and '10053'

[Olgun Onur Ozmen]

Hi everone,

   Windows agent was down for a short time.We have seen windows socket error.I told the team it was network issue but this windows agent is on localhost, where automic is installed.
   What does the down of the local agent have to do with the network? What is the relationship with the network?

everything is on local . I do not think there should be any network situation but socket errors make me think.
I'm trying to make sense of this, but would it be your suggestion?

 

on cp log:

20180629/134522.303 - U00003413 Socket call 'recv(1)' returned error code '10054'.
20180629/134522.303 - An existing connection was forcibly closed by the remote host.
20180629/134522.334 - U00003397 Agent 'WINAGENT' logged off (client connection='1').
20180629/135027.713 - U00003413 Socket call 'recv(1704)' returned error code '10053'.
20180629/135027.713 - An established connection was aborted by the software in your host machine.

 

crash log:

Crash time 29/06/2018 13:45:22.225
Image: 'D:\Automic\Agents\Windows\bin\UCXJWX6.exe'
Version: 12.1.0+build.796, 2017-09-18-12:56:26

Process is native type.
System version: Windows Vista

Processor architecture x64
Current thread 2092

Exception information, code 0xC00000FD - The thread uses up its stack.
Exception address 0x00007FF7CE34AE06
Exception flags 0x00000000
Number of parameters 2
0000000000000001 00000000002B3FE8 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000

Register context:
rax=0000000001522F80 rbx=00000000000011E8 rcx=00000A1928395A0E
rdx=00000000000011E8 rsi=0000000000BA8E08 rdi=0000000000004800
rip=00007FF7CE34AE06 rsp=00000000002B3FF0 rbp=00007FF7CE67C040

Stack protocoll:

Thread-ID Address Function
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
... old stack protocoll
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR
0x0000082c 00007FF7CE58E180 uc4::KernelModule::sendChgLogR

Write minidump file '..\temp\crash_131747535222250000.mdmp'

 

--> crash_131747535222250000.mdmp file is empty.

[kreth02]

Hello

 

The communication in the Automic environment is always based on the Network.  This is also on localhost

[FrankMuffke]

Hi

 

usually those messages come from either a software firewall or an Antivirus program.

the first one from one on your agent machine, the second message from one on your AE Server.

If you use SMGR you could check its log to get more infos.

 

cheers, Wolfgang

[LuuLe]

Hi Olgun_Onur_Ozmen,

 

Did Thomas or Wolfgang comment help you in resolving your issue or are you experiencing this?  If their suggestion help in resolving the issues, please use the "Mark Correct" to help us identify which helped you resolve & for future community user.

[Eric Felker]

We had this issue recently, where we were getting "An established connection was aborted by the software in your host machine" in our log. It ended up being something corrupted with the agent in our case. We noticed our .ini file wasn't quite right and our keystore was actually missing. We restored agent files from a backup and agent was able to connect.

 

So in our case, this error was very misleading. Should probably be adjusted if that is possible to avoid sending future readers in a strange direction like engaging security team to look at whitelisting the agent process on your windows host like we did.

 

Eric