I'm using the TaurusTLS components in my app for both SMTP and making calls to Microsoft Graph. It's replaced earlier calls using the Indy SSL components. I've put the OpenSSL 4 DLLs in the application directory and it all works fine.. EXCEPT... it seems I still have to leave the old OpenSSL libraries as well! If I remove them, I get an error on startup that the SSL library couldn't be loaded. I'm using the latest Intraweb version - is there any setting in the server controller to manage this or does Intraweb still use those old libraries for listening?
Any image that I create and a TIWPaintBox seems to be clipped at 1000 pixels horizontally. I have checked that clipping is not enabled on the containing component. Can anyone tell me why this may be?
How does Intraweb and IWDevTools (to give it its new name!) decide whether to load the readable CSS version or the minimised version? I have two apps that behave differently (one loads cgcss and the other cgcss-min) so I guess I must have a setting somewhere - but I've no idea where it is! Can you tell me, please?
Hello. I’m unable to link a project that uses the TIWSummernote component because the required object files (IWCompSummernote.obj/IWCompSummernote.o) are missing from the installation folder.
I am trying to figure out a way to implement a kanban like control where I have columns of items that I can drag from one column to next. Is there a general way to accomplish this with any known IW components?
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.
(09-08-2026, 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?
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>