大家好，关于还记得工业控制电池检测系统的.NET 卡住分析吗很多朋友都还不太明白，不过没关系，因为今天小编就来为大家分享关于的知识点，相信应该可以解决大家的一些困惑和问题，如果碰巧可以解决您的问题，还望关注下本站哦，希望对各位有所帮助！

0:000:x86 !clrstackOS 线程ID:0x4a08 (0)子SP IP 呼叫站点012fe784 0000002b [HelperMethodFrame_1OBJ: 012fe784] System.Threading.WaitHandle.WaitOneNative(System.Runtime.InteropServices.SafeHan dle ，UInt32，布尔值，布尔值）012fe868 7115d952 System.Threading.WaitHandle。 InternalWaitOne (System.Runtime.InteropServices.SafeHandle, Int64, 布尔值，布尔值) [f:\dd\ndp\clr\src\BCL\system\threading\waithandle.cs @ 243]012fe880 7115d919 System.Threading.WaitHandle.WaitOne(Int32 ，布尔） [f:\dd\ndp\clr\src\BCL\system\threading\waithandle.cs @ 194]012fe894 711e89bf System.Threading.WaitHandle.WaitOne(Int32) [f:\dd\ndp\clr\src\BCL \system\threading\waithandle.cs @ 220]012fe89c 6fb186b8 System.Threading.ReaderWriterLockSlim.WaitOnEvent(System.Threading.EventWaitHandle, UInt32 ByRef, TimeoutTracker, EnterLockType)012fe8e0 6fb17892 System.Threading.ReaderWriterLockSlim.TryEn terReadLockCore(TimeoutTrack呃）012fe920 6fb17562 系统.Threading .ReaderWriterLockSlim.TryEnterReadLock(TimeoutTracker)012fe94c 0325f49f xxx.QuyitpjK0dXKR6IyqH(System.Object)012fe964 0325ee8a xxx.RWAutoLock.ctor(System.Threading.ReaderWriterLockSlim, Boolean). 从六角形中的线程堆栈数据来看，看来是卡在读写锁TryEnterReadLock上，根据读写锁的规则，肯定有人执行了WriteLock，无法退出。下一步是找到持有该锁的线程。

2. 到底谁在持有

如果是lock的话，相信很多朋友都知道使用!syncblk命令。那么读写锁用什么命令呢？说实话，我想不通。我只能深入研究ReaderWriterLockSlim 类本身，看看是否有任何新内容。

0:000:x86 !DumpObj /d 03526f38Name: System.Threading.ReaderWriterLockSlimMethodTable: 6f947428EEClass: 6f9a92dcSize: 72(0x48) bytesFile: C:\Windows\Microsoft.Net\Assembly\GA C_MSIL\System.Core\v4.0_4.0.0.0__b77a5c561934e089\System.Core.dllFields: MT 字段偏移类型VT Attr 值Name70da878c 40004aa 38 System.Boolean 1 实例0 _fIsReentrant6f92fa28 40004ab 3c .LockSlim+SpinLock 1 实例03526f74 _spinLock70dfba4c 40004ac 1c System.UInt32 1 实例20 _numWriteWait 70dfba4c 40004ad 20 System.UInt32 1 实例1 _numReadWaiters70dfba4c 40004ae 24 System.UInt32 1 个实例0 _numWriteUpgradeWaiters70dfba4c 40004af 28 System.UInt32 1 个实例0 _numUpgradeWaiters6f93d764 40004b0 39 System.Byte 1 个实例0 _waiterStates70da42a8 40004b1 2c System.Int32 1 个实例-1 _upgradeLockOwnerId 70da42a8 40004b2 30 System.Int32 1 实例11 _writeLockOwnerId70da6924 40004b3 c .g.EventWaitHandle 0 个实例034844d0 _writeEvent70da6924 40004b4 10 .g.EventWaitHandle 0 个实例042a69c8 _readEvent70da6924 40004b5 14 .g.EventWaitHandle 0 个实例00000000 _upgradeEvent70da6924 40004b6 18 .g .EventWaitHandle 0 实例00000000 _waitUpgradeEvent70da150c 40004b8 4 System.Int64 1 实例367 _lockID70da878c 40004ba 3a System .Boolean 1 实例0 _fUpgradeThreadHoldingRead70dfba4c 40004bc 34 System.UInt32 1 实例3221225472 _owners70da878c 40004c2 3b System.Boolean 1 实例0 _fDispose70da42a8 40004a9 4dc System.Int32 1 静态4 ProcessorCount70da150c 40004b7 4d4 System.Int64 1 静态1882 s_nextLockID6f942b7c 40004b9 0 .ReaderWriterCount 0 TLstatic t_rwc 结合源码分析，发现上面的_writeLockOwnerId=11就是持有锁的线程ID。很容易找到固定线。将这个managementid=11转换为dbgid，再次观察。

0:000:x86 !t 13 11 47bc 0a0702c0 1029220 抢占式00000000:00000000 01425ed0 0 MTA (线程池工作线程) 0:013:x86 !clrstackOS 线程ID3 33 600x47bc (13)子SP IP 呼叫站点07e4f1ac 0000002b [InlinedCallFrame: 07e4f1ac] 07e4f1a4 09e38597 DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr)07e4f1ac 09e38334 [InlinedCallFrame33 360 07e4f1ac] System.Data.SQLite.UnsafeNativeMethods.sqlite3_step(IntPtr)07e4f1dc 09e38334 System.Data.SQLite.SQLite3.Step(System.Data.SQLite.SQLiteStatement)07e4f228 09e36fe8 System.Data.SQLite.SQLiteDataReader.NextResult()07e4f250 09e36ce系统.Data .SQLite.SQLiteDataReader .ctor(System.Data.SQLite.SQLiteCommand, System.Data.CommandBehavior)07e4f270 09e367ce System.Data.SQLite.SQLiteCommand.ExecuteReader(System.Data.CommandBehavior)07e4f284 09e36732 System.Data.SQLite。 SQLite 命令。 ExecuteNonQuery(System.Data.CommandBehavior)07e4f2b0 09e366e6 System.Data.SQLite.SQLiteCommand.ExecuteNonQuery()07e4f2bc 09e350dc SqlSugar.AdoProvider.ExecuteCommand(System.String, SqlSugar.SugarParameter[])07e4f388 1 3189518 `1[[系统。 __Canon, mscorlib]].ExecuteCommand()07e4f420 0181ac4a xxx.OperateLog+d__8.MoveNext().0:013:x86 kCvRegToMachine(x86)0x14fX86MachineInfo:SetVal: 请求未知寄存器0 # ChildEBP Ret地址00 07e4ede0 76c9ad10 ntdll_76ed0000!NtFlushBuffersFile+0xc01 07e4ede0 6b27af8c 内核库!FlushFileBuffers+0x30WARNING: 堆栈展开信息不可用。以下框架可能有误。02 07e4edf0 6b270256 SQLite_Interop!SI768767362ea03a94+0xf73c03 07e4ee1c 6b267938 SQLite_Interop!SI768767362ea03a9 4+0x4a0604 07e4ee38 6b2599e1 SQL ite_Interop!SI83d1cf4976f57337+0x84c805 07e4ee80 6b25902b SQLite_Interop!SIa3401e98cbad673e+0x320106 07e4ee98 6b25258c SQLite _Interop!SIa3401e98cbad673e +0x284b0 7 07e4f168 6b255a05 SQLite_Interop！SI327cfc7a6b1fd1fb+0x633c08 07e4f19c 09e38597 SQLite_Interop!SI9c6d7cd7b7d38055+0x255 大概知道写锁是用来写sqlite的，后者卡在缓冲区刷新函数NtFlushBuffersFile上，方法签名如下：

NTSTATUS NtFlushBuffersFile(HANDLE FileHandle, IO_STATUS_BLOCK *IoStatusBlock);有的朋友可能想看看怎么写，那么简单反编译一下代码：

至此，我们基本搞清楚了，因为13号线程持有写锁，导致主线程想要使用读锁操作sqlite时，等待了很长时间。

解决方案相对简单。主线程应该尽可能只做UI更新操作。不要让它触发各种锁，否则有等待锁的可能。

3. NtFlushBuffersFile 怎么了

有的朋友可能会问为什么NtFlushBuffersFile函数会卡住不返回。要找到这个答案，您需要查看反汇编。

0:013:x86 uf ntdll_76ed0000！NtFlushBuffersFilentdll_76ed0000！NtFlushBuffersFile:76f41ad0 b84b000000 mov eax，4Bh76f41ad5 ba7071f576 mov edx，偏移ntdll_7 6ed000 0！Wow64SystemServiceCall（76f57170）76f41ada ffd2调用edx76f41adc c20800 ret 80:013:x86 u 76F57170hntdll_76ed0000！Wow64SystemServiceCall:76f57170 ff252892ff 76 jmp双字指针[ntdll_76ed0000!Wow64Transition (76ff9228)]0:013:x86 u 76ec7000wow64cpu！ KiFastSystemCall:76ec7000 ea0970ec763300 jmp 0033:76EC700976ec7007 0000 添加字节ptr [eax],al76ec7009 41 inc ecx76ec700a ffa7f8000000 jmp dword ptr [edi+0F8h] 从查看汇编代码中，NtFlushBuffersFile通过KiFastSystemCall进入内核态。用户态转储无法看到内核态，因此也无法进一步追查此案。

但是，您也可以查看该线程过去的GetLastError() 值。使用!gle 命令您可能会有所收获。

0:013:x86 !gleLastErrorValue: (Win32)0x26 (38) – 无法获取错误代码textLastStatusValue: (NTSTATUS)0xc0000008 – 无法获取错误代码文本根据上述状态代码，搜索msdn 了解具体信息。

从错误描述来看，可能是sqlite文件有问题。句柄无效，读取已结束。怀疑是操作sqlite时文件损坏。

现在回过头来看，如果你想对Sqlite进行并发读写，你应该可以开启Write-Ahead Logging模式。程序中不需要控制读写。