WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

ODBC
plus

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

qConnect Crashes with Exit Code -1073741571


Question:

I have a Winbatch Server App, which listens on a TCP Port. When a request comes in it does an ODBC Query, formats the data it fetches and sends it back through the listen port.

Problem is, the app runs fine for several hours and then crashes for some reason I cannot understand because it does not open an Winbatch Error Dialog nor does it crash so that a windows fatal exception window would occur. It simply terminates quietly with exit code -1073741571. This I know because meanhile I wrote a wrapper program which starts the compiled Server App and logs the return code. Also the amount of hours it runs is not a constant value. For example the first time it ran over 9 hours and terminated, the second time it ran about 8 hours and then exited.

Does anyone have a solution to this problem or an explanation what this exit code means? I would be really grateful, cause this app should run permanently and not terminate itself after some hours.

Thanx for any help. I'm really very clueless on this issue because I don't know there to start looking for the problem.

Answer:

Step 1: Add
DebugTrace(@ON,"C:\bigdebug.txt")
at the top of the program AND as the first line of every #definefunction and #defineSubroutine.

If you get worried about file size, you can add something like

debugcounter=0 
;to the top of the script then

;and then this is some main loop
debugcounter=debugCounter+1
if debugcounter >= 1000
FileDelete("C:\bigdebug.txt")
debugcounter=0
endif
AFTER the crash occurs you can examine the debug trace log...and the next line that would have been added to the log is probably the line it crashed on.

Once we know what that line is...then we can start theorizing about the error.

User Reply:

Well, I had a crash now and the line of code where it crashes (which would be the next line not in the log file) was the following line in a subroutine named ODBC_Connect:
retcode = qConnect(hdbc, Datasource, "", "")
which establishes a connection to the database before making a query. Well, may there be a Memory Leak or something in the hdbc extender when one makes hundreds of connects and disconnects during some hours?

Here's the complete subroutine which is called before every query. Of course there's also a disconnect subroutine, which I can post as well if you like:

DefineSubroutine ODBC_Connect(datasource)
DebugTrace(@on,gvRead("logfile"))
henv = qAllocEnv()

If henv == -1
retcode = qLastCode()
xMessageAndMail("Fehler %retcode%","could not allocate SQL Environment Variable", GetIcon("@mbstop"))
CleanUp()
Endif

hdbc = qAllocConnect(henv) 

If hdbc == -1
retcode = qLastCode()
xMessageAndMail("Fehler %retcode%","could not allocate SQL Connection Handle", GetIcon("@mbstop"))
CleanUp()
Endif

qSetConnOpt(hdbc, 103, 5, 0) ; SQL_LOGIN_TIMEOUT
qSetConnOpt(hdbc, 101, 1, 0) ; SQL_READ_ONLY

tries = 3
cnt = 0
while @True
retcode = qConnect(hdbc, Datasource, "", "")
If (cnt > tries) Then Break
If (retcode == @qSuccess) || (retcode == @qSuccessInfo) 
Break
EndIf
cnt=cnt+1
TimeDelay(1)
EndWhile

If (retcode != @qSuccess) && (retcode != @qSuccessInfo)
err=ODBC_Error_Ext(hdbc,1)
xMessageAndMail(StrCat("Fehler",err),"Could not connect to Datasource%@CRLF%Please check that a User DSN with Name '%datasource%' exists", GetIcon("@mbstop"))
CleanUp()
Endif

hstmt = qAllocStmt(hdbc)

If hstmt == -1
retcode = qLastCode()
xMessageAndMail("Fehler %retcode%","could not allocate SQL Statement Handle", GetIcon("@mbstop"))
CleanUp()
Endif

return hstmt ; Statement Handle
#EndSubroutine

Answer:

How many times does qConnect execute before it crashes? Are you using the latest version of the ODBC Extender (Ver 10013)? If the qConnect loop is executing more than once what is the faling SQL return code that causes it to execute again...

User Reply:

I don't knowhow many times qconnect executes because I delete the log if my main program loop reaches 1000 because of the size of the log file.

I always keep my extenders up to date with vcheck.

The failing qConnect SQL return code is "[S1000 Simba Driver][Simba File System Base]", which is according to the creator nothing to worry about, you just have to reconnect. And It really happens very, very, rarely. Maybe 1 of 100 connects or so.

But I don't think it has something to do with the connect retries because meanwhile my app crashed 3 times, always at the mentioned connect statement and it was always the first try which killed the app (cnt=0). I will now create a separate log with an odbc connect counter and get back to you when I have the first results.

Answer:

I recommend checking the eventlog for any interesting info. Also make sure you have the latest version of the Simba ODBC driver.

User Reply:

Ok, I had 6 crashes (meanwhile I wrote a restart script, but this cannot be a permanent solution), and my connection counter logs show that the all crashes occured after 177 successful connects exactly, so the 178th connection attempt crashes the app it seems.

As I already have the latest Simba Driver and the eventlog also shows nothing unusual and because restarting the app gives you another 177 attempts I really think the problem must lie in the odbc_extender. Remember: I connect/disconnect to the driver for every query which is executed because else it may happen that the odbc_connection times out until the next request, so the driver does not know if the app already connected 100, 1000, 10000 times, cause every time the connection is recreated. I think if the problem would lie in the simba driver I would have to reboot the machine and restarting the app would not help.

Answer:

Can you eliminate code from your program to make a much shorter test case that we can run? Maybe something that just connects and disconnects to a text database repeatedly, so we can reproduce the problem.

User reply:

Too bad, you we're right. I stripped down the code and when only the connect/disconnect routines were left I changed the ODBC_Driver to a text file and voila it worked like a charm. I could make 2000 connects without the app exiting. Interesting thing was with the stripped down program the 4D Open driver (internal name "simba") could connect 178 times (instead of 177).

So I went looking for another driver using google for a newer/fixed driver and I found a newer release (from another vendor, not the one I got my driver). Now with this release I can do 356 connects and with this driver the app doesn't exit silently, it crashes winbatch.exe (or if compiled the compiled exe) and when you look at the details you see that the 4D Open odbc driver dll caused the crash.

Problem Is I'm forced to use this driver because there is no alternative and I don't think you can fix it somehow within the odbc extender. But my question is: Is there a way to unload/reload the odbc dll or such a thing or maybe relaunch the program itself after 300 connects or something like that? Any ideas would be helpful... Thanx for your assistance.

Answer:

No way to unload the ODBC Extender from the script. It only gets unloaded when the script exits. Looks like you are going to need to relaunch the program itself after 'so many' connects to work around the issue with the driver.
Article ID:   W16838
File Created: 2017:07:28:13:58:33
Last Updated: 2007:07:03:14:26:29