Question

I'm try to find the cause of a nasty AccessViolation. This access violation occurs always with the same stack trace.

(c18.b2c): Access violation - code c0000005 (!!! second chance !!!) *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll - clr!StrongNameSignatureVerification+0x797c: 000007fef70eaa4c 48894110 mov qword ptr [rcx+10h],rax ds:0000000000000010=????????????????

The access violation is thrown somewhere inside "AwareLock::OwnedByCurrentThread" After loading the correct symbols i got this stack trace:

clr!ObjHeader::Wait+0x24, calling clr!AwareLock::OwnedByCurrentThread clr!ObjectNative::WaitTimeout+0xc7, calling clr!ObjHeader::Wait System.Threading.Monitor.Wait(System.Object, System.TimeSpan)), calling 000007fef70ea670 (stub for System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object)) 0000000034cae6a8 000007fef70ea6eb clr!ObjectNative::WaitTimeout+0x7b, calling clr!LazyMachStateCaptureState 0000000034cae6f0 000007fef5712f7f (MethodDesc 000007fef4b28d08 +0x4f System.Threading.Monitor.Wait(System.Object, System.TimeSpan)), calling 000007fef70ea670 (stub for System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object)) 0000000034cae740 000007fe986debe1 (MethodDesc 000007fe98789088 +0xc1 PeripheralHardwareAccess.PeripheralHardwareAccessBase.WaitForAck(PeripheralHardwareAccess.AsciiControlProtocolMessage, System.TimeSpan)), calling (MethodDesc 000007fef4b28d08 +0 System.Threading.Monitor.Wait(System.Object, System.TimeSpan))

Because we use native code it might be possible that the object header of the lock object is corrupted. I have already enabled the heap check with "gflags.exe" mentioned here without success.

And I've run the "!VerifyHeap" command of SOS without any detected errors. If it is always the same object that is invalid. Is there a way to do a check during runtime? Do you have other ideas what exactly is corrupt and how i can detect the cause of this exception? Or what commands / data might help to investigate this bug.

Thanks

Manuel

Was it helpful?

Solution 2

Thanks KCT for your answer. You're right a similar issue can be fixed with this hot-fix. (+1) for your answer. But we've already installed the latest version of the framework which has this hot-fix already included. In my case it was indeed a bug in some native code that caused this problem.

OTHER TIPS

I'm not sure if it is the same problem. I only remember it was a 000005 Access Vialotion Exception. But as no one answered it till now the following might help. We had a similar issue in AutoCAD that uses .NET 4.0. After installing .NET 4.5 we've got the Access Violation Exception after some time. But when it happed once the it always appeared. To uninstall 4.5 and installing 4.0 solved it. The reason behind was a bug in the Managed C++ v16 compiler that was triggered in AutoCAD code.

https://connect.microsoft.com/VisualStudio/feedback/details/801715/clr-runtime-error-kb2640103

http://knowledge.autodesk.com/support/autocad/downloads/caas/downloads/content/autodesk-autocad-2014-block-insertion-hotfix.html?v=2014

Hope this helps

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top