My c# service application raises the following error(Eventlog):Code Snippet
.NET Runtime version 2.0.50727.1433 - Fatal Execution Engine Error (000006427F8A5DC8) (80131506)
I tried google to find some information about the errorcode 6427F8A5DC8 but I found nothing.
The Server is a windows server 2003 x64 with installed framework 2.0, 3.0 and 3.5. The service runs without problems many weeks but since we upgraded to VS 2008 and change the target platform from framework 2.0 to 3.5 we run into trouble with our service application.
On another server 2003 x86 there are no problems with the framework 3.5.
The service starts successfully but after a couple of hours it stops and we get the error message above in the eventlog.
I hope somebody can help.
We still have the problem, but now we have Error Reporting enabled:
Here the message:
Faulting application myapp.exe, version 1.0.2949.21212, stamp 479db2a8, faulting module mscorwks.dll, version 2.0.50727.1433, stamp 471ed580, debug? 0, fault address 0x00000000001e4663.
Any help appreciated, thanks!
Here are some additional information from windbg:Code Snippet
00000642`7f51465c 498b08 mov rcx,qword ptr [r8]
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 000006427f51465c (mscorwks!CreateApplicationContext+0x000000000007511c)
ExceptionCode: c0000005 (Access violation)
Attempt to read from address 0000000012bcf838
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
APPLICATION_VERIFIER_FLAGS: 0Code Snippet
STACK_COMMAND: dds 3d7db40 ; kb
our code does not execute sql-commands. We read a lot of data from files and put it into objects in a multithreaded environment. We have run our application as a sevice or as a windows form. In booth scenarios the applicationen stops and in the eventlog we have the error from above.
I am having the same error, on XP 64bit. I am also running framework 3.5, but am only using basic IO operations (constantly overwriting a little file). Takes about 24 hours of continuous running to crash it. I'm trying to create a little test application to recreate these conditions. Seems to me from the above comments that it's an error only experienced by 64bit .NET 3.5 users...
The 'Fatal Execution Engine Error' (80131506) is pretty general and can be caused by many things. It is impossible to say more about it without detailed information. If you are able to create a simplified repro (which repros in minutes rather than a day), then there's a chance we can find out what's wrong.
If you have a simplified repro, I would recommend to search through already reported bugs on MS Connect (https://connect.microsoft.com) and/or file a new bug there.
Another important information is if the bug is reproducible on more than one machine and if it is affected by other software installed on the machine. Having that information would help too.
- Proposed as answer by Karel ZikmundMicrosoft employee, Moderator Saturday, May 31, 2008 7:32 PM
I am also getting this error - [ .NET Runtime version 2.0.50727.1433 - Fatal Execution Engine Error (000006427F8A5DC8) (80131506) ] I get this error when attempting to install SQL 2005 Standard on a failover cluster using two identical machines running Server 2003 x64 R2 SP2. I also have .Net 2.0 and .Net 3.5 on both machines.
The error is followed by a message [ Faulting application setup.exe, version 2005.90..1399.0, stamp 43500fa1, faulting module mscorwks.dll, version 2.0.507.27.1433, stamp 471ed580, debug? 0, fault address 0x000000000018ce45 ]
The SQL install errors out after the support files are installed during the phase that the SQL setup checks for system configuration. The window itself just disapears about 3 seconds in, and gives no obvious error report that it has failed. Only in the event viewer does it show this problem.
Any help would be much appreciated. I have followed and refollowed all of the steps that microsoft suggests for configuring the cluster.
I have been checking up on this thread all year. My team has had the same problem (.NET Runtime version 2.0.50727.1433 - Fatal Execution Engine Error (000006427F8A5DC8) (80131506)) for over two years now. We also see unexplainable corruption errors like AccessViolations on the .X of a point object or other exceptions that seem "impossible" considering the use of managed code. It became our conclusion that the Fatal Execution errors were signs of corruption in places like kernel memory. The problem was not occurring frequently enough to be a huge issue until recently.
We have spent the last 2.5 months trying to debug the source of this problem. We meticulously broke our own code down until it was doing practically nothing, audited every scrap of unmanaged code and hired outside debugging experts (who confirmed what we had been able to narrow down, but ended up just as baffled as we were) to help us resolve this problem.
We have been able to narrow the problem down to a third party image acquisition hardware component (they are now just as baffled as we are). Our combined testing is showing that when this hardware component is DMA-ing, we see these unexplainable corruption errors or Fatal Execution errors within 30 minutes of running our code. In separate testing we also see that running on a PC with two, single-core Intel processors or one, dual-core AMD processor our code does not error, but when running on two, dual-core Intel or AMD processors our code errors.
I am wondering if there is any knowledge out there that might help us relate the results of our two paths of testing.
We are running Windows 64-bit with .NET 2.0, 3.0 and 3.5 installed. The problem has spanned development work in VS 2005 and VS 2008. About two years ago it was drastically reduced with some hot-fixes, but I was not working with it at the time and those developers are no longer with the company.
I will keep checking this thread and hopefully be able to post some information soon about the source of this problem. If others are anywhere near as stressed and frustrated as I have been by this problem I'll pass along whatever information we manage to come across!
Nice sleuthing. But yeah, that's what brings the CLR to its knees. A driver that doesn't quite get its DMA right, perhaps not quite dealing with cache coherency issues just right. Or worse, the hardware getting it wrong, there are plenty of hardware bugs out there. Squirt some random bytes in the wrong place at the wrong time and it is FEEE time. *Very* hard to debug. Good luck.
An update from our end:
One of the strange things we have noticed when looking at our crash dumps of these crashes the code trying to read from address 0x0000000813131313 (causing an AccessViolation) during a GC plan phase or something similar. Our board supplier uses a constant 0x13131313 in their code and we were assuming this number was somehowbeing pulled from that constant. In our most recent round of debugging, they changed it to something different and are still seeing a read on address 0x0000000813131313.
Our code does not use that number anywhere, it is not possible for any of our data sets to use that number so consistently, etc. The debug experts said they were able to find this byte pattern in a variety of places on memory dumps taken at every GC: managed heap, unused areas of a user mode thread's stack and once in paged pool kernel memory. At the time we figured the kernel memory can't be affected by our app and turned our attentions to this third party driver which has that byte sequence and access to that memory. They also indicated the byte pattern is also present in some Microsoft stuff, but I can't find the email that went into detail about it. We chose to focus on the third party driver as a more likely cause of the crashes.
At any rate, this byte pattern is rather predictable in showing up. Has anyone else see anything like it? Is there a better board to post something like this to? Any advice on how to figure out where this number is coming from? I'm starting to think it's the key to figuring out how our memory is being corrupted and our application crashing.
Unfortunately, I am also getting this error -
.NET Runtime version 2.0.50727.1433 - Fatal Execution Engine Error (79FFEE24) (80131506)
Faulting application <myapp>, version 188.8.131.52, stamp 48da7f75, faulting module mscorwks.dll, version 2.0.50727.1433, stamp 471ef729, debug? 0, fault address 0x000f6756.
I've been searching the net to find a solution for this, and the closest clue I've found about it was this post.
My application uses a C++ library to connect to a message queue system, and I believe that all of our problems have something to do with the managed code calling the unmanaged code inappropriately, or the garbage collector getting lost somewhere.
I can only reproduce this error by running the application for almost 3 hours.
I'm running the application on 2 different machines (Windows 2003 server and xp sp3), both with .NET 3.5.
The strangest thing is that we also capture all unhandled exceptions through managed code, but the application is unexpectedly finished.
It would be nice to get some explanation about this, even if it was something like "we don't know why this happens, but we are trying to figure it out".....
C++ is quite capable of bring the CLR down to its knees all by itself. Just overflow a buffer you got from managed code and its FEEE time. Also next to impossible to debug, it usually crashes long after the damage was done.
More of an update:
The third party in our debugging efforts has come up with interesting information. Our code is setup to run independently of theirs (we don't rely on them to supply us with any data) and their code is running on it's own. They set up threads to search their buffers ahead of and behind the locations where they DMA into.
What they've found is this 64-bit number (see my previous post) will show up in a buffer as soon as they start to DMA. The thread monitors that location and changes it to something different (all FFFFF's) and the next time it checks that location it's changed back to the 64-bit number. Only that location is bad. When the number shows up in their buffers, our code does not crash. If the number doesn't show up in one of their buffers, eventually our code will crash trying to read that number as an address.
They copied the test setup off our AMD pc and put it on an Intel pc and saw the same crashes (15-30 minute runs seem to reproduce the error) until they installed a Windows update. I don't have the details yet on the specific update other than it was specifically related to a microcode update for Intel machines. They went 36 hours (~50 runs) with no crashes. To verify, they uninstalled the update and saw crashes, but reinstalled and saw it crash again. It's a heartbreaker! They are verifying they have the same setup when they went 36 hours with no crashes and doing further testing. Whatever that update had in it seems to have had some impact.
Our problem seems to be unrelated to yours, perhaps ... but stay focused! Persistant work will eventually lead to results. We are several months into debugging this, don't let the frustration drag you down!
We have the same problem. Our application was working fine but after updating to .net framework 3.5 we get Service Unavailable message time to time. Event log shows (.NET Runtime version 2.0.50727.1433 - Fatal Execution Engine Error (000006427F8A5DC8) (80131506)) error.
I have looked everywhere to find a solution but no luck so far. We are using Windows Server 2003 x64.
We finally solved our problem a few weeks ago. There was a bug in our 3rd party driver leftover from when they converted it from 32-bit to 64-bit for us. It would DMA 32 bits of a number into an address it was not supposed to if the address it was supposed to go to was located above 4GB. If that address happened to be in the memory used by our program during execution we would see the Fatal Execution errors or an impossible exception (usually an AccessViolation where it could not happen without some kind of corruption). We were continuously hitting 6.5 GB to 7.0 GB of memory use so this happened frequently.
Our supplier fixed this problem and provided us with a new driver and we have not seen the problem in over a month. Our individual solution is probably of zero use to anyone else. This was the result of months of methodical and tedious debugging within my own group and working with our supplier.
Best of luck!
I get this a lot while working with the winscard.dll, perhaps it is the driver of the readers that I'm working with, I don't know.
In addition to forcing x86 over 64/Any CPU, I can only get around that (avoid that behavior completely) by running the application in debug mode.
I am getting this same error when I try to Preview a Report in SSRS 2008 R2 working on Windows XP. The thing is it appears to only happen when I have created a report with Parameters in. I suspect that SSRS is trying to maybe do something with IE to handle the Parameters and failing so crashes me out of BIDS. I suppose it may also be trying to do something with IIS and maybe missing some vital chunk of DLL or something?!
I fail to understand why an application like Visual Studio 2008 R2 supposedly using .NET 3.5 SP1 is trying to use .NET 2, but maybe someone with a little more knowledge could advise.
I know we are using old OS technology here, but since it all installs I would have thought it should ALL work.
I was not sure whether to post this on SSRS Forum or here.
Maybe someone will advise ...
Hopefully sheds more light on this issue.
Would be great to solve this one - first week in a new job and all.......
OK since not had any response in a few days, I have re posted this into Reporting Services Thread, and had a response about needing a very old hotfix for .Net 2, however I am not sure how that hangs
with Windows XP, and the fact that all my patches are up to the minute, which I would have thought should have had the hotfix already embedded.......
I may be missing something though.....
The hotfix suggests it cannot find a User Policy reference or something, but so far not fully worked out how to make sure it can find one. Have tried adding a Group Policy Snap in into the mmc, but that still does not shed any more light.......
Does that ring any bells with anyone?
- Edited by ezeget Friday, March 30, 2012 9:47 AM