How to find a user ID that is associated with a session ID in an error in the Application log on the AOS server in Microsoft Dynamics AX

  • Article

Applies to:   Microsoft Dynamics AX 2009
Original KB number:   953375

Summary

This article describes that you receive the following error message in the Application log in Microsoft Dynamics AX:

RPC error: RPC exception 1726 occurred in session <SessionID>

Also, this article describes how to associate the session ID in the error message to a user ID.

More information

Consider the following scenario in Microsoft Dynamics AX 2009.

You notice that the memory usage increases on the AOS server. Then, you review the Application log on the AOS server to determine the cause. In this scenario, you notice that an event is logged in the Application log.

In this scenario, you may want to find a Microsoft Dynamics AX user ID that is associated with the session ID in the error message. And, you want to understand the business process and what the end user was doing at the time that you have problems.

To determine whether the problem is caused by an end user or by the business process, you can use the session ID from the error message in the Application log on the AOS server. Then, you can relate the session ID to the sysuserlog table in the Microsoft Dynamics AX database. To do this, follow these steps:

  1. Run an SQL statement in SQL Query Analyzer or in SQL Server Management Studio. For example, you run the following SQL statement in SQL Query Analyzer or in SQL Server Management Studio:

    select * from sysuserlog where sessionid = <SessionID> and createddate > '2007/7/17' order by createddate desc

    Note

    • In this script, <SessionID> is the placeholder for the actual session ID in the error message in the Application log.
    • In this script, use a createddate that is greater than (>) a day or several days before the actual date in the error message. Then, you can obtain the date when the end-user logged in to Microsoft Dynamics AX instead of the date of the actual error message.

  2. View the results of the statement. For example, there are three records in the results of the following statement.

    USERID TYPE COMPUTERNAME CLIENTTYPE LOGOUTTIME LOGOUTDATE BUILDNUM SESSIONID TERMINATEDOK CREATEDDATE CREATEDTIME
    Admin 0 MACHINE1 1 57511 7/17/2007 2500.275 10 1 7/17/2007 37944
    Mark 0 MACHINE3 1 0 1/1/1900 2500.275 10 0 7/19/2007 75080
    John 0 MACHINE2 3 41200 7/18/2007 2500.275 10 1 7/20/2007 40326

  3. Use the results of the statement to determine the user who is associated with the session ID in the error message. To do this, follow these steps:

    1. Check the CLIENTTYPE column to determine the type of the connection, and then check the TERMINATEDOK column to verify which client crashed. If the TERMINATEDOK column for a line displays 0 (zero), and if no logoff time is recorded in the LOGOUTTIME column, this means that a client crashed, or an end-user used Ctrl+Alt+Del to end the client process.

      Note

      • Do not use the SESSIONID column because session IDs can be reused.

      • In the sysuserlog table, the values in the ClientType column are as follows.

        Value The meaning that the value represents
        0 Com Object
        1 Client
        2 Server
        3 Worker Thread

        Also, you can find this information about the sysuserlog table in the following object in Application Object Tree (AOT):
        \System Documentation \ Enums \ClientType

    2. Note the value in the USERID column and the COMPUTERNAME column for the client that crashed. Then, determine what was occurring at this client and which user was using the client at that time.

    In the example in step 1, there is no logoff time, and the TERMINATEDOK value is 0 for the second record in the results. Therefore, the user ID for Mark and for MACHINE3 is most likely the end user who is associated with the error message in the Application log. You have to check with the end user to determine whether they encountered the issue and what kind of issues the end user encountered.

To check more recent connections or active connections, check the sysclientsessions table. Also, be aware that session IDs may be reused. Therefore, the current user who uses the session ID may not be the end user who is associated with the error message in the Application log.