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.
Consider the following scenario in Microsoft Dynamics AX 2009, in Microsoft Dynamics AX 4.0, or in Microsoft Dynamics AX 3.0. 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 that resembles the following event:
Event Type: Information
Event Source: Dynamics Server 01
Time: 12:30:14 PM
Event Category: None
Description: Object Server 01: RPC error: RPC exception 1726 occurred in session <SessionID>.
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:
- 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
- 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.
- View the results of the statement. For example, there are three records in the results of the following statement.
Collapse this tableExpand this table
- 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:
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 MarkB 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 he or she encountered the issue and what kind of issues the end-user encountered.
- 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 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.
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.
Article ID: 953375 - Last Review: July 14, 2012 - Revision: 5.0
- Microsoft Dynamics AX 2009
- Microsoft Dynamics AX 4.0
- Microsoft Dynamics AX 3.0
- Axapta Object Server
|kbhowto kbinfo kberrmsg kbmbsmigrate kbexpertiseinter KB953375|