Yesterday, 01:48 AM
(This post was last modified: Yesterday, 01:51 AM by alex.trejo@tttnet.com.mx.)
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:
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:
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.
[*]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
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:The relevant stack sequence reported by DebugDiag is:
- 0xC000041D
- Internal exception: 0xC0000005
- Null-address access
- Exception thread OS ID: 6256
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.