We Keep Coding

Fatal error. Internal CLR error. (0x80131506) on String.Format() [duplicate]

The exception code C0000005 is thrown from mscorwks.dll when the application is run on Windows Server 2008 R2 launched using test complete. Other platforms (Windows XP, Server 2003 R2, Windows 7 32-bit and 64-bit) do not present this exception.
The event log from a single execution has many of the following event with event ID 1023 raised by the .NET Runtime:
.NET Runtime version 2.0.50727.4952 - Fatal Execution Engine Error (7383851A) (80131506)
The application itself makes use of a SOAP interface generated by Visual Studio from a WSDL file, a COM object with an embedded interop, and is targeting .NET 4.
sfc /scannow was run and found no problems with system files on the affected system.
What troubleshooting can be done to identify a solution?

Fatal Engine Execution Error and an access violation are both symptoms of the same problem. FEEE is raised when the .NET garbage collector detects that the internal structure of the garbage collected heap is destroyed. An access violation is a hardware exception, raised by the processor when it is asked to access memory with an invalid address. A common cause of an AV is heap corruption.
These kind of mishaps are very commonly caused by unmanaged code. It is also quite common for unmanaged code to have latent memory management bugs that can go unnoticed for a long time. The kind of damage the bug can do tends to be quite random. Just running it on another operating system which has a different memory allocation pattern can be enough to trigger the bomb.
You have an excellent candidate for the source of the trouble. You'll need to work with the COM server vendor or author to chase the bug.

A 0xC0000005 is an exception code wrapping a Win32 error which means "Access Denied." Given that you are using COM interop and are getting an ExecutionEngineException (in COM, COR_E_EXECUTIONENGINE; 0x80131506), my guess is that either it's a NULL pointer in the COM component or a faulty ComImport directive in your .NET code.

This error is caused by flaws in the way that TestComplete 7 interacts with the heap in mixed managed/unmanaged applications. Instead of using the TestedApp.Run method using the following block of code, modified for you choice of scripting language, presented in VBScript:
Dim oScript, command
Set oScript = CreateObject("WScript.Shell")
command = "%comspec% /c " & PATH_TO_EXE & " " & Args
oScript.Run command, 10, True
The relevant MSDN article is Run Method (Windows Script Host).

TestComplete 7 (including the latest update 7.52) supports .NET Framework 4 only up to version .NET 4 Beta 2. It does not support the release version of the Framework, so this may be the reason of the problem.
Try building the application targeting .NET 2.0. This should resolve the problem.
To test .NET 4 applications, you will need to use TestComplete 8.

.NET/C# DB2 for iSeries 'FatalExecutionEngineError' from IBM.Data.DB2.iSeries

Having trouble connecting from a C#/.NET program to a Development (non-live) iSeries
Getting the following failure when trying to open a new connection:-
"Exception of type 'System.ExecutionEngineException' was thrown."
HResult -2146233082
Managed Debugging Assistant 'FatalExecutionEngineError' has detected a problem in 'C:\Users\sclose\Documents\Visual Studio 2015\Projects\iSeries1\iSeries1\bin\Debug\iSeries1.vshost.exe'.
Additional information: The runtime has encountered a fatal error. The address of the error was at 0x71ccec3c, on thread 0x28bc. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
Just a very simple noddy program which sets a connection string and opens a new connection:-
string ConnectionString = "DataSource=MACH03Y;UserID=sysmon;Password=xxxxxxxxx;LibraryList=U1SCLOSE;Naming=System";
_connection = new iDB2Connection(ConnectionString);
Have iAccess for Windows 7.1 installed and am able to connect and sign on to the iSeries through System i Navigator
Tried:-
1) Various combinations of UserId's and Library lists (valid and invalid)
2) Valid and Invalid DataSource values
3) Different IBM.Data.DB2.iSeries.dll versions including the latest
Always the same failure
We know the same code works successfully in a live environment but this is maybe first time it's been tried in a dev environment!
Normally in dev it uses a mock service and goes nowhere near a real iSeries
I have more experience on the iSeries side than the .NET side
Thinking it's maybe a Network/Firewall issue?
Any help gratefully received

Whenever I have seen this error, it has been a problem with the Visual Studio Debugger. I do not think it is a problem with your code or the IBM.Data.DB2.iSeries.dll.
Error code 5 is an access violation in Windows. These debugger crashes are usually fixed by upgrading Visual Studio or applying the latest service pack. VS2015 is screwy in lots of ways, since it was a ground up rewrite, and I had these errors a few years ago until they fixed them. Try a service pack first. If that doesn't help, try either version 2012 or 2017. There also conceivably could be a Windows update that broke this. It has happened before.
See also: "vshost32.exe has stopped working" OR "fatal execution engine error" in Visual Studio

Application-internal exception in Windows.UI.Xaml.dll

I'm working on a Windows 10 Store Windows Universal app using Visual Studio 2015 Community, c#, and XAML. It is decompressing a compressed file and displaying images found therein.
The build provides 0 warnings.
The debug version runs fine regardless of input file size.
The release version runs fine with typical input file sizes.
For large input file sizes (~100 1 megapixel images), the release build crashes consistently with 'Unhandled exception at 0x55E9A305 (Windows.UI.Xaml.dll) in appname.exe: 0xC000027B: An application-internal exception has occurred (parameters: 0x127DC468, 0x00000005).'
The crash occurs when the user tries to display the second image. All decompression is complete and all the bitmaps have been created by this time.
I've fiddled with the Build settings and narrowed down the difference to the option 'Compile with .NET Native Tool chain'. If that option is checked, the application crashes. If that option is unchecked, the application runs fine.
All told, the application is using about 400 MB of heap so although not small it isn't near the capacity of the machine.
"So uncheck the option!", I hear you cry. Unchecking the box leads to the certification failure shown below:
FAILED
Supported APIs
• Error Found: The supported APIs test detected the following errors:
-API OpenSemaphore in api-ms-win-core-synch-l1-1-0.dll is not supported for this application type. System.Threading.dll calls this API.
-API CreateSemaphore in api-ms-win-core-kernel32-legacy-l1-1-0.dll is not supported for this application type. System.Threading.dll calls this API.
-API ExecuteAssembly in uwphost.dll is not supported for this application type. StupidTest.exe calls this API.
-API DllGetActivationFactory in uwphost.dll is not supported for this application type. StupidTest.exe has an export that forwards to this API.
An empty project suffers the same failure if Compile .Net Native tool chain is not selected.
So my questions:
Must Universal Apps use Compile .Net Native tool chain?
Is there any documentation on the meanings of the parameters in the internal exception or somewhere else I can turn to troubleshoot?
In short, any advice on getting out the "It doesn't work if selected, but you must select it to get certified" dilemma I find myself in?

I struggled with this issue also for the past few days, and I've found the answer!
So if you haven't updated Visual Studio 2015 to Update 1, do it. Because this error is a bug in the compiler and after the update you will be able to build the project with the Compile .Net Native tool chain option selected.
And yes, those four errors that the WACK tool picks up, is because of compiling your project without checking the .Net Native tool chain option in the Build menu of the Package.appxmanifest file.

EntryPointNotFoundException in advapi32.dll while starting application

I developing WPF application in Visual Studio 2013 Update 5 on windows 7 x64 SP1. After starting program download xml-file over http and parse it. All worked fine until today, and problem is that exception begin occurring suddenly, no significant changes were made in project, no new references were added.
Now while starting program throws System.Windows.Markup.XamlParseException with message "The method or operation is not implemented" and it occurs even before InitializeComponent() so no one line of my code executed. Then I looked into IntelliTrace window in Visual Studio and found a chain of exceptions, top of them is System.EntryPointNotFoundException with message "Unable to find an entry point named 'EventSetInformation' in DLL 'advapi32.dll'".
Searching give me this and this talking that EventSetInformation is windows 8+ only. So windows 7 missing this method and here is exception, but how could my program reference this method while it (program) is not related to windows 8, not a bit?
I can also assume that there is some Update-5-related components inside Visual Studio that can trigger this advapi32 method, but if so - how can I disable this feature?
Edit
Program using .NET 4.5
Exception info:
System.Windows.Markup.XamlParseException occurred
Message=The method or operation is not implemented.
Source=PresentationFramework
StackTrace:
in System.Windows.Markup.WpfXamlLoader.Load(XamlReader xamlReader, IXamlObjectWriterFactory writerFactory, Boolean skipJournaledProperties, Object rootObject, XamlObjectWriterSettings settings, Uri baseUri)
Edit2
As Steve and Hans noticed in comments, actual problem finally wasn't related to advapi32 library. I had a WindowEx class derived from Window with some custom stuff, and my visual window was derived from this WindowEx. Maybe my custom class missed some method (if to believe exception message), but after switching base class back to Window and putting custom logic from WindowEx directly to visual window, error was gone.

For completeness of this question, here is answer with copy of question's last edit:
As Steve and Hans noticed in comments, actual problem finally wasn't related to advapi32 library. I had a WindowEx class derived from Window with some custom stuff, and my visual window was derived from this WindowEx. Maybe my custom class missed some method (if to believe exception message), but after switching base class back to Window and putting custom logic from WindowEx directly to visual window code-behind, error was gone.

Exception not catched

I've a 64bit system with Win7 and I use VS2010 with .Net Framework 4.0.
In a Winform application I get an Exception from a third-party component, I'm trying to catch this exception with a Try-Catch but it doesn't work!
Why?
UPDATE
If I un-check CLR Exceptions It works properly but I'm forced to check it due to this known problem: Why the form load can't catch exception?
If I press F10 it continues entering in catch statement!!

Seems that you are using calling an unmanaged dll here. Try catching this exception using ExternalException Class. This may work for you but once you've gone outside of the .NET runtime's control, it's entirely up to the unmanaged code; there's nothing the .NET runtime can do.

Have you got the following setting unchecked:
Break when exceptions cross AppDomain or managed/native boundaries (Managed only)
in your Tools->Options->Debugging->General tab for Visual Studio 2010
Its explained in MSDN here