Atozed Forums - IntraWeb General Discussion

Strict CSP Implementation

Thu, 29 Oct 2026 14:32:54 -0400

Hello everyone,

I am currently working on hardening an IntraWeb application (IW 16.1.9, standalone execution) that relies on HTML Bootstrap templates and custom JavaScript/jQuery.

During a recent penetration test and security audit, the use of 'unsafe-eval' and 'unsafe-inline' in our Content Security Policy (CSP) headers was flagged as a high-risk finding.

While we are in the process of implementing dynamic request-based nonce values for external scripts and templates, we understand that IntraWeb's core rendering engine heavily relies on:

Inline event handlers (onclick, onchange, etc.) generated by native IW controls.

Async/AJAX response processing, which dynamically evaluates incoming JS snippets on the client side.

Given these architectural constraints:

Is there an official or recommended pattern to achieve strict CSP compliance within IntraWeb without breaking the core AJAX functionality?

Beyond using nonces, are there specific ServerController configs, event hooks, or best practices to eliminate or strictly limit the exposure of 'unsafe-eval' and 'unsafe-inline'?

Any insights, workarounds, or roadmap details regarding future CSP enhancements in IW 16.x would be greatly appreciated.

Thanks in advance for your guidance!

Best regards

Form doesn’t resize with browser window

Thu, 29 Oct 2026 05:48:37 -0400

Hello! When I create a form and place some controls aligned to the top and bottom, they display nicely as expected when the browser window is maximized. However, if I resize the browser window, the self.clientwidth and self.clientheight on the form are not updated. Instead, scrollbars appear in the browser window. How can I prevent this?

Simply replacing the IW icons

Wed, 28 Oct 2026 06:31:57 -0400

Hello,

I am looking to replace the original IW icons with my own
Normaly, this should be a simple procedure, right?

Simply replacing the IW icons

Wed, 28 Oct 2026 06:30:34 -0400

Hello,

I am looking to replace the original IW icons with my own
Normaly, this should be a simple procedure, right?

IWDevTools

Mon, 26 Oct 2026 09:19:52 -0400

1. The variable "IWCGJQCompsFiles" is set correctly, yet it is not being applied to the CGDevTools controls. They are not rendered. Did I miss something?

2. One of the forms in my project is based on TIWCGJQFrame. It contains a TIWCGJQRegion with `Align = alLeft`. However, instead of being aligned to the left, it appears approximately 200–300 pixels further to the right. Everything works correctly when using an older version of CGDevTools.

Thanks, Andreas.

SpinBox Button Size

Mon, 19 Oct 2026 14:12:21 -0400

The up/down buttons on a TIWCGJQSpinEdit are very, very small on form creation! Pressing F5 or even F12 for developer tools puts them right, but it's annoying for the end user. Is there a simple fix so that they appear properly, right from the go?

Rerendering CG Tab Control

Mon, 19 Oct 2026 13:21:34 -0400

I have some controls that dynamically cause tabs on a TIWCGJQTabs control to appear or disappear, depending on their value. Up until now, I've used AjaxRerender on the TIWCGJQTabs to reflect the change immediately. However, if there is a TIWCGJQGrid on the tab being revealed, it does not render properly (or at all, really) in the latest DevTools version. I have to do a full refresh of the whole form for it to appear. Any suggestions?

SSL Revisited

Fri, 16 Oct 2026 12:37:06 -0400

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?

Help with TIWPaintBox

Tue, 13 Oct 2026 04:44:52 -0400

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?

CSS in CGDevTools

Sun, 11 Oct 2026 15:34:11 -0400

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?

TIWSummernote Issue

Tue, 29 Sep 2026 23:38:22 -0400

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.

KanBan like behaviour

Tue, 29 Sep 2026 14:54:15 -0400

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?

- Lou

WebApplication.IP change from IW15.x to IW16.2

Tue, 08 Sep 2026 23:02:52 -0400

I have a dll which in Audit records user activity and IP, using WebApplication.IP. This under delphi 10.2.3 and IW15.x

A new application using same audit (Delphi 12.2 IW16.2), reports under WebApplication.IP our internal server rather than user IP.

Should I use a diferent routine?

Hook/callback to handle the "HTTP(S) server active using binding(s)" startup log line

Tue, 08 Sep 2026 05:03:04 -0400

Hi,

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 .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.

Thanks!

Reproducible IIS crash involving IWRtlFix.StdWndProc during ADO connection destructio

Mon, 07 Sep 2026 21:48:52 -0400

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.

Atozed_MAP_symbol_extracts.txt (Size: 1.71 KB / Downloads: 0)

w3wp__hemologyx__PID__3652__Date__09_07_2026__Time_11_31_16AM__209__Second_Chance_Exception_C000041D_CrashHangAnalysis.zip (Size: 249.99 KB / Downloads: 0)