internal error - dbsrv11

[Former Member]

hi guys, just wondering if anyone encounters such problem before ?

Internam Error - dbsrv11 dbsrv11 has envountered a serious error and needs to close. We are sorry for the inconvenience.

From the crash log i found :

VERSION=11.0.1.2044
FILENAME=C:\\Documents and Settings\\All Users\\Application Data\\SQL Anywhere 11\\diagnostics\\SA11_20140721_103517_9508.crash_log
OS=Windows 2003 Build 3790 Service Pack 2
PROCESSOR=X86_64
EXEC_ARCH=X86
EXEC_PATH=C:\\Program Files\\SQL Anywhere 11\\Bin32\\dbsrv11.exe
MODULE_PATH=C:\\Program Files\\SQL Anywhere 11\\Bin32\\dbserv11.dll
EXCEPTION_PTR=0F07CB60
EXCEPTION_CODE=2147483651
EXCEPTION_FLAGS=0
EXCEPTION_RECORD=00000000
EXCEPTION_ADDRESS=77E4BEF7
EXCEPTION_NumParameters=1
EXCEPTION_Param0=0084036C
TRYING_TO_SAVE_MINI_DUMP C:\\Documents and Settings\\All Users\\Application Data\\SQL Anywhere 11\\diagnostics\\SA11_20140721_103517_9508.dmp
DUMPLEVEL 0
SAVING_MINI_DUMP_COMPLETED
CRASH_LOG_COMPLETE
ATTEMPTING_TO_SUBMIT_MINIDUMP...

From another err.xml, there are more encrypted messages here (so, i guess i will not post here in case if it is needed)

The platform of this OS :

product="SQL Anywhere" application_version_build="2044" system_properties="Windows 2003 Build 3790 Service Pack 2"

Anyone had such problem before ? Need to know if the root cause is from the OS platform or the software side itself :) thank you

[VolkerBarth]

Do you run dbsrv11 with the -o console.log option? If so, are there any warnings/errors in that log file?

Note: Version 11.0.1.2044 is the original maintenance release version of 11.0.1 and is therefore really old (as of early 2009?) - there have been several years of bugfixes in newer 11.0.1 EBFs, the last (build 11.0.1.3158) has been released last month, so you might consider to update to a newer EBF... (Yes, I'm aware that this does not explain the stopped service.)

[Former Member]

As to Volker's final observation: "(Yes, I'm aware that this does not explain the stopped service.)" ...

The crash_log file shown contains only meta-information about the crash captured. There is mostly just platform, version, bitness and dump file name information, with very few specific details in that file. If this issue is due to an identifiable bad state an "assertion error" or a "fatal error" should be logged as part of the Windows Application Event Log as well as in the server console logs (ie. the -o file Volker was asking about).

Failing any record of the issue in the Windows Event Logs or the server log, there will be more details in the minidump file itself but that requires that to be submitted and analyzed by an engineer.

Volker is also correct about the number of fixes provided since the 11.0.1 GA release and you should look into that more. If you do find you are unable to apply EBFs you could try setting max_query_tasks=1 to avoid a few parallelism bugs that have been fixed much more recently than the release you are running.

[Former Member]

hi guys, thanks for the feedback. So far from the event viewer, im not able to see anything / any crashes log by SQL so far. That's why we dont have much clue on this too. In the mean time, the version might be quite "old" but as my client is using the current version and has no intention to upgrade this, we are not able comment much too since we are just the vendor.

Thanks

[VolkerBarth]

What about the -o console.log file?

[Former Member]

hi volker, may i know where can i find this physical log file ? i see these files only : SA11_20140721_103517_9508.err.xml and SA11_20140716_104450_3080.crash_log

[former_SQLA_member1694878]

In your service parameters/start line, you may have specified a -o <path> and/or -oe <path> switch. The file would be located at one of these paths. Fatal assertions are logged here, which are usually a result of a corrupted database.

As others have mentioned, applying the EBF bug fix has a good chance of resolving the issue.

Do you know if the client was doing anything specific when the crash occurred (large report, testing new procedure)?

The .DMP file located in the same folder as the crash_log may have more information related to root cause, if you have a support contract I would recommend submitting this.

[Former Member]

Hi Mikel, From the services > start parameters, there is nothing here. The only options seen is the "Path to executable" with this line

C:\\ASA11\\Bin32\\dbsrv11.exe -hvSQLANYs_Program

Apart from the crash log (SA11_20140716_104450_3080.crash_log), yes i see there is dmp file too (SA11_20140716_104450_3080.dmp) but i dont think we have support contract tho. Who / any methods we can get this Dmp file to be decrypted ?

This server contains only the programs and not a sharing platform with other application. There was no updates / testing done in this platform as well.

Update : we have reinstall the sybase 11 (as the program was not initially installed by us previously) and then patch this SA11_Full_Win32+x64.1101_2808_EBF.exe. Reinstallation was done to another directory as the previous path < 1Gb of space It has been running 2 days now and so far no such crashes (fingers crossed) but still, need to find the actual root cause to our client 😞