Home Dashboard Directory Help
Search

Internal error in the .NET Runtime (exit code 80131506) by Mistertom


Status: 

Closed
 as External Help for as External


9
0
Sign in
to vote
Type: Bug
ID: 696561
Opened: 10/25/2011 1:14:56 AM
Access Restriction: Public
Moderator Decision: Sent to Engineering Team for consideration
0
Workaround(s)
view
3
User(s) can reproduce this bug

Description

The program, a .NET Framework 4 application running as a Windows service, crashes with the following errors in the event log:

> Framework Version: v4.0.30319
> Description: The process was terminated due to an internal error
> in the .NET Runtime at IP 79236AC7 (79140000) with exit code 80131506.

> Faulting application abc.servicebus.host.exe, version 1.0.0.0, stamp 4e9f9133,
> faulting module clr.dll, version 4.0.30319.237, stamp 4dd234a8, debug? 0,
> fault address 0x000f6ac7.

This error does not occur after startup but after what seems to be a random period of time, varying from a few hours to a few weeks.
This error occured on different hardware configurations, both virtual and physical machines and both x86 and x64 processors.
This error occured both on .NET Framework version 4.0.30319.1 and version 4.0.30319.237.

There is no memory issue with the program. The program does not use umanaged libraries.

A memory dump of the crashing application was captured.
Details
Sign in to post a comment.
Posted by Ima Dirty Troll on 3/24/2012 at 1:44 PM
I got this exit code as well, which crashed a long-running service.

The crash happened at *exactly* 5 seconds after the start of the minute. At just this point in time, the service starts a few hundred parallel operations, some as tasks and some as threads. Each of these performs a network operation that takes several seconds to complete (checking whether services on remote machines are running, reading files located on remote machines, and querying some databases). This is all managed code, and every code path being executed at this time is inside a try/catch block.

This crashing application was written in .NET 3.5 and upgraded to .NET 4.0. Some of the older code still uses threads and newer code uses TPL tasks.

I don't have a crash dump but I can provide more info about the crashing application if needed. (specific API calls etc.) The problem is intermittent and it has reproduced a few times, but I have not been able to find consistent repro steps.


- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name=".NET Runtime" />
<EventID Qualifiers="0">1023</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2012-03-24T16:19:05.000Z" />
<EventRecordID>24703</EventRecordID>
<Channel>Application</Channel>
<Computer>Titan</Computer>
<Security />
</System>
- <EventData>
<Data>Application: WatchdogService.exe Framework Version: v4.0.30319 Description: The process was terminated due to an internal error in the .NET Runtime at IP 000007FEF3FCE2A2 (000007FEF3E40000) with exit code 80131506.</Data>
</EventData>
</Event>


- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2012-03-24T16:19:05.000Z" />
<EventRecordID>24704</EventRecordID>
<Channel>Application</Channel>
<Computer>Titan</Computer>
<Security />
</System>
- <EventData>
<Data>WatchdogService.exe</Data>
<Data>1.0.0.0</Data>
<Data>4f10c6c7</Data>
<Data>clr.dll</Data>
<Data>4.0.30319.239</Data>
<Data>4e1822f4</Data>
<Data>c0000005</Data>
<Data>000000000018e2a2</Data>
</EventData>
</Event>
Posted by Microsoft on 10/27/2011 at 12:45 PM
The issue you are seeing here is caused by managed heap corruption. This can be due to a wide variety of issues, such as an incorrect PInvoke signature, native code in your program corrupting the managed heap, or in rare cases a bug in CLR itself. For some background information, there are several places on the internet with information about debugging this type of issue: http://blogs.msdn.com/b/tess/archive/2006/02/09/net-crash-managed-heap-corruption-calling-unmanaged-code.aspx

If you still suspect its a bug in CLR, you will have to go through our standard support channels at http://support.microsoft.com or by caling 800-936-5800. We unfortunately cannot diagnose this issue via connect due to the time involved in tracking issues down like this.
Posted by MS-Moderator07 [Feedback Moderator] on 10/26/2011 at 2:06 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Posted by Mistertom on 10/25/2011 at 5:03 AM
I tried to upload the dump file with the file attachement option and with the specific workspace URL but I cannot see any trace of it being successfully uploaded.
Posted by MS-Moderator07 on 10/25/2011 at 1:57 AM
Thank you for submitting feedback on Visual Studio 2010 and .NET Framework. In order to efficiently investigate and reproduce this issue, we are requesting additional information outlined below.
    
It may help if you provide us with a dump file and call stack.

You can get detailed steps about how to get the dump file and call stack at http://blogs.msdn.com/debugger/archive/2009/12/30/what-is-a-dump-and-how-do-i-create-one.aspx

Or you can download a Visual Studio 2010 Diagnostic Tool from http://visualstudiogallery.msdn.microsoft.com/en-us/e8649e35-26b1-4e73-b427-c2886a0705f4. You can get detailed description about how to use it to collect dump file.

************************************************************
Please zip the file and use "FeedbackID-696561" as prefix of the file name.

************************************************************
You can use the following workspace to upload the file:
https://sftus.one.microsoft.com/choosetransfer.aspx?key=8e6f8ea0-3c43-4b43-8ffc-3d081a2ceda1
Password is xLBDIjK)abN

Please submit this information to us within 4 business days. Thanks again for your efforts and we look forward to hearing from you.

Microsoft Visual Studio Connect Support Team
Posted by MS-Moderator01 on 10/25/2011 at 1:47 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
File Name Submitted By Submitted On File Size  
MINIDUMP_FirstChance_av_AccessViolation_Abc.ServiceBus.Host.exe__08bc_2011-10-17_19-04-17-803_0c70.dmp (restricted) 10/25/2011 -
ADPlus_report.txt (restricted) 10/25/2011 -
ADPlus_log_08bc_2011-10-17_10-24-56-905.log (restricted) 10/25/2011 -