When updating user tabs on a set of robots, the hub crashed. We made sure not to select the hub while deploying the update. Hub does not crash when deploying probes to these robots.
Faulting application name: hub.exe, version: 0.0.0.0, time stamp: 0x6773aa75
Faulting module name: ntdll.dll, version: 10.0.14393.7426, time stamp: 0x66f60107
Exception code: 0xc0000005
Fault offset: 0x0000000000066483
Faulting process id: 0x98c
Faulting application start time: 0x01dc232253aab021
Faulting application path: D:\Nimsoft\hub\hub.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: c8f1fe5e-f20c-450f-a1db-9e7634591acb
Faulting package full name:
Faulting package-relative application ID:
23.4 and above
One of the robots had the hub ip listed as the robot ip in the robot.cfg . This caused the restart command to be sent to both servers and the hub was not expecting the request and crashed.
Example, the hub ip is 10.0.0.1 and the robot ip is 10.0.0.2
in the robot.cfg it was set like this:
robotname = robot1
hubip = 10.0.0.1
robotip = 10.0.0.1 <wrong ip>
first_probe_port = 48000
set_qos_source = yes
ip_version = ipv4 ipv6
domain = uim_domain
hub = uim_hub
Correct the robot.cfg.
Please note the Windows event is a generic message for any probe that crashes and not anything specific for the hub. This exact message will be generated when any probe crashes. It is just the Windows standard library noting the crash. There is no information Broadcom can use to analyze the reason for the crash from this windows event.