A few weeks ago one of my customers have an issue with an SAP ERP system running on SLES 12 + SAP HANA 1.22. The dammed error message “back-end session terminated” appeard which usually means having fun checking really inside of the SAP system. I think this case is quite interesting because the solution was completely different to what we though in the beginning. It also taught me a quite valuable lesson 🙂
The problem
The customer performed a system refresh from PRD to QAS in a SAP ERP system. After finishing the system refresh there was an issue when executing some transactions. For example, if I executed the XDN1 transaction we got the following error message:
SID: SAP System Message: Work process restarted; back-end session terminated
This error message appeared as a pop-up when executing the transaction, closing the current SAPGUI window. The same issues appeared on different situations like using the technical help, generating profiles with PFGC transaction or using VA01 transaction.
The investigation
First thing I did was checking the work process trace. The reason is because each time a work process dies or when we get the error message “back-end session terminated” the reason is written in the WP trace. Even if you don’t understand the trace file the reason is still there so you can look for a solution considering this information. In this case when the WP died there was the following messages:
The first part is a warning related to an insufficient value of the vm.max_map_count. I checked the OS and the parameter vm.max_map_count wasn’t even defined in the /etc/
The second part is the error message itself. It just says that the session has been deleted with the error ERROR-CORE-PROCESS_CRASHED. This could be caused by different reasons. For example, if the roll area is insufficient then the user’s session in the WP will die. Unfortunately this wasn’t the case, the system had enough memory in all the areas for executing the transaction.
Next thing to check was the SQL queries being executed in the system while executing the XDN1 transaction. I got the SQL queries doing a performance trace in the SAP system and then I executed the queries directly in the HANA database. Everything worked correctly so the problem was not related to the database.
I had no clue for solving the issue so I decided to contact the SAP Support. They provided the following notes so I had to check if any of them solved the issue:
- 2491252 – Storage area for GUI status MENUSYST too small: SAP note related to memory areas. It says that you have to increase the value of the parameter ztta/cua_area. We increased the value to 10000000 and it didn’t work. It is also strange because the memory parameters are automatically calculated with Kernel 742 and superior versions.
- 2650210 – SYSTEM_CORE_DUMPED in cuaNumberIcontextEntries: We performed the steps described in the first part and it didn’t work. The second part was added after our support message.
The solution
Finally SAP solved the issue performing the following steps:
- Start transaction SE41
- Enter “SAPLSHL2” for field “Program”
- Enter “F1HELP” for field “Status”
- Select from menu: “User Interface” → “Activate”
These steps solved all the issues we had with different transactions and the technical help. It is quite interesting because I’m still trying to figure what happened after the system refresh that could cause these errors. We performed the same system refresh procedure dozens of times in the system and we never had this issues.
In case you have these kind of issue in the future I would recommend checking the following:
- The work process trace file. You can get them directly in the OS or using ST11 transaction.
- OS trace files such as Windows event monitor or /var/log/messages in Linux OS.
- Memory parameters on both OS and SAP instances.
- SQL queries being executed while using the transaction. Check those queries directly in the database if you can.
If nothing of that helped then open a support message to SAP Support and start praying to the Basis Gods.
Conclusions
Two ideas I want to share with you about this case:
- Sometimes thinking “out of the box” helps a lot for finding the origin of the problems. If you tried everything and it didn’t work try changing the approach
- Being honest I would never guess how to fix this issue without the help of SAP Support. Sometimes a cry for help is better than be stuck in the same problem over and over.
Thank you so much for posting this!!! After our PRD->QAS refresh one user complained of a similar problem. He sessions were closed as soon as she switched to a different applications (Outlook). SM04 still showed her being logged on, so she was forced to re-log in and terminate existing session.
I asked her to do the same in the QAS system and the problem was the same there. I applied the solution (SE41) in QAS, and it fixed the problem. What is more interesting, it also fixed her PROD problem as well!!! I did not have to do the same in production! As soon as the QAS was performing normally, the production sessions stayed in the foreground too.
I’m glad you fix the issue Julie 🙂 What is pretty interesting is that performing the same steps in QAS also solved the PRD problem. The steps I descried are system-dependent and performing them in QAS won’t affect PRD. Maybe the user was trying to connect to the same system over and over again? Who knows, I’m glad it worked 🙂