01-09-2023, 01:28 PM
Hi Alexandre and thanks for your feedback!
As for ExecProcess, I might try that later, although I will give not give it the highest priority. The reason is as I said earlier that it's within a (non-Intraweb) service that did not undergo any particular changes for the upgrade, plus that we have also already minimized the usage of the sox application.
As for the "Invalid page context" exception, one observation is that we in most (but not all) cases get it on the first form loaded for the session. Now that I think of it, I have actually gotten it myself once. That was when I went to the login page of our main web application and noticed that an image containing our logo was not properly loaded. I then hit F5 or perhaps the refresh button in the browser, and I think this is when the exception came. If I recall correctly, the page was properly loaded after the refresh, and I think I could log on to the application after that. So one theory could be that it occurs when a page for some reason is not properly loaded in the browser. Another observation is that in the two log examples I provided, there should normally be another log line after "Form created:..." triggered by an async timer event (a one-time thing striking after 50 msec) and it is not there. Probably the user has tried to refresh the page later, and that's when the exception comes. My guess is that the request that triggers the exception is synchronous.
Also, I checked some other cases and found one completely different exception where there also was a huge jump in memory (this time 100 MB). Could it be the call stack generation that can take a lot of memory (rather than the particular exception)?. It looks like we have a number of known exception types (such as EExpiredSession) in our code for ServerController.OnException where we don't log the occurrence as an error, and don't generate a call stack (Is that done by setting the Handled parameter to False? I have not written this code and don't fully understand it. Is it the same parameter that controls if you go to the exception renderer or not?). If you think the 'Invalid page context' case is to be considered as harmless, I could do the same for this. Or I could do it for the entire exception class EIWSecurityException (but I am guessing this is not so wise?). Of course I could also try with CheckFormId = False if you think this is better (although we do want to run with maximum web security if possible).
But you are right that this exception probably has little to do with http.sys, we had seen it also before the upgrade of IntraWeb version and the change to using http.sys instead of Indy. I just noted the memory jump associated to it. As it seems, our main web application is the only service that looks a bit suspicious when you look at the memory usage just before the system restarts: My next step could be to try to detect memory and other resource leeks.
Best regards
Magnus Oskarsson
As for ExecProcess, I might try that later, although I will give not give it the highest priority. The reason is as I said earlier that it's within a (non-Intraweb) service that did not undergo any particular changes for the upgrade, plus that we have also already minimized the usage of the sox application.
As for the "Invalid page context" exception, one observation is that we in most (but not all) cases get it on the first form loaded for the session. Now that I think of it, I have actually gotten it myself once. That was when I went to the login page of our main web application and noticed that an image containing our logo was not properly loaded. I then hit F5 or perhaps the refresh button in the browser, and I think this is when the exception came. If I recall correctly, the page was properly loaded after the refresh, and I think I could log on to the application after that. So one theory could be that it occurs when a page for some reason is not properly loaded in the browser. Another observation is that in the two log examples I provided, there should normally be another log line after "Form created:..." triggered by an async timer event (a one-time thing striking after 50 msec) and it is not there. Probably the user has tried to refresh the page later, and that's when the exception comes. My guess is that the request that triggers the exception is synchronous.
Also, I checked some other cases and found one completely different exception where there also was a huge jump in memory (this time 100 MB). Could it be the call stack generation that can take a lot of memory (rather than the particular exception)?. It looks like we have a number of known exception types (such as EExpiredSession) in our code for ServerController.OnException where we don't log the occurrence as an error, and don't generate a call stack (Is that done by setting the Handled parameter to False? I have not written this code and don't fully understand it. Is it the same parameter that controls if you go to the exception renderer or not?). If you think the 'Invalid page context' case is to be considered as harmless, I could do the same for this. Or I could do it for the entire exception class EIWSecurityException (but I am guessing this is not so wise?). Of course I could also try with CheckFormId = False if you think this is better (although we do want to run with maximum web security if possible).
But you are right that this exception probably has little to do with http.sys, we had seen it also before the upgrade of IntraWeb version and the change to using http.sys instead of Indy. I just noted the memory jump associated to it. As it seems, our main web application is the only service that looks a bit suspicious when you look at the memory usage just before the system restarts: My next step could be to try to detect memory and other resource leeks.
Best regards
Magnus Oskarsson