申请/代码说明:
我的应用程序基于c#并使用SQL Server CE,并且在相同的代码位置只能获得此异常两次。直到此版本才引入此例外的崩溃。此版本中唯一的变化是将.net框架更改为4.5.2。
我在处理SqlCeConnection
时遇到访问冲突异常,但出现以下错误:
尝试读取或写入受保护的内存。这通常是一个 表明其他内存已损坏。
此异常不会被.net 的try catch子句截获 - 它会导致崩溃。
在我的代码中,我使用以下命令运行
try
{
var connectionString = string.Format("{0}{1}{2}", "Data Source=", _localDB, ";File Mode=Read Write;Max Database Size=4000;Persist Security Info=False;");
using (var sqlCeConnection = new SqlCeConnection(connectionString))
{
using (var sqlCeCommand = new SqlCeCommand())
{
sqlCeCommand.Connection = sqlCeConnection;
sqlCeCommand.CommandText = "SELECT * FROM Application";
sqlCeConnection.Open();
var result = (string)sqlCeCommand.ExecuteScalar();
isValid = !IsValid(result);
}
}
}
catch (Exception ex)
{
_log.Error("exception", ex);
}
第一次崩溃的调用堆栈:
ntdll!ZwWaitForMultipleObjects+a
KERNELBASE!WaitForMultipleObjectsEx+e8
kernel32!WaitForMultipleObjectsExImplementation+b3
kernel32!WerpReportFaultInternal+215
kernel32!WerpReportFault+77
kernel32!BasepReportFault+1f
kernel32!UnhandledExceptionFilter+1fc
ntdll! ?? ::FNODOBFM::`string'+2365
ntdll!_C_specific_handler+8c
ntdll!RtlpExecuteHandlerForException+d
ntdll!RtlDispatchException+45a
ntdll!KiUserExceptionDispatcher+2e
sqlcese35!__SafeRelease+c
sqlcese35!Column::`vector deleting destructor'+5c
sqlcese35!Object::DeleteObjects+39
sqlcese35!Table::`vector deleting destructor'+45
sqlcese35!Table::Release+27
sqlcese35!HashTable::~HashTable+2a
sqlcese35!Store::~Store+12b
sqlcese35!Store::Release+2a
sqlceme35!ME_SafeRelease+17
DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr ByRef)+78
[[InlinedCallFrame] (System.Data.SqlServerCe.NativeMethods.SafeRelease)] System.Data.SqlServerCe.NativeMethods.SafeRelease(IntPtrByRef)
System.Data.SqlServerCe.SqlCeConnection.ReleaseNativeInterfaces()+147
System.Data.SqlServerCe.SqlCeConnection.Dispose(Boolean)+f1
System_ni!System.ComponentModel.Component.Dispose()+18
第二次崩溃的调用堆栈:
ntdll!NtWaitForMultipleObjects+a
KERNELBASE!WaitForMultipleObjectsEx+e8
kernel32!WaitForMultipleObjectsExImplementation+b3
kernel32!WerpReportFaultInternal+215
kernel32!WerpReportFault+77
kernel32!BasepReportFault+1f
kernel32!UnhandledExceptionFilter+1fc
ntdll! ?? ::FNODOBFM::`string'+2335
ntdll!_C_specific_handler+8c
ntdll!RtlpExecuteHandlerForException+d
ntdll!RtlDispatchException+45a
ntdll!KiUserExceptionDispatcher+2e
<Unloaded_sqlcese35.dll>+7c88c
<Unloaded_sqlceqp35.dll>+102790
0x06ccc898
0x06f9efc8
0x1eca8018
0x1f207400
<Unloaded_sqlcese35.dll>+228dc
0x00000004
0x2edff008
0x00000002
0x00000003
0x00000004
<Unloaded_sqlcese35.dll>+3fbd9
0x06ccc898
DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr ByRef)+78
[[InlinedCallFrame] (System.Data.SqlServerCe.NativeMethods.SafeRelease)] System.Data.SqlServerCe.NativeMethods.SafeRelease(IntPtrByRef)
System.Data.SqlServerCe.SqlCeConnection.ReleaseNativeInterfaces()+147
System.Data.SqlServerCe.SqlCeConnection.Dispose(Boolean)+f1
System_ni!System.ComponentModel.Component.Dispose()+1b
我在互联网上发现了一些建议提供一些解决方案:
可能的解决方案:检查同一连接上的多线程问题(attempted to read write protected memory. this is often an indication that other memory is corrupt)
抑制:
一个。连接是在使用括号中创建的,不会被重复使用
湾调用方法每5分钟调用一次,并通过转储文件验证它没有被同时调用。
可能的解决方案: sql ce版本不匹配(http://blogs.msdn.com/b/sqlservercompact/archive/2009/05/06/troubleshooting-access-violation-exception-while-using-sql-server-compact-database-with-ado-net-provider.aspx)
可能被拒绝:我在安装的版本中看到的是3.5 SP2(3.5.8080.0),并且从转储中的模块我可以看到sqlceme35.dll
,{{1} } DLL的版本为3.05.8080.0
可能的解决方案有疑问如下: https://stackoverflow.com/a/20492181/1447518
可能被拒绝:从统计角度来看听起来不对 - 代码在同一个地方崩溃了两次,尽管应用程序代码中有另一个地方写入并读取到另一个数据库并且申请没有在那里崩溃。
我想到的最后一件事,可能会建议DLL的卸载问题(看看第二个调用堆栈)。我的猜测是dll是从应用程序中卸载的,而应用程序需要它们才能进行处理,但它接缝有点模糊和“远射”
我的问题是:可能导致问题的原因,以及可能的解决方案是什么?
答案 0 :(得分:1)
虽然此解决方案尚未验证,但解决方案如下:
从第二个调用堆栈中我可以看到卸载本机DLL,我的猜测是SQL连接的dispose方法正在使用它当前处理的方法之一。 我通过Process转储验证了所有SqlCeConnection类型都在处理过程中。
看到ErikEj的评论让我意识到如果我看一下SQL-CE 3.5到4.0之间的代码差异(System.Data.SqlServerCe.dll)会更好。
查看代码后,我可以看到释放的方法被移动到dispose方法中的稍后位置。
此外,我可以看到,在调用SafeRelease之前,还有另一项检查,检查安全发布所需的本机DLL是否已经发布 - 并抛出异常。
底线,SQL-CE 4.0有两个针对同一问题的解决方案。
我的猜测是这个问题是由于这个原因造成的。
现在的解决方案是在所有应用程序生命周期(没有连接字符串)期间保持连接,这会导致指针池将本机Dll保留在内存中以用于所有应用程序生命周期。
更好的解决方案是迁移到SQL-CE 4.0。