none
SQLDump.mdmp Erreur sqllang!CSsXmlNsResolver::GetCurrentElement RRS feed

  • Question

  • Hi,

    We have an error generating SQLDump.mdmp. A WinDbg stack shows sqllang!CSsXmlNsResolver::GetCurrentElement.

    We're using XML path functions such as xml.exist or xml.value, and the error seems to occur when running those xml functions.

    Have you seen this error ?

    Thks

    Thursday, October 6, 2016 10:53 AM

All replies

  • Hi Tcor,

    Could you please be more specific about the issue? Also, what do you see in SQL Server log? In addition, please also provide your SQL Server/Windows version and patch level so we can have a better understanding about the issue. 

    If you have any other questions, please let me know.

    Regards,
    Lin
    Saturday, October 8, 2016 4:51 AM
    Moderator
  • Hi, 
    We have the same issues with SQL 2016 SP2 CU8 Enterprise, Windows Server 2016.

    It is generating dumps every week.

    It seems this bug is not fixed in any of the CUs released.

    Tuesday, December 10, 2019 7:35 AM
  • Hi MLG,

    What is the cause of this memory dump? Are you getting a memory violation? non yield scheduler? Also can you please paste the information on your sql server error log?

    regards!

    Tuesday, December 10, 2019 12:35 PM
  • SqlDumpExceptionHandler: Process 1444 generated fatal exception c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process.                                                                                      
    * *******************************************************************************                         
    *                                                                                                                
    * BEGIN STACK DUMP:                                                                                              
    *   12/07/19 15:23:22 spid 1444                                                                                  
    *                                                                                                                
    *                                                                                                                
    *   Exception Address = 00007FFD906F9EBA Module(sqllang+0000000001139EBA)                                        
    *   Exception Code    = c0000005 EXCEPTION_ACCESS_VIOLATION                                                      
    *   Access Violation occurred reading address 0000000000000050                     


    More Details:

    spid1444    Stack Signature for the dump is 0x00000001715395C5
    spid1444    DumpCallbackHk::CreateCabFile: at 2060 g_CabDdfFile file is null, normally because nocollectors added any files, exiting
    spid1444    DumpCallbackHk::CollectFiles: at 481 failed at CreateCabFile with error: 0x80004005

    When I analyze the minidump with winDbg I got this (partial):

    FAILURE_SYMBOL_NAME:  sqllang.dll!CSsXmlNsResolver::GetCurrentElement

    00 ntdll!NtWaitForSingleObject
    01 KERNELBASE!WaitForSingleObjectEx
    02 sqlservr!CDmpDump::DumpInternal
    03 sqlservr!CDmpDump::Dump
    04 sqllang!SQLDumperLibraryInvoke
    05 sqllang!SQLLangDumperLibraryInvoke
    06 sqllang!CImageHelper::DoMiniDump
    07 sqllang!ContextDumpNoStackOverflow
    08 sqllang!ContextDump
    09 sqllang!stackTraceExceptionFilter
    0a sqldk!SOS_OS::ExecuteDumpExceptionHandlerRoutine
    0b sqldk!IsNXException
    0c sqldk!ex_trans_cexcept
    0d msvcr120!_CallSETranslator
    0e msvcr120!FindHandlerForForeignException
    0f msvcr120!FindHandler
    10 msvcr120!__InternalCxxFrameHandler
    11 msvcr120!__CxxFrameHandler
    12 ntdll!RtlpExecuteHandlerForException
    13 ntdll!RtlDispatchException
    14 ntdll!KiUserExceptionDispatch
    15 sqllang!CSsXmlNsResolver::GetCurrentElement
    16 sqllang!CSsXmlBinReader<0>::PeekItem
    17 sqllang!CSsXmlBinReader<0>::GetNextItem
    18 sqllang!CXmlConvert::MainConvertLoop
    19 sqllang!CXmlConvert::Convert
    1a sqllang!ConvertXMLForTDS72Plus
    1b sqllang!`anonymous namespace'::TSendRowClassNoCount<7,0>::TSendXML<0>
    1c sqllang!CTds74::SendRowImpl
    1d sqltses!CEsExec::GeneralEval
    1e sqllang!CXStmtQuery::ErsqExecuteQuery
    1f sqllang!CXStmtSelect::XretExecute
    20 sqllang!CMsqlExecContext::ExecuteStmts<1,1>
    21 sqllang!CMsqlExecContext::FExecute
    22 sqllang!CSQLSource::Execute
    23 sqllang!CStmtExecProc::XretLocalExec
    24 sqllang!CStmtExecProc::XretExecExecute
    25 sqllang!CXStmtExecProc::XretExecute
    26 sqllang!CMsqlExecContext::ExecuteStmts<1,1>
    27 sqllang!CMsqlExecContext::FExecute
    28 sqllang!CSQLSource::Execute
    29 sqllang!process_request
    2a sqllang!process_commands_internal
    2b sqllang!process_messages
    2c sqldk!SOS_Task::Param::Execute
    2d sqldk!SOS_Scheduler::RunTask
    2e sqldk!SOS_Scheduler::ProcessTasks
    2f sqldk!SchedulerManager::WorkerEntryPoint
    30 sqldk!SystemThread::RunWorker
    31 sqldk!SystemThreadDispatcher::ProcessWorker
    32 sqldk!SchedulerManager::ThreadEntryPoint
    33 kernel32!BaseThreadInitThunk
    34 ntdll!RtlUserThreadStart

    Server is physical

    Tuesday, December 10, 2019 1:02 PM
  • Hi MLG,

    Memory violations are always related to SQL Server Bugs. I checked CU 9 and CU 10 but i didn't find any fix related to memory violations. I'll reccomend to open a case in microsoft support because maybe you will require a custom patch or wait for a patch to be released.

    hope this helps.

    Tuesday, December 10, 2019 2:53 PM
  • Install the latest updates and retest. MS is horrible at publicly documenting changes.  Just because your problem is not listed in the public notes for a patch, does not mean it is not fixed.

    Tuesday, December 10, 2019 3:25 PM
    Moderator
  • There are three possible root causes for dumps like this:

    1) Bug in SQL Server
    2) Bad hardware, that is a bad memory stick.
    3) A faulty component running in the process space of SQL Server. That could be:
       a) A linked server (which is not SQL Server)
       b) An unsafe assembly.
       c) An extended stored procedure.
       d) Something invoked from sp_OAxxxxx.

    Comparing the stack dumps can give some clues. If they always look the same, it is very likely to be a bug in SQL Server. If there is an external component on top it is the last. If the dump is random, this indicates that is a bad memory stick - or a bad component that thrashes the SQL Server space.

    In your case you have sqllang.dll!CSsXmlNsResolver::GetCurrentElement listed as the fauly module. If you see that this always happens with XML processing, it is a bug in SQL Server.

    The best way to get a resolution is to open a support case.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    Tuesday, December 10, 2019 10:24 PM
  • Thank you for your answer.

    Actually we receive two kind of dumps and inside it is mentioned the procedure which causes the issue (Input Buffer) and it is always a procedure which is dealing with XMLs.

    The dump I showed you above is one type we receive. The other type of dump we have is also related to procedure dealing with XMLs but it is different type of issue: 

    *   Exception Address = 00007FFD94116A70 Module(sqlTsEs+0000000000046A70)
    *   Exception Code    = c0000094 EXCEPTION_INT_DIVIDE_BY_ZERO  

    Details:

    FAILURE_SYMBOL_NAME:  sqltses.dll!CDatetime2::FillParts

    Stack Text:

    sqltses!CDatetime2::FillParts+0x40
    sqltses!CDatetimeOffset::FillParts+0x143
    sqltses!CXVariantConvertVarTimeToWStr<43>::Convert+0x159
    sqltses!CXVariant::PerformConvertToWstr+0x74c
    sqllang!CSsXmlWriterText::AddValueTyped+0x7f4
    sqllang!CSsXmlWriter::AddValue+0xa8
    sqllang!CXmlConvert::MainConvertLoop+0x4c6
    sqllang!CXmlConvert::Convert+0xced
    sqllang!ConvertXMLForTDS72Plus+0x110
    sqllang!`anonymous namespace'::TSendRowClassNoCount<7,0>::TSendXML<0>+0x135
    sqllang!CTds74::SendRowImpl+0x1a6b
    sqltses!CEsExec::GeneralEval+0x1e9
    sqllang!CXStmtQuery::ErsqExecuteQuery+0x5f0
    sqllang!CXStmtSelect::XretExecute+0x322
    sqllang!CMsqlExecContext::ExecuteStmts<1,1>+0x40d
    sqllang!CMsqlExecContext::FExecute+0xa9e
    sqllang!CSQLSource::Execute+0x983
    sqllang!CStmtExecProc::XretLocalExec+0x2d2
    sqllang!CStmtExecProc::XretExecExecute+0x481
    sqllang!CXStmtExecProc::XretExecute+0x38
    sqllang!CMsqlExecContext::ExecuteStmts<1,1>+0x40d
    sqllang!CMsqlExecContext::FExecute+0xa9e
    sqllang!CSQLSource::Execute+0x983
    sqllang!process_request+0xea6
    sqllang!process_commands_internal+0x2df
    sqllang!process_messages+0x253
    sqldk!SOS_Task::Param::Execute+0x231
    sqldk!SOS_Scheduler::RunTask+0xaa
    sqldk!SOS_Scheduler::ProcessTasks+0x3cd
    sqldk!SchedulerManager::WorkerEntryPoint+0x2a1
    sqldk!SystemThread::RunWorker+0x8f
    sqldk!SystemThreadDispatcher::ProcessWorker+0x2de
    sqldk!SchedulerManager::ThreadEntryPoint+0x1d8
    kernel32!BaseThreadInitThunk+0x14
    ntdll!RtlUserThreadStart+0x21

    Basically this is the history of the dumps we have:

    08/23/19 spid 247 Exception 0xc0000094 EXCEPTION_INT_DIVIDE_BY_ZERO at 0x00007FFF9CBF6A00
    08/24/19 spid 1294 Exception 0xc0000094 EXCEPTION_INT_DIVIDE_BY_ZERO at 0x00007FFF9CBF6A00
    09/07/19 spid 2593 Exception 0xc0000094 EXCEPTION_INT_DIVIDE_BY_ZERO at 0x00007FFF9CC0E1E3
    09/24/19 spid 1452 Exception 0xc0000094 EXCEPTION_INT_DIVIDE_BY_ZERO at 0x00007FFF9CBF6A00
    10/30/19 spid 661 Exception 0xc0000005 EXCEPTION_ACCESS_VIOLATION reading address 0000000000000050 at 0x00007FFD906F9EBA
    11/24/19 spid 3505 Exception 0xc0000094 EXCEPTION_INT_DIVIDE_BY_ZERO at 0x00007FFD94116A70
    12/07/19 spid 1444 Exception 0xc0000005 EXCEPTION_ACCESS_VIOLATION reading address 0000000000000050 at 0x00007FFD906F9EBA

    Conclusion:

    We have these two kind of dumps which are somehow related to queries dealing with XMLs.

    Wednesday, December 11, 2019 8:08 AM
  • There is likely nothing in the dump which you can fix.  The dump file is for MS tech support to use to debug the problem.

    You need to install the latest CU and see if the problem is resolved.  If it is not, you will need to contact MS support, supply them the dump file, and get a fix from them.

    Wednesday, December 11, 2019 6:24 PM
    Moderator
  • I agree with Tom. This definitely smells like a bug in the product.

    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    Wednesday, December 11, 2019 10:34 PM
  • Yes, soon we will have ticket opened to MS and will let you know the results.

    Thank you.

    Thursday, December 12, 2019 9:27 AM