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 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.
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:
Finally SAP solved the issue performing the following steps:
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:
If nothing of that helped then open a support message to SAP Support and start praying to the Basis Gods.
Two ideas I want to share with you about this case:
I hope you all survived the log4j Apocalypse and Christmas, hopefully you had a great…
I know it is being a while since I posted the last time. So far…
UPDATE 11/25/2020 Adobe released a new patch that solves the issue a few days ago:…
Good news for you fanatics of SAP GUI! SAP will release SAP GUI 7.70 in…
Quick update since I don't have a lot of time lately. During my 2019 job…
It's been a while since the last time I wrote an entry in my blog.…
View Comments
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 :)