	Product(s):	APM Implementation and Performance Management
	Version(s):	7
	Environment:	N/A
	Area:	N/A
	Subarea:	N/A

Problem Description

An APM user using multiple Smart Client application services was running into stale services. The user's administrator was able to determine that each time a specific end-user would go to a specific remote in APM foundation and review the Synchronization view > upload transactions tab, the user session would run into a fatal exception. The user would then exit APM naturally (exit and logoff) after a small delay. About 30s to 1minute after the initial fatal exception error, one of the other smart client services would go stale but not the application server that the user was initially logged on to. Relaunching the application as the same user, coincidentally to the same application server and repeating the procedure would result in another application server going stale, again not the application server the user session was assigned to. The user again launched a session, was assigned to the same service, and repeated the same procedure. This time the only application service still running went stale.

The error logs for the server indicated the following:

2023-01-12 00:00:00.0000Z Error Domain\Username Ivara.PL.FatalExceptionPolicy [26] AccessViolationException, with message Attempted to read or write protected memory. This is often an indication that other memory is corrupt., caught at: [?GetMCLBDataAsDataSet@InternalResultSet@PL@Ivara@@$$FQE$AAMPE$AAVIvaraDataSet@Control@UIData@Data@23@HHHAE$CAPE$AAVPLResult@723@@Z,C:\a\1\s\PresentationLayer\PL\ResultSet.cpp,469]

Solution

Review of the detailed user action logs and error logs (debug level) indicated that user's default personal configuration was the trigger. Accessing the configuration via the Enterprise level, Customization Center view > User Interface tab > Configurations sub-tab, it was found the configuration contained an XML column. It is known that XML data type columns are likely to result in issues/crashes when referenced in a configuration. Updating the configuration to delete the XML column from the configuration resulted in allowing the user to then navigate to the Remote Computer > Synchronizations > upload transactions tab successfully without crashing any application servers.

XML data used in a configuration will crash application service and lead to stale servers

Problem Description

Solution

See also