clr.dll crashes on Windows 10 RRS feed

  • Question

  • My application crashes with the following error:

    Faulting application name: xxxx.exe, version: 2014.0.0.0, time stamp: 0x591473cc
    Faulting module name: clr.dll, version: 4.6.1586.0, time stamp: 0x575a139f
    Exception code: 0xc0000005
    Fault offset: 0x0006f3a3
    Faulting process id: 0x15cc
    Faulting application start time: 0x01d2e3ea71f0ff70
    Faulting application path: xxxx.exe
    Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Report Id: 7065dbf7-1f71-40ed-b72d-eb96a9bbad26
    Faulting package full name:
    Faulting package-relative application ID:

    Application is running on Windows 10 with .Net framework 4.6.2

    Anybody knows how to resolve this?



    Wednesday, June 21, 2017 10:14 PM

All replies

  • It means the application you're running is asking for access that it shouldn't have (0xc0000005 is the code for "access violation")

    You may tell the software vendor to fix it.

    Thursday, June 22, 2017 1:57 AM
  • Hi EK2017,

    Thank you for posting here.

    The error 0xc0000005 is Access Violation error. When a program attempts to access memory which has been distributed to another process and is not available for this one, you'll receive the error and the software will be terminated.

    You could try the solutions in the following link.


    Best Regards,


    Note: This response contains a reference to a third party World Wide Web site. Microsoft is providing this information as a convenience to you. 

    Microsoft does not control these sites and has not tested any software or information found on these sites; Therefore, Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there.

    There are inherent dangers in the use of any software found on the Internet, and Microsoft cautions you to make sure that you completely understand the risk before retrieving any software from the Internet. 

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, June 22, 2017 5:55 AM
  • Wendy,

    Thanks for your reply. Are there any logs created by Windows that can give me more details on the issue?



    Thursday, June 22, 2017 3:38 PM
  • Hi,

    I had recently a similar problem. In my case it was caused by the new JIT. I could solve my problem by editing the app.config file. I just added the entry useLegacyJit.

        <useLegacyJit enabled="1" />  

    Maybe it works for you, too.

    Best regards


    Code Samples: Code Samples
    Chrigas Blog: Chrigas Blog

    Friday, June 23, 2017 10:35 PM
  • Humm... the new JIT does not affect 32-bit assemblies... (You can know that by observing the faulting module path is at Framework and not Framework64)
    Saturday, June 24, 2017 9:45 AM
  • From the crash dump file, I was able to get the call stack and disassembly:

    Call Stack:

    7656252a ffd2            call    edx
    7656252c c20400          ret     4
    7656252f 90              nop
    76562530 b80e100700      mov     eax,7100Eh
    76562535 ba606c5676      mov     edx,offset win32u!Wow64SystemServiceCall (76566c60)
    7656253a ffd2            call    edx
    7656253c c20800          ret     8
    7656253f 90              nop
    76562540 b80f100100      mov     eax,1100Fh
    76562545 ba606c5676      mov     edx,offset win32u!Wow64SystemServiceCall (76566c60)
    7656254a ffd2            call    edx
    7656254c c3              ret <----------- This is where it crashed
    7656254d 8d4900          lea     ecx,[ecx]
    76562550 b810100000      mov     eax,1010h
    76562555 ba606c5676      mov     edx,offset win32u!Wow64SystemServiceCall (76566c60)
    7656255a ffd2            call    edx
    7656255c c20800          ret     8
    7656255f 90              nop
    76562560 b811100000      mov     eax,1011h
    76562565 ba606c5676      mov     edx,offset win32u!Wow64SystemServiceCall (76566c60)
    7656256a ffd2            call    edx
    7656256c c20800          ret     8

    Tuesday, June 27, 2017 7:30 PM
  • CallDescrWorker is used to "enregisters the appropriate arguments and makes the actual call" when prepare calling external function.

    But without information on what are the addresses on stack, we'd be unable to guess where it starts to go wrong. (In case of Access Violation, the final place the instruction pointer points to is often where the train had already wrecked. In here, the first entry in stack could be holding other data rather than the return address therefore there is an exception, but I have no idea what a correct return address would be look like.)

    Wednesday, June 28, 2017 6:23 AM
  • I've installed Visual Studio on the target machine and was able to figure out where the program crashes. It is crashing in ExecuteReader() function of MySQL Connector/Net library. But still have no idea how to fix it. 
    Thursday, August 10, 2017 4:04 PM
  • Does Microsoft offer paid services to fix this kind of issues?
    Tuesday, August 15, 2017 4:00 PM
  • Yes. If you/your company has MSDN subscription, there is support incident quota available each year. If not, you can buy it. (Select the product and follow screen instructions, and then you'll reach a page that tell you to select the account the incident quota will be deducted on or to pay for it)

    But these won't help unless you have source code for the software.

    Wednesday, August 16, 2017 1:11 AM
  • Thanks a lot!

    Wednesday, August 16, 2017 9:40 PM