Recent Posts
1
Web Server - Ask For Help / Re: GPF on Line=1774 Proc=SSL_OUR_SERVERSWITCHTOSSL
« Last post by jlavera on May 19, 2026, 09:21:33 AM »Can somehow sharing a certificate among servers can cause this? I have two servers sharing a folder and a certificate, and both are showing this sporadic GPF problem. Other servers not sharing, does not.
2
Web Server - Ask For Help / Re: GPF on Line=1774 Proc=SSL_OUR_SERVERSWITCHTOSSL
« Last post by jlavera on May 18, 2026, 04:12:56 AM »Hi, Bruce.
I'm not sure how we solved that, but it was working fine in NT 12.47.
We needed some new features so we migrated to NT 14.37 - now, the problem started again.
With the server sitting idle, just answering "pings", it GPFs each 6 or so hours.
Basically, same GPF as this old case.
I'm sure all the dlls are matching NT 14.37, libcrypto-3.dll is 3.5.1.0, LibSSL-3.dll is 3.5.1, clanet.dll is 14.37.0.0, all in the program's folder.
Note in the GPF there is no mention of any other program, just clanet.dll and clarun.dll.
Is there any other resource I should check?
Why is it calling SSL_OUR_SERVERSWITCHTOSSL? Our "unsecure" port is closed, there is nothing coming from there (all connections are TLS).
Is this needed? Can be disabled somehow?
Program : F:\SMSRestServerMobileDevOps\SMSRestWebServer.exe
Version : 5276.14.4.548
At : 19:23:22 on 2026/05/18
Workstation: : ALCHEMY-RDSH-02
User Name: : ALCHEMY-RDSH-02$
Reported error : EXCEPTION_ACCESS_VIOLATION - Error writing data at : 00000000h
Windows : Win 10 - 10.0.17763
Clarion : 0.9
Thread : 3 Field : 0 Event : 523 Keycode : 0
Error at address : 00000000h no module
Stack Trace
7417CE89h Line=2072 Proc=SSL_OUR_SERVERSWITCHTOSSL@F Src=netdl020.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[01] 7417CE89h Line=2072 Proc=SSL_OUR_SERVERSWITCHTOSSL@F Src=netdl020.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[02] 741706C6h Line=1794 Proc=SIMPLESERVER_ACCEPT@Fll Src=netdl017.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[03] 741487E0h Line=1158 Proc=CALLBACKWINDOWCLIENTCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[04] 76E96D1Bh no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[05] 76E877CCh no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
72F0BDC0h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72F0BDC4h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72F0BDBCh Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[06] 76E8690Bh no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[07] 76E7CC60h no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
[08] 72EA0B48h Line ?=27 no proc Src="Library State" Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
74148C28h Line=819 Proc=CALLBACKWINDOWSRC@F Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
72EE1E3Ah Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EC36E8h Line ?=27 no proc Src="Library State" Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
[09] 74148F1Eh Line=857 Proc=CALLBACKWINDOWSRC@F Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[10] 72E83FC3h no line number no proc Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EFCFC4h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EDDE6Eh Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
[11] 72E83AA1h no line number no proc Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EDDE84h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EFCFC4h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EFD044h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EF1360h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EF1374h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EF1390h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EF1384h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EF13ACh Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EF13A0h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
[12] 77817E4Dh no debug info, Module=C:\windows\SYSTEM32\ntdll.dll 10.0.17763.6292 (WinBuild.160101.0800)
[13] 77817E1Dh no debug info, Module=C:\windows\SYSTEM32\ntdll.dll 10.0.17763.6292 (WinBuild.160101.0800)
Kind regards,
Jorge Lavera
I'm not sure how we solved that, but it was working fine in NT 12.47.
We needed some new features so we migrated to NT 14.37 - now, the problem started again.
With the server sitting idle, just answering "pings", it GPFs each 6 or so hours.
Basically, same GPF as this old case.
I'm sure all the dlls are matching NT 14.37, libcrypto-3.dll is 3.5.1.0, LibSSL-3.dll is 3.5.1, clanet.dll is 14.37.0.0, all in the program's folder.
Note in the GPF there is no mention of any other program, just clanet.dll and clarun.dll.
Is there any other resource I should check?
Why is it calling SSL_OUR_SERVERSWITCHTOSSL? Our "unsecure" port is closed, there is nothing coming from there (all connections are TLS).
Is this needed? Can be disabled somehow?
Program : F:\SMSRestServerMobileDevOps\SMSRestWebServer.exe
Version : 5276.14.4.548
At : 19:23:22 on 2026/05/18
Workstation: : ALCHEMY-RDSH-02
User Name: : ALCHEMY-RDSH-02$
Reported error : EXCEPTION_ACCESS_VIOLATION - Error writing data at : 00000000h
Windows : Win 10 - 10.0.17763
Clarion : 0.9
Thread : 3 Field : 0 Event : 523 Keycode : 0
Error at address : 00000000h no module
Stack Trace
7417CE89h Line=2072 Proc=SSL_OUR_SERVERSWITCHTOSSL@F Src=netdl020.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0[01] 7417CE89h Line=2072 Proc=SSL_OUR_SERVERSWITCHTOSSL@F Src=netdl020.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[02] 741706C6h Line=1794 Proc=SIMPLESERVER_ACCEPT@Fll Src=netdl017.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[03] 741487E0h Line=1158 Proc=CALLBACKWINDOWCLIENTCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0[04] 76E96D1Bh no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0[05] 76E877CCh no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0 72F0BDC0h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72F0BDC4h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72F0BDBCh Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0[06] 76E8690Bh no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0 74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0[07] 76E7CC60h no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
[08] 72EA0B48h Line ?=27 no proc Src="Library State" Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
74148C28h Line=819 Proc=CALLBACKWINDOWSRC@F Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0 72EE1E3Ah Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EC36E8h Line ?=27 no proc Src="Library State" Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845[09] 74148F1Eh Line=857 Proc=CALLBACKWINDOWSRC@F Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[10] 72E83FC3h no line number no proc Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EFCFC4h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EDDE6Eh Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845[11] 72E83AA1h no line number no proc Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EDDE84h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EFCFC4h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EFD044h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EF1360h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EF1374h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EF1390h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EF1384h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EF13ACh Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EF13A0h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845[12] 77817E4Dh no debug info, Module=C:\windows\SYSTEM32\ntdll.dll 10.0.17763.6292 (WinBuild.160101.0800)
[13] 77817E1Dh no debug info, Module=C:\windows\SYSTEM32\ntdll.dll 10.0.17763.6292 (WinBuild.160101.0800)
Kind regards,
Jorge Lavera
3
Web Server - Ask For Help / Re: NetWebServiceMethod
« Last post by seanh on May 04, 2026, 10:49:56 PM »If you're only getting XML maybe the client request is the problem?
See:
https://www.capesoft.com/docs/NetTalk14/NetTalkWebServices.htm#ReturnFormatRules
See:
https://www.capesoft.com/docs/NetTalk14/NetTalkWebServices.htm#ReturnFormatRules
4
Web Server - Ask For Help / Re: NetWebServiceMethod
« Last post by rupertvz on May 04, 2026, 08:22:05 AM »Thanks Jane, that makes sense regarding using the client.
At the moment I'm testing directly in the browser just to validate the behaviour of the template.
I'm using the TestFileParameter method from Example 77 with:
Return Type = View
View Table = Customer
However, even with data in the Customer table, the response is empty:
<TestFileParameter_response></TestFileParameter_response>
So I'm trying to confirm:
Should this example return Customer records without additional parameters?
Does the VIEW require specific parameters or filters to trigger data retrieval?
Also, even when I add _json_=1 to the URL, the response remains XML ? so I'm trying to understand whether that's expected when using a browser, or if something in my configuration is missing.
I'll test with a client as suggested, but I'd like to first confirm the expected behaviour of the example itself.
At the moment I'm testing directly in the browser just to validate the behaviour of the template.
I'm using the TestFileParameter method from Example 77 with:
Return Type = View
View Table = Customer
However, even with data in the Customer table, the response is empty:
<TestFileParameter_response></TestFileParameter_response>
So I'm trying to confirm:
Should this example return Customer records without additional parameters?
Does the VIEW require specific parameters or filters to trigger data retrieval?
Also, even when I add _json_=1 to the URL, the response remains XML ? so I'm trying to understand whether that's expected when using a browser, or if something in my configuration is missing.
I'll test with a client as suggested, but I'd like to first confirm the expected behaviour of the example itself.
5
Web Server - Ask For Help / Re: NetWebServiceMethod
« Last post by rupertvz on May 04, 2026, 08:20:40 AM »Thanks for the suggestion Sean,
I did try to force JSON via ContentType, but I ran into compile issues ? it seems like setting ContentType directly (e.g. net.ContentType or p_web.ContentType) is not available in a NetWebServiceMethod.
From what I understand, NetTalk should handle the response format via template settings or request negotiation.
I also tested:
http://127.0.0.1:88/TestFileParameter?_json_=1
But the response still comes back as XML.
Is setting ContentType manually actually supported in this context, or should JSON output be controlled purely via the template and request?
I did try to force JSON via ContentType, but I ran into compile issues ? it seems like setting ContentType directly (e.g. net.ContentType or p_web.ContentType) is not available in a NetWebServiceMethod.
From what I understand, NetTalk should handle the response format via template settings or request negotiation.
I also tested:
http://127.0.0.1:88/TestFileParameter?_json_=1
But the response still comes back as XML.
Is setting ContentType manually actually supported in this context, or should JSON output be controlled purely via the template and request?
6
Web Server - Ask For Help / Re: NetWebServiceMethod
« Last post by Jane on April 30, 2026, 09:17:53 PM »Are you trying to send JSON to a web browser or to a client of some sort?
There's a NetTalk example WebServiceRequiresXFiles (77) that includes two apps - a client and a web server.
It's also often useful to use the netdemo example program as a web client to debug what you're doing.
There's a NetTalk example WebServiceRequiresXFiles (77) that includes two apps - a client and a web server.
It's also often useful to use the netdemo example program as a web client to debug what you're doing.
7
Web Server - Ask For Help / Re: NetWebServiceMethod
« Last post by seanh on April 30, 2026, 06:24:55 PM »have you set the content type?
net.ContentType = 'application/json'
net.ContentType = 'application/json'
8
Web Server - Ask For Help / NetWebServiceMethod
« Last post by rupertvz on April 30, 2026, 01:09:47 PM »Hi Guys,
I'm working with NetTalk WebServer and using a NetWebServiceMethod procedure.
I can successfully call the endpoint and the procedure executes, but I'm struggling to get a JSON response to return in the browser. Currently, the request runs, but the response is blank when JSON is selected.
I have:
A queue defined for return (Q)
JSON enabled in the template
ServiceMethod populating the queue
However, it seems like the JSON branch in BuildResult / BuildResultFields is not being generated or executed.
My questions:
Is there a recommended example app or webinar showing a working NetWebServiceMethod returning JSON?
Should JSON responses for queues be handled purely via template, or is manual handling (e.g. AddJSONFromQueue) expected?
Is there a standard pattern for returning simple JSON (without queues)?
Any guidance or working example would be appreciated.
I'm working with NetTalk WebServer and using a NetWebServiceMethod procedure.
I can successfully call the endpoint and the procedure executes, but I'm struggling to get a JSON response to return in the browser. Currently, the request runs, but the response is blank when JSON is selected.
I have:
A queue defined for return (Q)
JSON enabled in the template
ServiceMethod populating the queue
However, it seems like the JSON branch in BuildResult / BuildResultFields is not being generated or executed.
My questions:
Is there a recommended example app or webinar showing a working NetWebServiceMethod returning JSON?
Should JSON responses for queues be handled purely via template, or is manual handling (e.g. AddJSONFromQueue) expected?
Is there a standard pattern for returning simple JSON (without queues)?
Any guidance or working example would be appreciated.
9
Web Server - Ask For Help / Re: API hangs on memo field
« Last post by Bruce on April 28, 2026, 08:48:54 PM »sounds like a bug in Reflection. I'll take a look.
10
Web Server - Ask For Help / API hangs on memo field
« Last post by jlavera on April 28, 2026, 06:31:51 AM »I have a rest server API. Recently upgraded to NT 14.37, and all the latest versions of ST, Reflection, jFiles, etc.
There is a complex topspeed file with lot of fields and some memo fields. The API receive just a few of them, ignoring the rest.
There is generated code that does this:
DocParm:App_Rosters.SetAttribute('table',DocParm:App_Rosters.TableFieldToColumn(App_Rosters,'AppRosters:CancelDescription'),'readonly') DocParm:App_Rosters.SetAttribute('table',DocParm:App_Rosters.TableFieldToColumn(App_Rosters,'AppRosters:CancelDescription'),'private')
And it hangs on either one.
I debugged until I found that in Reflection.clw, there is a
ReflectClass.TableFieldToColumn Procedure(FILE pTable,String pLabel)
where this call does a loop in the "record"... but it is not counting or processing the memo fields. It looks for the field name in the structure, but it is not there, as a memo, it is not part of the structure. The result is it never ends the loop and the server hangs.
Anyone sees this? Is this a bug, or I'm missing a setting (which I cannot find)?
Kind regards,
Jorge Lavera
There is a complex topspeed file with lot of fields and some memo fields. The API receive just a few of them, ignoring the rest.
There is generated code that does this:
DocParm:App_Rosters.SetAttribute('table',DocParm:App_Rosters.TableFieldToColumn(App_Rosters,'AppRosters:CancelDescription'),'readonly') DocParm:App_Rosters.SetAttribute('table',DocParm:App_Rosters.TableFieldToColumn(App_Rosters,'AppRosters:CancelDescription'),'private')
And it hangs on either one.
I debugged until I found that in Reflection.clw, there is a
ReflectClass.TableFieldToColumn Procedure(FILE pTable,String pLabel)
where this call does a loop in the "record"... but it is not counting or processing the memo fields. It looks for the field name in the structure, but it is not there, as a memo, it is not part of the structure. The result is it never ends the loop and the server hangs.
Anyone sees this? Is this a bug, or I'm missing a setting (which I cannot find)?
Kind regards,
Jorge Lavera