SQL crash running assembly - by Keivan Kechmiri

Status : 

  External<br /><br />
		This item may be valid but belongs to an external system out of the direct control of this product team.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 360941 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 8/7/2008 6:13:13 AM
Access Restriction Public


The following crash of SQL accoure everytime a specific CLR dll are run. The CLR dll are a third party application part.

Log Name:      Application
Source:        Application Error
Date:          2008-08-07 14:38:44
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      ksd-sr-08.k1.se
Faulting application sqlservr.exe, version 2007.100.1442.32, time stamp 0x484082b2, faulting module ntdll.dll, version 6.0.6001.18000, time stamp 0x4791adec, exception code 0xc0000374, fault offset 0x00000000000a6e97, process id 0x498, application start time 0x01c8f88947a11432.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <TimeCreated SystemTime="2008-08-07T12:38:44.000Z" />
    <Security />
Sign in to post a comment.
Posted by Microsoft on 10/28/2008 at 10:13 AM
The issue seems to be caused by the third party assembly hosted in an UNSAFE mode and without a repro we run out of investigation options. Therefore we decided to close it.

Thank you for working with us on the investigation.
-Krzysztof Kozielczyk
Posted by Microsoft on 8/14/2008 at 5:11 PM

Our developers analyzed the minidump you provided (thank you one more time!). There is a native memory corruption that we suspect was caused by the third party assembly you're hosting. Unfortunately this is typical for assemblies calling into native code.

We could investigate more if you provided us with a repro. Could you please create a database including all objects that are necessary for a repro, compress it and attach? That would allow us to verify our theory.

You could also contact the support of the assembly's provider and verify if they're aware of this problem - maybe they're already working on this or even have a solution.

Krzysztof Kozielczyk
Posted by Microsoft on 8/13/2008 at 10:51 AM
Hi Keivan,

Thank you again for reporting the issue and for providing us with the minidump file. We will investigate the issue and let you know as soon as we make any progress.

Krzysztof Kozielczyk
Posted by Keivan Kechmiri on 8/10/2008 at 10:59 PM

I've attached a part of the Windows Error Reporting log (not the memorydump it's to big). I haven't found any other error log.

I've also upgraded to RTM but it's exactly the same problem.

The assembly is a third party which is part of a music scheduling software called Goal Selector from RCS Works (www.rcsworks.com).

The assembly is some sort of copy protection to their system,

The assembly runs fine on SQL 2005 (32-bit).

I think there are 2 parts of this assembly a managed code part and a unmanaged part that are called by the registered assembly.

It's fairly easy to reproduce the problem, but you need a database, a install sql script and a couple of small assemblys. Then you need to run a specific sql procedure that will call the assembly.

I hope that you can find something that will point to a solution...

Posted by Microsoft on 8/8/2008 at 10:57 AM

Thank you for reporting this issue!

To be able to investigate it we would like to ask you to send us the dump file that should be created in SQL Server's LOG folder. Could you please compress it and attach it to your response?

Could you also tell me more about your scenario? I noticed you're registering the assembly as UNSAFE. Is the assembly developed specifically to be used in SQL Server or are you just trying to register some assembly you're using in standalone application? Did you try using this assembly with SQL Server 2005 before? Please note that UNSAFE assemblies have severe potential for breaking SQL Server process, especially if they're calling into native code, etc.

Krzysztof Kozielczyk