Server instance: FSSSNav71 User: <DomainName>\<UserName> Type: Microsoft.Dynamics.Nav.Types.Exceptions.NavSessionTerminatedException Message: The server stopped the session (ID: 150381) because of a stop session request. StackTrace: at Microsoft.Dynamics.Nav.Runtime.NavApplicationMethod.InvokeMethod(ITreeObject obj, String methodName, Object[] args) at Microsoft.Dynamics.Nav.Service.NSField.DrillDownField(NavSession con) at Microsoft.Dynamics.Nav.Service.NSField.DrillDown(NavSession session) at SyncInvokeDrillDownField(Object , Object[] , Object[] ) at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs) at Microsoft.Dynamics.Nav.Service.ServiceOperationInvoker.ErrorMappingCombinator(ServiceOperation innerOperation, NSServiceBase serviceInstance, Object[] inputs, Object[]& outputs) Source: Microsoft.Dynamics.Nav.Ncl HResult: -2146233088 ---------------------------------- Type: System.Reflection.TargetInvocationException Message: Exception has been thrown by the target of an invocation. StackTrace: at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at Microsoft.Dynamics.Nav.Runtime.NavApplicationMethod.InvokeMethod(ITreeObject obj, String methodName, Object[] args) Source: mscorlib HResult: -2146232828 ---------------------------------- Type: Microsoft.Dynamics.Nav.Types.Exceptions.NavSessionTerminatedException Message: The server stopped the session (ID: 150381) because of a stop session request. StackTrace: at Microsoft.Dynamics.Nav.Runtime.SessionAccessLock.[color=#00FF40]ThrowSessionTerminatedException[/color]() at Microsoft.Dynamics.Nav.Service.ServiceCall.GetClientReturnValue(Action invokeCallback) at Microsoft.Dynamics.Nav.Service.NSClientCallback.[color=#40FF40]FormRunModal[/color](NavForm form, NavFormRuntimeParameters parameters) at Microsoft.Dynamics.Nav.Runtime.NavForm.RunModal(NavRecord record, Int32 fieldNo) at Microsoft.Dynamics.Nav.Runtime.NavForm.RunModal(Boolean isInLookupTrigger, Boolean isLookup, Int32 formId, NavRecord record, Int32 fieldNo) at Microsoft.Dynamics.Nav.Runtime.NavForm.RunModal(Boolean isInLookupTrigger, Boolean isLookup, Int32 formId, NavRecord record) at Microsoft.Dynamics.Nav.BusinessApplication.Codeunit50006.FncWFCockpit_Scope.OnRun() at Filter.InvokeWithFilter(NavMethodScope ) at Microsoft.Dynamics.Nav.BusinessApplication.Codeunit50006.FncWFCockpit(Int32 poptMode, Int32 poptType, NavText ptxtTeamFilter) at Microsoft.Dynamics.Nav.BusinessApplication.Codeunit50006.OnInvoke(Int32 memberId, Object[] args) at Microsoft.Dynamics.Nav.BusinessApplication.Page50119.TxtQueriedAssignedToTeam_a45_OnDrillDown_Scope.OnRun() at Filter.InvokeWithFilter(NavMethodScope ) at Microsoft.Dynamics.Nav.BusinessApplication.Page50119.TxtQueriedAssignedToTeam_a45_OnDrillDown() - User clicked Action button to assign an instruction to their team Source: Microsoft.Dynamics.Nav.Ncl HResult: -2146233088
Comments
This behaviour usually indicts that something went wrong during the upgrade. Objects not fully or correctly upgraded.
What I found strange is that you are talking about FormRunModal() which should not exist in NAV 2013 R2.
NAV 2013 R2 only supports pages and all calls and links should use Page.Runmodal command.
My action would be:
1. Compile all objects and make sure there are no use of Forms or old reports.
2. Try to use standard pages to see if the error still appears.
I hope this helps.
Thanks.
The behaviour, which you have mentioned in your post, is usually seen when you are using wrong build version of Navision (Wrong means lower build version).
Let me explain in more detail as below
Suppose you have upgraded Objects in Navision 2013 R2 Rollup 10. Now you are using Navision 2013 R2 Rollup 7 or Rollup 9 to open Role Tailored Client of Nav 2013 R2 Rollup 10. In this case, I face the same problem which you have reported. Here, When you open Nav 2013 R2 Database in development environment, you will be able to open it in both Build version and Systems will not give you any error but in case of RTC, it will give you error.
So, Please make sure that you are using correct build version to open your Nav 2013 R2 Upgraded Database. After open Database with correct build version in development environment, Compile all objects then try to start RTC Client.
Please do not forget to mark Post as solved it hints have solved your problem.
at Microsoft.Dynamics.Nav.Runtime.NavForm.RunModal(NavRecord record, Int32 fieldNo)
at Microsoft.Dynamics.Nav.Runtime.NavForm.RunModal(Boolean isInLookupTrigger, Boolean isLookup, Int32 formId, NavRecord record, Int32 fieldNo)
at Microsoft.Dynamics.Nav.Runtime.NavForm.RunModal(Boolean isInLookupTrigger, Boolean isLookup, Int32 formId, NavRecord record)
The objects and system we have developed is based on Cumulative Update 8. It would take many days to grapht all the changes onto CU13 so currently we have just upgraded the RTC and middle tier. We started on CU8 with the issue and then upgraded RTC & Middle tier to CU13 to try to fix. We have done a global compile of all objects and restarted the middle tier server and still get the same issue.
We have double checked build numbers on all 5 terminal servers (Which have been running NAV2009 classic only for over a year no problems), the middle tier server, the two middle tier services on this instance. The error occurs both from the Terminal Servers and on the RTC installed on the Middle Tier Server (No network in way). We've tried using the LIVE middle tier server and service rather than the test, just in case it is a problem with the virtualised middle tier server. We've added an extra virtual processor and extra 4GB RAM. It even does it with two users only.
Tonight we are going to try to delete all the blobs in the 'Object Metadata' table so they are recreated when the RTC starts. Has any tried this will all object metadata be recreated.
We also have two separate middle tier instances, one with debugging enabled one without. Clients connect to the middle tier without. The error also occurs without anyone on the second instance, and the second instance was added to try to pinpoint the problem.
Any further pointers would be appreciated
The problem being the users are testing the tailored document 'workflow' modules which they spend 95% of their time in.
I will get one of our team here to test the financials side but we are uncertain when the error occurs it affects other users.
Thank you
I have looked at the error message again
The fun starts with the Page 50119 then it goes to the codeunit 50006
The codeunit 50006 calls Microsoft.Dynamics.Nav.Runtime.NavForm.RunModal ?!?!?!
Is it possible to double check that in the codeunit 50006 there are no calls which use "Form" word.
Sometimes compiler ignores lines or code that call Forms.
You also need to check in the variables.
I Hope this helps.
Thanks.
I exported CU50006 as text and looked for form variables but I cannot see any. Only page variables.
Below is a copy of the C# the middle tier code created from the C/Side code for Codeunit50006
Within this you can see the NavForm.RunModal. I assume the developers of the middle tier were used to forms rather than pages and thus their methods have the word Form in them?
There is something very wrong going on in the CU 50006
Is it possible to copy here functions
FncWFCockpit
FncWFCockpit_Scope
as without looking at the code it will be very difficult to identify what is wrong.
Thanks.
Hope this helps! You can see the RunModals which I believe are called from the factbox...
The test user was not using the system. The error occurred on a Factbox. There is a count of the number of instructions assigned to a user. Something somehow triggered the drilldown on the text box that caused CU50006.FncWFCockpit to trigger. (Well this is what the call stack indicates!)
Thoughts pls... I have been out for 2-3 days... Testing has reduced so the error has not occurred as often so I cannot confirm if it only occurs in custom objects....
Thoughts pls...
I have similar issue after upgrading NAV 2013 r2 form CU4 to CU13.
Errors occurs randomly for only few users when NAV fire code:
I`ve checked everything twice, every user use correct NAV client version. But still don't find solution.
](*,) ](*,) ](*,)
Regards,
One thing that confused us is the stack trace detailed on the previous screen shot is because the user clicked an action on a page that ran a modal form... The modal form sat there until the timeout error was given. The error was then written to the event log containing the full stack track. It is not when the user clicked the action button. This explains why the error occurred at 1am on one occasion, because the users session was left logged in on the modal form.
Pingpong is present on the underlying page, but our developer is adamant it is not ping-pong he removed it for 2 days and the error still appeared in the event log (Also ping pong does not seem to run when there is a modal page opened from the ping pong page).
And I still get this error on custom solution but only on few client machines - all time its the same machines.
I rebuild my solution - my suspicious was temporary record on Page.RUNMODAL function. Now i am using buffer table but it doesnt help.
Client IT guys said that this computers are exacly the same as rest of comuters - there is (propably) no network issues....
We have updated .NET framework on middle tier & the 4 Microsoft Remote Desktop Services servers. All servers have had updates applied. We are now on the point of building a physical middle tier machine and installing it in the data centre separate from the VMware server cluster. (Server is being transported in van tomorrow).
The servers setup has worked fine for NAV2009 Classic for over a year and continues to work fine along side the new NAV2013R2 on VMware server cluster so unsure if replacing the middle tier with a physical machine will help....
Thoughts pls...
We have make workaround for this issue using worksheet page type (in lookup mode) instead of using Page.Runmodal.
Now its working like a charm.
But still its only workaround....
<key="ClientServicesKeepAliveInterval" value="120" />
Do you have services to update server time automatically? If I increment the server time by greater that 2minutes I get the timeout message and can reconnect to same session.
If I reduce this setting to 1 second. I get the error if I increase the server time by > 1 second. This is repeatable but I am not sure if this is the reason for our timeouts... Onsite tomorrow so we will see..
After some testing I managed to, kind of re-create, the same issue. The error message does not pop-up all the time so it is intermittent.
The error message is:
Wojtekm was right the error message happens when you have a structure
IF Page.RUNMODAL = ACTION::OK THEN BEGIN
..
END;
When the page is run (it has to be runmodal ) there is a Dialogue that shows a progress of the action, If I click on "Cancel" to stop it, NAV crashes and the error message in the even viewer is For
IF Page.RUN = ACTION::OK THEN BEGIN
..
END;
everything works fine.
So in my opinion this is a bug that only Microsoft can fix.
It looks like the RUNMODAL causes this issue, as it sends a wrong signal to the server when it is inactive.
It sends a signal that session is closed but in fact only the page is closed.
So I would rise a technical support call with Microsoft.
I hope this helps.
Thanks.
Thank you for your research we have had an open technical support call with Microsoft for some weeks and they are helping us. Sounds extremely familiar I will pass on your findings I'm sure there are issues around this area.
Microsoft have confirmed the client setting ClientServicesKeepAliveInterval is an additional setting that was introduced for Windows Azure...
They state “In NAV 2013 R2 the ClientServicesKeepAliveInterval setting was added which overrides the WCF ReliableSession.InactivityTimeout Property. This makes the default NAV Client session inactivity timeout 2 minutes.”. This setting was also ported back to NAV 2013 via hotfix.
The middle tier code uses this setting at various points, one of these points is when a MODAL PAGE closes to check for inactivity timeouts.
There are issues there but I think they are being exacerbated by the client 'Windows Time' service receiving time updates from the active directory domain controller(s)... We've made some changes and users are testing the system today/tomorrow... Will keep you posted...
*AD1 was setup as type NTP and configured to pickup the current time every 1024 seconds (Approx 17 mins) from NTP.ORG pool of servers on the internet.
*AD2 was setup as type NT5DS configured to pickup the time from AD1 when available.
All other servers/workstations including our middle tier then had 'Windows Time' client service running to pickup the time from the active directory server that they were authenticated by. Either AD1 or AD2. Thus every 1024 seconds (Approx 17mins) these would received time updates from the AD1/AD2.
All fine except...
Somehow, a Boolean had inadvertently been set in VMware on the AD1 VM to pickup the time from the physical 'HOST' it was running on. (This being a cluster of servers did not help either as 2 physical hosts in the server pool)
VMware was updating the time on AD1 back to the HOST RTC every 60 seconds. So for 16 out of 17 minutes the time on AD1 was correct. It would then jump by 5 minutes. This is greater than the <"ClientServicesKeepAliveInterval"> setting of 120 seconds. So when the time jumps forward NAV middle tier times out, but only once in a long while as the middle tier server had to request it's time update in the exact 1 minute interval when the time was wrong on the AD1.
All working now... Thank you everyone for your input... Increasing <"ClientServicesKeepAliveInterval"> did help but there was still the possibility 6-8 months down the line if the HOST RTC went out this would have re-occurred!
I still believe there are issues around <"ClientServicesKeepAliveInterval"> setting and MODAL pages but more information is required...