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

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<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 652064 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 3/17/2011 12:25:24 PM
Access Restriction Public


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.
Sign in to post a comment.
Posted by Ambrish [MSFT] on 5/4/2011 at 4:00 AM

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:



Posted by Ambrish [MSFT] 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.



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    
    [Frames below may be incorrect and/or missing, no symbols loaded for System.Data.SqlServerCe.ni.dll]    
    mscorwks.dll!@JIT_MonExitWorker@4() + 0xb bytes    
    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    
    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 Ambrish [MSFT] 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.