After change to http.sys, errors on production servers after a few days of operation

[Alexandre Machado]

Could it be the call stack generation that can take a lot of memory (rather than the particular exception)?

I don't think the call stack generation would cause a jump in memory usage that could be perceived like that

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?)

When an exception happens, IW will do this:
1- Log the exception using the standard ExceptionLogger (if enabled)
2- Call any other registered 3rd party exception handlers (E.g. EurekaLog). If any exist and returns TRUE, then IW considers the exception as Handled (see 3 below)
3- Generate the ServerController.OnException event. This event contains the Handled var parameter as you mentioned. If Handled returns TRUE, IW will stop any processing related to this exception, otherwise it will:
4- Call the registered exception renderer class which is responsible for generating that standard error page. The call stack is obtained during this stage.

So, you are correct. If Handled somehow returns True (because of some 3rd party exception handler or your own code) the call stack is not obtained.

If you think the 'Invalid page context' case is to be considered as harmless, I could do the same for this

It is harmless as long as you only get it on this especial circumstances (i.e. a user refreshes the page after the page loading somehow got broken). If you get several exceptions of that type during normal usage it may indicate a problem with your code, a 3rd party library (e.g. TMS, CG DevTools) or a bug in IntraWeb itself which hasn't been detected.

I would suggest you to force an "Invalid Page Context" error in your dev environment (while debugging) and see if FastMM can detect any memory leak.

It is kind of simple to force this. Run the application, open the browser dev tools (F12). Scroll to the bottom of the "inspector" view and find the "IW_FormID_" hidden field. Edit its content and change the value. Now you just need to post this page (any button with an associated event should do it) or even refresh it pressing F5.
Now, after generating the "Invalid Page Context" error, all you need to do is to terminate the application and see if FastMM reports anything.

If you need some help on using FastMM4 to find memory leaks we have created a nice how to here: 

https://www.atozed.com/2021/07/detecting...-fastmm-4/

And also with Deleaker, which is another nice tool that works with any memory manager: https://www.atozed.com/2022/07/detecting...-deleaker/