Microsoft Dynamics AX Support

This blog contains posts by the Microsoft Dynamics AX Support teams Worldwide

Steps to trace an AX session in the application event log back to a user

Steps to trace an AX session in the application event log back to a user

  • Comments 2

If you are experiencing performance issues or AOS crashes, hangs, or memory leaks it could be due to a process that is being done in the system.  It can sometimes be difficult to track down the process that is causing the issue.  If you are getting errors in your application event log on the AOS machine like the following you can use the steps in this article to track a session back to a user.  You can then try contacting the user to find out what they were doing at the time the error was logged.  I have found that the closer to the time of the error that you can talk to the user the better.  For example if the error was 4 hours ago the user is more likely to remember what they were doing when their system crashed than if you talk to them 2 days later.

 

RPC error: RPC exception 1726 occurred in session X. 

No ping from XX.  Terminating the session

SPID XX for session id XX is still present in the database.  Please delete the SPID from the database. 

 

Here are the steps that you can take for Microsoft Dynamics AX 2009

1) Have the session id and the time the error occurred from the application event log

2) Log into Dynamics AX and go to the AOT

3) In the AOT go to data dictionary then tables then sysuserlog

4) Right click on the sysuserlog table and select open (sometimes you have to go to add-ins then table browser)

5) Then on the sessionid column right click and select filter by field and use the sessionid from step 1

6) When the results come up there are usually still quite a few so right click on the createdDateTime column and select filter by field and use the date from the error message in the application event log.  Note that to get the filter to work for just the date you have to enter the date in double quotes like the following "10/21/2009"

7) Then with the results you have find the record where the time is the last one before the error message in the application event log.  If you scroll over for that record you will see the userid column to tell you who the user is.

 

Here are the steps that you can take for Microsoft Dynamics AX 4.0:

1) Have the session id and the time the error occurred from the application event log

2) Log into Dynamics AX and go to the AOT

3) In the AOT go to data dictionary then tables then sysuserlog

4) Right click on the sysuserlog table and select add-ins then table browser

5) Then on the sessionid column right click and select filter by field and use the sessionid from step 1

6) When the results come up there are usually still quite a few so right click on the createddate column and select filter by field and use the date from the error message in the application event log

7) Then with the results you have find the record where the createdtime is the last one before the error message in the application event log.  If you scroll over for that record you will see the userid column to tell you who the user is.

Leave a Comment
  • Please add 8 and 4 and type the answer here:
  • Post
  • So what to do when rpc error's are occuring every two to three minutes?  Probably means a memory leak in a common task?  Perhaps a batch job?  

    Great stuff here.

  • If you are getting frequent and periodic RPC errors.  First determine the RPC error using the error codes at:

    msdn.microsoft.com/.../ms681386(v=VS.85).aspx

    If you can track the session ID and user you may be able to determine the process generating the errors.  Most likely is an automated process like a Dynamics AX batch job, or a web service, or application using a .NET Business Connector.

    You will want to find the process calling the .NET BC and restart it and troubleshoot the specific RPC errors.  As far as a memory leak it is not likely, but such an automated process generating error may lead to an increase in the AOS memory, until the underlying issue is resolved.

Page 1 of 1 (2 items)