KeyVaultClient throws FatalExecutionEngineError on debug randomly - c#

When I debug ASP.NET MVC application, KeyVaultClient throws randomly exception:
Managed Debugging Assistant 'FatalExecutionEngineError' : 'The runtime has encountered a fatal error. The address of the error was at 0x59eab403, on thread 0x6098. 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.'
I use:
nuget Microsoft.Azure.KeyVault 3.0.3
Visual Studio 2019 Professional 16.1.4
Microsoft.AspNet.WebApi 5.2.3
don't have Managed Compatibility Mode
I got familiar with this question and nothing helpful happens.
Edit
After enabling Managed Compatibility Mode I get slightly different error:
Managed Debugging Assistant 'FatalExecutionEngineError' has detected a problem in 'C:\Program Files (x86)\IIS Express\iisexpress.exe'.
Additional Information: The runtime has encountered a fatal error. The address of the error was at 0x6c0db403, on thread 0x54a8. 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.
occurred

From https://devblogs.microsoft.com/devops/switching-to-managed-compatibility-mode-in-visual-studio-2013/
New managed debug engine that provides us the ability to more rapidly add new features compared to the older implementation. This can be seen by the number of features introduced in Visual Studio 2013 after only a single year including Managed Return Values, .NET 64-bit Edit and Continue, Async Callstacks Enhancements, and Improved Tasks Window to name a few. Unfortunately, there are still a couple scenarios that are not supported yet with the new debug engine, so in these cases you will have to switch back to the legacy engine.
Error which you are getting is because of the issue which is not supported by new debug engine.
Please try below setting and see if you still get the same error.
To switch back to the legacy debug engine globally, select Tools/ Options
then check Use Managed Compatibility Mode on the Debugging / General tab.
The global option will force the legacy engine to be used for any launch or attach.
Hope it helps.

Related

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.

Autofac couldn't resolve dependency on TeamCity

I have a such code (It's a part of unit tests executed by nunit-console):
class MyClass
{
[DI(Type = typeof(MyClass))]
public IMyClass MyClassProperty {get;set;}
}
By reflection i'm scanning such classes and then register in Autofac:
// Register MyClass as IMyClass
autofacBuilder.RegisterType(diAttribute.Type).As(propertyInfo.PropertyType);
After that i need to resolve this property in the same way - by reflection:
autofacContainer.Resolve(propertyInfo.PropertyType) // it contains IMyClass
When I'm launching this code locally it works well.
But doesn't work on TeamCity. Fails with error:
Error: 'Autofac.Core.DependencyResolutionException: An exception was thrown while executing a resolve operation. See the InnerException for details. ---> Common Language Runtime detected an invalid program. (See inner exception for details.) ---> System.InvalidProgramException: Common Language Runtime detected an invalid program.
There are a lot of questions on StackOverflow about this exception. It's not an Autofac problem, it's a JIT compiler problem. A quick Google search on the exception yields a lot of info.
InvalidProgramException / Common Language Runtime detected an invalid program
Common Language Runtime detected an invalid program?
You even see projects like NewtonSoft.Json running into the issue.
The exception itself means "a program contains invalid Microsoft intermediate language (MSIL) or metadata; generally this indicates a bug in the compiler that generated the program."
Microsoft has a KB article on troubleshooting the issue. Whenever folks have resolved it, as far as I've seen, it's always one of two fixes:
A change to the compilation options. For example, some people running encryption/obfuscation sorts of tools find turning them off helps; others find turning off compiler optimization fixes it. (The KB article has some tips.)
Making sure things are patched to the latest versions. I've run into other similar situations myself where things work great on my machine but not on the build server; or vice versa. Almost invariably it's because I have my machine all patched up but the build server has been languishing unpatched; or someone just patched up the build server and I haven't installed my patches yet.
I'd recommend starting with the patches since that's usually the simplest fix. Use Windows Update to make sure both you and the build server have the latest .NET updates. If that doesn't fix it, check out some of the troubleshooting tips in the articles and questions above.

Getting FatalExecutionEngineError in c#?

Getting following exception at random positions.
The runtime has encountered a fatal error. The address of the error
was at 0x65c08447, on thread 0x14d8. 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.
This module is worked fine yesterday but giving this exception today. i just changed debug configuration to x86. Yesterday it was AnyCPU. But i'm using sqlite and it reports following warning when configuration was AnyCPU.
Warning :- There was a mismatch between the processor architecture of
the project being built "MSIL" and the processor architecture of the
reference "System.Data.SQLite, Version=1.0.66.0, Culture=neutral,
PublicKeyToken=db937bc2d44ff139, processorArchitecture=x86", "x86".
This mismatch may cause runtime failures. Please consider changing the
targeted processor architecture of your project through the
Configuration Manager so as to align the processor architectures
between your project and references, or take a dependency on
references with a processor architecture that matches the targeted
processor architecture of your project.
I'm using unmanaged code from How do I get common file type icons in C#?. Also i'm using objectlistview.
All the code except this is just for accessing database.
my machine has windows 7 x64 ultimate.
Error starting to come up in search functionality of my application

Categories