Identifying ABB PPA’s Service ID Modules

In this occasion, I will explain certain aspects about ABB PPA’s (Process Portal A) services that is routinely used by many of its client. Especially the mapping of the service id to their consecutive executable files.

This information is important for troubleshooting the connection problem between ABB client and its server. Usually this problem manifested in the form of the client application appears to be hang, i.e. not responding for indefinite of time.

I’ve came across this symptom when I try to execute my prototype small command prompt application that utilizes the OPC features of ABB PPA. In this case, my application, when activated, seems to be waiting for something in-definitely, and after perform some debugging, it appears to be waiting for some connection object, using the socket modules.

By performing the checking of network status using netstat -a -n -b, it reveals that the application waits to receive some data from port 4224 and 2870 :

The AFWDSO~1.EXE (AFWDsOPCSurrogate.exe) is actually a server stub that gets activated when the client is using the OPC data access methods.

Then, realizing that I haven’t yet activates the server services using ABB Service Manager SCM, I started it and re-run my application. But it is still hangs. Re-checking it using the above netstat command reveals the same port that the client waits for receiving data.

This raises my question as to what kind of server services that the client actually waits, and before long, I’ve found out that the port information is obtain via a call to GetNetworkIdAddresses of AfwSMAddrHdlr.exe module.

This method, in turn perform access of port information through the registry, precisely in HKLMEY_LOCAL_MACHINE\SOFTWARE\ABB\Sigma\Systems\ key path.

Below the Systems node, there are lists of GUID of installed system (called the context) and the current active system is recorded in the WPDefaultContext sub key.

Inside each context guid (i.e. the guids of each system) there are lists of available services and its related parameter. So, in my case, the port 4224 belongs to services with id of {2089E12E-10BC-11D2-8635-0060B0CEAB60}, whereas the port information is located as the substring of port* sub keys, which the asteriks denotes port index. The port 4224 belongs to port index 0 (zero).

But, what kind of the executable module that links to this service id ? To answer this question, I have to verify each of the server services that gets activated when I starts the ABB Service Manager.

When the each of the server services initializes, it calls the ServiceDoInit of IAfwServiceOperations to register the identification data of the service, including the service id, and in the above case, the above id happens to be the property of AfwAppLogSrv.exe server service.

By examining each call to ServiceDoInit method for each service, I can now built the list that correlates the service id and its associated executable module as follows :

AfwAppLogSrv.exe
{2089E12E-10BC-11D2-8635-0060B0CEAB60}

AfwAspDirSrv.exe
{DCC91B1A-BDBB-11D1-B723-0000F878B945}

AfwSNSrv.exe
{E2596CE0-A233-11D1-8979-006097052D4A}

AdvAELogger.exe
{CA00D8A1-6B42-4CEB-96DD-D5CA55770B3C}

AdvAeSoftAlarms.exe
{DAA630D5-A3A3-47EC-BC6D-137B5FC50BE2}

ADVAESRV.EXE
{DFC44E50-B38B-11D1-9717-0060B05C5608}

AdvEAEngine.exe
{77BB3626-E13D-4463-8224-6BE517B45FAF}

AfwFsdSrv.exe
{D7851870-820B-11D2-8E8C-000000000000}

AfwSysMsgSrv.exe
{581ECD70-FC4B-11D1-BEA0-0060085C8452}

AfwTimeSrv.exe
{2F3A558C-E681-11D2-857D-0060B0CEAB60}

AfwXRefSrv.exe
{D15AEC48-2579-11D3-9672-0008C73F2527}

I can now use this list as an important cross referencing next time when connection problem occurs again and also to solve other related problems 🙂