Home Dashboard Directory Help
Search

SQLCE 3.5 SP2 NullReferenceException from System.Data.SqlServerCe.Accessor.Dispose by RMD


Status: 

Closed
 as Fixed Help for as Fixed


1
0
Sign in
to vote
Type: Bug
ID: 652064
Opened: 3/17/2011 12:25:24 PM
Access Restriction: Public
0
Workaround(s)
view
1
User(s) can reproduce this bug

Description

I'm often getting a NullReferenceException being thrown by SQL Server CE 3.5 SP2 when the finalizer is called by garbage collection. Below is the stack trace:

System.Data.SqlServerCe.dll!System.Data.SqlServerCe.Accessor.Dispose() + 0x5e bytes System.Data.SqlServerCe.dll!System.Data.SqlServerCe.Accessor.Finalize() + 0x13 bytes

So far, I've only seen this issue on a single machine, which happens to be 64bit. Not sure if that's contributing. I'm using the 32bit SQLCE library.
Details
Sign in to post a comment.
Posted by Microsoft on 5/4/2011 at 4:00 AM
Hello,

As per our discussions and further investigations the issue has been fixed in the SQL Server Compact 3.5 SP2 Cumulative Update 2. The CU2 is available for download at the location below:

http://support.microsoft.com/kb/2289547

Regards,

Ambrish
Posted by Microsoft on 4/1/2011 at 4:27 AM
The bug has been fixed in SQL Server Compact 4.0 that is available for download at http://www.microsoft.com/downloads/en/details.aspx?FamilyID=033cfb76-5382-44fb-bc7e-b3c8174832e2. If the fix needs to be ported to SQL Server Compact 3.5 SP2 then please log a bug with the Microsoft Support team. The process for logging a bug with Microsoft Support is at https://support.microsoft.com/oas/default.aspx?Gprid=14917&st=1&wfxredirect=1&sd=gn. The fix for SQL Server Compact will be released as a QFE. If you face any problems in logging the issues the issue with the Support team then please reply back to this thread.

Regards,

Ambrish

Posted by RMD on 3/31/2011 at 12:59 PM
More details.

It appears as though this is a timing issue related to multiple threads accessing SQL CE on a fast machine. The faster the machine, the more likely it is to crash.

My dev workstation typically has a crash once every few hours. It's a 2.5 year old Core i7 940. The other dev workstation we see this on is a brand new Core i7 2600. Both of these have two physical cores (4 logical due to hyperthreading), but the newer machine encounters the crash almost immediatly on start.

If I hard-code a limit of 1 thread for the software in question, the crash doesn't appear to happen.

If this is a timing issue where on a fast, multi-core machine running multiple threads there is some chance for heap corruption, it would make sense that limiting it to 1 thread would essentially eliminate the issue.

We are working on a demo app that will allow you to reproduce the issue on sufficently fast hardware.
Posted by RMD on 3/31/2011 at 12:25 PM
I have now confirmed that this happens on another machine. This other machine is also a Windows 7 x64 box with multiple cores. (Dual core w/hyper threading, just like my box.)

I have *not* been able to reproduce this issue on a Hyper-V VM with 4 cores assigned. Perhaps this means it has more to do with the memory on the box that the CPU cores? The boxes where this issue happens have 8GB and 16GB of ram, respectively.

Interestingly, the crash happens almost immediatly on the machine with 16GB of ram, where it takes as much as several hours to happen on the box with 8GB of ram.

I can provide a minidump if that helps.
Posted by RMD on 3/29/2011 at 6:12 AM
I'll try to create a demo app for this issue. In the mean time, I've been able to capture a minidump of my application crashing due to either this error, or a related error.

The exception is:

Unhandled exception at 0x7763e653 (ntdll.dll) in MyApp.exe.4980.dmp: 0xC0000374: A heap has been corrupted.

Here is the stack trace:

>    ntdll.dll!_RtlReportCriticalFailure@8() + 0x57 bytes    
    ntdll.dll!_RtlpReportHeapFailure@4() + 0x21 bytes    
    ntdll.dll!_RtlpLogHeapFailure@24() + 0xa1 bytes    
    ntdll.dll!_RtlFreeHeap@12() + 0x50010 bytes    
    AcXtrnal.dll!NS_FaultTolerantHeap::APIHook_RtlFreeHeap() + 0x61 bytes    
    ole32.dll!CRetailMalloc_Free() + 0x1c bytes    
    ole32.dll!_CoTaskMemFree@4() + 0x13 bytes    
    04a1476a()    
    System.Data.SqlServerCe.ni.dll!55fc0d3c()     
    [Frames below may be incorrect and/or missing, no symbols loaded for System.Data.SqlServerCe.ni.dll]    
    System.Data.SqlServerCe.ni.dll!55fca645()     
    System.Data.SqlServerCe.ni.dll!55fca57b()     
    System.Data.SqlServerCe.ni.dll!55fd492e()     
    System.Data.SqlServerCe.ni.dll!55fc7158()     
    System.Data.SqlServerCe.ni.dll!55fc719f()     
    System.Data.Entity.ni.dll!703971a2()     
    System.Data.Entity.ni.dll!70395e3c()     
    System.Data.Entity.ni.dll!70331b8e()     
    System.Core.ni.dll!70910e71()     
    mscorwks.dll!@JIT_MonExitWorker@4() + 0xb bytes    
    mscorlib.ni.dll!71536e76()     
    mscorlib.ni.dll!715557b1()     
    mscorwks.dll!_CallDescrWorker@20() + 0x33 bytes    
    mscorwks.dll!_CallDescrWorkerWithHandler@24() + 0x9f bytes    
    mscorwks.dll!MethodDesc::CallDescr() + 0x15a bytes    
    mscorwks.dll!MethodDesc::CallTargetWorker() + 0x1f bytes    
    mscorwks.dll!MethodDescCallSite::CallWithValueTypes_RetArgSlot() + 0x1a bytes    
    mscorwks.dll!ExecuteCodeWithGuaranteedCleanupHelper() + 0x9f bytes    
    mscorwks.dll!ReflectionInvocation::ExecuteCodeWithGuaranteedCleanup() + 0xfe bytes    
    mscorlib.ni.dll!715556a7()     
    mscorlib.ni.dll!715402d5()     
    mscorlib.ni.dll!71536df4()     
    mscorwks.dll!_CallDescrWorker@20() + 0x33 bytes    
    mscorwks.dll!_CallDescrWorkerWithHandler@24() + 0x9f bytes    
    mscorwks.dll!MethodDesc::CallDescr() + 0x15a bytes    
    mscorwks.dll!MethodDesc::CallTargetWorker() + 0x1f bytes    
    mscorwks.dll!MethodDescCallSite::CallWithValueTypes_RetArgSlot() + 0x1a bytes    
    mscorwks.dll!ThreadNative::KickOffThread_Worker() + 0x11a bytes    
    mscorwks.dll!Thread::DoADCallBack() - 0x15bf bytes    
    mscorwks.dll!Thread::ShouldChangeAbortToUnload() - 0x737 bytes    
    mscorwks.dll!Thread::ShouldChangeAbortToUnload() - 0x811 bytes    
    mscorwks.dll!Thread::ShouldChangeAbortToUnload() - 0x685 bytes    
    mscorwks.dll!ManagedThreadBase::KickOff() + 0x13 bytes    
    mscorwks.dll!ThreadNative::KickOffThread() + 0xd6 bytes    
    mscorwks.dll!Thread::intermediateThreadProc() + 0x46 bytes    
    kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes    
    ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes    
    ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes    

As you can see, my code isn't even present in the stack.
Posted by Microsoft on 3/22/2011 at 2:05 AM
Thanks for logging the issue. If possible can you please attach a repro application. This will help to speed up the investigations.

Regards,

Ambrish
Sign in to post a workaround.