We recently migrated a Windows Service application from Indy+TaurusTLS to Http.sys (TIWStartHSys.Execute) in IntraWeb 16 / Delphi 13.
On every successful service start, TIWServiceWorker writes an informational line directly to <exe-name>.log (and to the Windows Event Log):
HTTP(S) server active using binding(s): http://+:80/,https://+:443/
We'd like to handle this ourselves — route it through our own logging infrastructure, decide the format, decide whether/where it gets written — rather than have TIWServiceWorker write it directly and unconditionally.
We looked into intercepting this from our own TIWServerControllerBase descendant, but as far as we can tell TIWServiceWorker is an internal service-bootstrap class unrelated to TIWServerControllerBase, and it runs before our own OnCreate/OnConfig handlers ever get control — so we don't have an obvious hook to intercept it from application code.
Is there a supported event, callback, or override point (on TIWServiceWorker or elsewhere) that lets application code take over this logging, or would this need to be a feature request?
Environment: IntraWeb 16, Delphi 13 (RAD Studio), Windows Server 2022, Http.sys server (IWStartHSys), 64-bit.
Delphi 12.2 IW 16.2.2 32bit ISAPI application
[*]ServerController.ComInitialization = ciNone
[*]IWRtlFix is the first unit in the DPR uses clause, before IWInitISAPI
[*]We are experiencing a recurring crash in a 32-bit IntraWeb ISAPI application hosted by IIS.
The most recent crash occurred on September 7, 2026, at 11:31:16 AM, in w3wp.exe PID 3652.
The outer exception is:
0xC000041D
Internal exception: 0xC0000005
Null-address access
Exception thread OS ID: 6256
The relevant stack sequence reported by DebugDiag is:
TADOConnection.Destroy
→ ADO connection-point Unadvise
→ DestroyAsyncEvents
→ msado15!_FireEventOnMainThread
→ user32!PeekMessageW
→ WM_SETTINGCHANGE
→ repeated IWRtlFix.StdWndProc callbacks
→ call to address 0x00000000
DebugDiag did not have Delphi symbols and displayed the repeated frame as:
SysInit.@_dbk_fcall_wrapper+3EE01E
Using the exact MAP file for the DLL loaded by the crashed process:
SysInit.@_dbk_fcall_wrapper is at $000127A8.
$000127A8 + $003EE01E = $004007C6.
IWRtlFix.StdWndProc begins at $004007B0.
Therefore, the repeated frame is:
IWRtlFix.StdWndProc + $16
This frame appears 338 consecutive times in the reported stack.
DebugDiag also displayed the Delphi caller below ADO as:
IWInitISAPI.TerminateExtension+1374CB
The exact MAP resolves it as follows:
IWInitISAPI.TerminateExtension is at $0041FBE4.
$0041FBE4 + $001374CB = $005570AF.
Data.Win.ADODB.TADOConnection.Destroy begins at $0055703C.
Therefore, this frame is:
Data.Win.ADODB.TADOConnection.Destroy + $73
The Windows message arguments captured in the stack are:
HWND = 0x0FB008A
Message = 0x001A (WM_SETTINGCHANGE)
wParam = 0
lParam = 0x0110D2F8
Memory at lParam contains the following UTF-16 bytes:
64 00 65 00 76 00 69 00 63 00 65 00 73 00 00 00
This decodes to:
devices
The exception context ends with EIP = 0x00000000, consistent with an indirect call to a null procedure address from the StdWndProc/object-instance callback path.
We have observed the same crash signature in multiple w3wp processes and application builds. Previous crashes also involved WM_SETTINGCHANGE with the text “devices”, ADO teardown and a long repeated StdWndProc callback chain.
Moving IWRtlFix before IWInitISAPI changed the addresses and the symbol labels, but did not prevent the crash.
Our current hypothesis is that a window-procedure/object-instance callback is stale, invalid, or recursively linked when ADO pumps Windows messages during TADOConnection destruction. We understand that the precise underlying lifecycle defect still needs confirmation.
Could you please advise:
Is this a known issue in IWRtlFix or IntraWeb 16.2.2?
Is there a newer IWRtlFix implementation or patch applicable to Delphi 10.2.3?
Could the patched StdWndProc/object-instance implementation retain an invalid callback during ADO message pumping?
Are there additional diagnostics we can add around IW_MakeObjectInstance/IW_FreeObjectInstance?
Is there a recommended way to prevent this interaction during TADOConnection destruction?
The attached DebugDiag CrashHangAnalysis report contains the complete reported stack and module information.
We can provide the full dump privately if it is strictly required, but we prefer to begin with the report and the symbol/memory evidence above.
Thank you.
(Yesterday, 01:48 AM)alex.trejo@tttnet.com.mx Wrote: Delphi 12.2 IW 16.2.2 32bit ISAPI application
[*]ServerController.ComInitialization = ciNone
[*]IWRtlFix is the first unit in the DPR uses clause, before IWInitISAPI
[*]We are experiencing a recurring crash in a 32-bit IntraWeb ISAPI application hosted by IIS.
The most recent crash occurred on September 7, 2026, at 11:31:16 AM, in w3wp.exe PID 3652.
The outer exception is:
0xC000041D
Internal exception: 0xC0000005
Null-address access
Exception thread OS ID: 6256
The relevant stack sequence reported by DebugDiag is:
TADOConnection.Destroy
→ ADO connection-point Unadvise
→ DestroyAsyncEvents
→ msado15!_FireEventOnMainThread
→ user32!PeekMessageW
→ WM_SETTINGCHANGE
→ repeated IWRtlFix.StdWndProc callbacks
→ call to address 0x00000000
DebugDiag did not have Delphi symbols and displayed the repeated frame as:
SysInit.@_dbk_fcall_wrapper+3EE01E
Using the exact MAP file for the DLL loaded by the crashed process:
SysInit.@_dbk_fcall_wrapper is at $000127A8.
$000127A8 + $003EE01E = $004007C6.
IWRtlFix.StdWndProc begins at $004007B0.
Therefore, the repeated frame is:
IWRtlFix.StdWndProc + $16
This frame appears 338 consecutive times in the reported stack.
DebugDiag also displayed the Delphi caller below ADO as:
IWInitISAPI.TerminateExtension+1374CB
The exact MAP resolves it as follows:
IWInitISAPI.TerminateExtension is at $0041FBE4.
$0041FBE4 + $001374CB = $005570AF.
Data.Win.ADODB.TADOConnection.Destroy begins at $0055703C.
Therefore, this frame is:
Data.Win.ADODB.TADOConnection.Destroy + $73
The Windows message arguments captured in the stack are:
HWND = 0x0FB008A
Message = 0x001A (WM_SETTINGCHANGE)
wParam = 0
lParam = 0x0110D2F8
Memory at lParam contains the following UTF-16 bytes:
64 00 65 00 76 00 69 00 63 00 65 00 73 00 00 00
This decodes to:
devices
The exception context ends with EIP = 0x00000000, consistent with an indirect call to a null procedure address from the StdWndProc/object-instance callback path.
We have observed the same crash signature in multiple w3wp processes and application builds. Previous crashes also involved WM_SETTINGCHANGE with the text “devices”, ADO teardown and a long repeated StdWndProc callback chain.
Moving IWRtlFix before IWInitISAPI changed the addresses and the symbol labels, but did not prevent the crash.
Our current hypothesis is that a window-procedure/object-instance callback is stale, invalid, or recursively linked when ADO pumps Windows messages during TADOConnection destruction. We understand that the precise underlying lifecycle defect still needs confirmation.
Could you please advise:
Is this a known issue in IWRtlFix or IntraWeb 16.2.2?
Is there a newer IWRtlFix implementation or patch applicable to Delphi 10.2.3?
Could the patched StdWndProc/object-instance implementation retain an invalid callback during ADO message pumping?
Are there additional diagnostics we can add around IW_MakeObjectInstance/IW_FreeObjectInstance?
Is there a recommended way to prevent this interaction during TADOConnection destruction?
The attached DebugDiag CrashHangAnalysis report contains the complete reported stack and module information.
We can provide the full dump privately if it is strictly required, but we prefer to begin with the report and the symbol/memory evidence above.
Thank you.
I am in the process of migrating our main web application from IW 15.2.49 (our current production version) to 16.2.4. When trying to test the web application (built with the latest IW version) with FireFox, I have run into several issues that might be closely related. To the FireFox user, the symptom is that the (next or updated) page never is loaded, you just see the spinner on the (current page) for a long time until it eventually times out with the error message NS_ERROR_NET_EMPTY_RESPONSE . For Chrome and Edge I see no issues. A setting that might be of importance here is that we run with AllowMultipleSessionsPerUser=True (for security reasons, if a tab for a user serssion is closed without making a logout, it should not be possible to reopen the same session).
The first issue is when we apply a security feature on our login page in order to change the response to a redirect when we do a POST when the user has entered senstive information. If I recall correctly it was suggested by you when discussing a finding from a customer penetration test. We call a helper procedure ChangeResponseCodeFromOKToRedirectAndStayInSession which calls another procedure like this:
procedure ChangeResponseCodeFromOKToRedirect(const URL: string);
begin
if (WebApplication.Response.Code < 301) or (WebApplication.Response.Code > 303) then
WebApplication.Response.Code := 302;
if WebApplication.Response.Headers.IndexOfName('Location') < 0 then
WebApplication.Response.AddHeader('Location', URL);
end;
Based on AI suggestions, I changed the response code to 303, which seemed to bypass this first FF issues (and still work in Chrome ande Edge). Is this a sensible modification in your opinion?
The second issue comes in the next step in the login process where we after successful authentication change the session ID (also for security reasons). We do this by calling
Code:
WebApplication.ResetApplicationID;
Again, this was a method added by you as a result of discussing penetration test findings. FF hangs as described above after this is called. I have experimented with workarounds but so far found no other than actually skipping this step when WebApplication.Browser is TFireFox. Do you have a sugegstion for another workaround that would actually change the session ID? Or is this something that should be fixed in the IntraWeb code for an upcoming release?
The third issue is when the user clicks Logout in the menu of our web application. Our code determines a logout page URL (which could be a static HTML page hosted by the web application) and then calls WebApplication.TerminateAndRedirect to this URL. Same issue, FF hangs. Based on AI suggestions, I wrote the following workaround:
Code:
if WebApplication.Browser is TFireFox then
begin
ReportStandardEventToLogCentral(letHint, 'Using ExecuteJS to redirect to the logout page due to Firefox/IW16 issue,'
+ ' session will not actually be terminated until timeout but Logout will be called to finalize our own resources.');
Logout();
WebApplication.ExecuteJS('window.location.replace("' + LogoutURL + '")');
end
else
WebApplication.TerminateAndRedirect(LogoutURL);
Is there a better workaround that actually terminates the session immediately? Or should the IntraWeb code for WebApplication.TerminateAndRedirect be fixed?
If I test it with Rad Studio REST Debugger, I get the expected response sent by my TContentHandler: 204 (nothing to be returned)
But when the server (a Twilio Server) send the POST request, it first seems to be working, then it gets the response below:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name='viewport' content='width=device-width, initial-scale=1'>
<title></title>
<script nonce="8g0lADvTJQAPKt1IoVJ+uVzmTTs">function getWS(){var o=0,l=0,t=document,r=window.devicePixelRatio||1;return"CSS1Compat"==t.compatMode?(o=Math.max(t.body.scrollWidth,t.documentElement.scrollWidth),l=Math.max(t.body.scrollHeight,t.documentElement.scrollHeight))o=t.body.scrollWidth,l=t.body.scrollHeight),[o,l,r]}function cookieCheck(){var o=navigator,e=document,i=!!o.cookieEnabled;return void 0!==o.cookieEnabled||i||(e.cookie="testcookie",i=-1!=e.cookie.indexOf("testcookie")),i}function isIFrame(){if(window.location!==window.parent.location)return 1;return 0;}function init() {if(!cookieCheck()){alert("This application requires cookies to be enabled. Please enable cookies in your browser's settings, close your current web session and try again.");throw "Cookies are disabled.";}var s = getWS();var f = document.forms[0];f.elements["IW_width"].value = s[0];f.elements["IW_height"].value = s[1];f.elements["IW_dpr"].value = s[2];f.elements["IW_iframe"].value = isIFrame(); f.submit();}</script>
</head>
<body>
<form method=post action="/?AccountSid=&Hold=false&Muted=false&SequenceNumber=1&StartConferenceOnEnter=true&StatusCallbackEvent=participant-join&Timestamp=Sat, 29 Aug 2026 01:17:31 +0000">
<input type=hidden name="IW_width">
<input type=hidden name="IW_height">
<input type=hidden name="IW_dpr">
<input type=hidden name="IW_iframe">
<input type=hidden name="IW_SessionID_" value="sbOFyXruzqeZFPneOENgcNbBGtC">
<input type=hidden name="IW_TrackID_" value="1">
<input type=hidden name="IW_WindowID_" value="l88Os8sKLIbJ2zvpQneeVxT2kJG">
<input type=hidden name="IW_RestartCheck_">
<script nonce="8g0lADvTJQAPKt1IoVJ+uVzmTTs">init();</script>
</form>
</body>
</html>
The code of the response 200 which seems Ok.
But in fact it is an error response sent by the Intraweb application:
"This application requires cookies to be enabled. Please enable cookies in your browser's settings, close your current web session and try again."
And it seems to be related to the option CookieOptions > RuncookieCheck.
The CookieOptions in my applications are:
HttpOnly=true
SameSite=ssoLax
Secure=true
SessionCookies=true
UseCookies=true
For sure I cannot ask users to go change cookies settings in their browsers before to be able to use my application!
So, how to resolve this?
Hello. I purchased an IntraWeb Ultimate license, and according to the documentation, it includes the source code for certain modules. I would like to know where I can download them, as I need to understand how some options work, and examining the source code makes that easier. I apologize if this isn't the right channel for this request; if you could point me to the correct place to submit this inquiry, I would appreciate it.
Hello, I have an issue: I am using IntraWeb Ultimate version 16.2 and trying to change the language for the DataTable in an IWDBGrid. However, the URL IntraWeb generates for the Spanish language settings is invalid—it points to a location that is no longer active (https://cdn.datatables.net/plug-ins/1.10...es-ES.json). How can I change that URL, or where can I download the source files to make the change myself? Thanks.
I'm working on a business catalog website using web technologies, and I'm looking for some advice on creating a clean and responsive user interface.
The project is for a company that showcases Office Furniture in Dubai, so the website contains product categories, image galleries, contact forms, and inquiry pages. My main goal is to make the site load quickly while keeping the layout simple and user-friendly.
For those who have experience with IntraWeb or Delphi web applications:
Which UI components work best for product catalog pages?
Do you have any recommendations for improving page performance when displaying many images?
Is there a preferred approach for responsive layouts that works well across desktop and mobile devices?
I'd appreciate any suggestions, best practices, or examples from your own projects.
I have a HTTP Server that performs the upgrade to a WebSocket server after serving the client with the html file containing the websocket client code on connect. Everything is working fine except the original TCP Thread is hanging in there as a ghost thread after the websocket upgrade, that is using a new thread.
I am looking for a possible way on how to terminate that thread. I can post the relevant snippet where the upgrade is happening, if required.
This is based on TIdCustomTCPServer and staspiter Websocketserver.
o=t.body.scrollWidth,l=t.body.scrollHeight),[o,l,r]}function cookieCheck(){var o=navigator,e=document,i=!!o.cookieEnabled;return void 0!==o.cookieEnabled||i||(e.cookie="testcookie",i=-1!=e.cookie.indexOf("testcookie")),i}function isIFrame(){if(window.location!==window.parent.location)return 1;return 0;}function init() {if(!cookieCheck()){alert("This application requires cookies to be enabled. Please enable cookies in your browser's settings, close your current web session and try again.");throw "Cookies are disabled.";}var s = getWS();var f = document.forms[0];f.elements["IW_width"].value = s[0];f.elements["IW_height"].value = s[1];f.elements["IW_dpr"].value = s[2];f.elements["IW_iframe"].value = isIFrame(); f.submit();}</script>