AccessViolationException causes build runner to crash

[NightOwl888]

I am referencing a faulty 3rd party component that sometimes throws AccessViolationException during testing (never happened in Visual Studio 2015 Community, only seems to happen from the command line). This AccessViolationException causes the entire test runner to crash.

Expected behavior: NUnit gracefully reports the failure and finishes the test run.

Sure, we also need the 3rd party to fix their component as well, but in the meantime, we still need a way to release. We are using dotnet-test-nunit version 3.4.0-beta-3.

Actually, I have also seen NullReferenceException and IndexOutOfRangeException crash the runner as well.

[CharliePoole]

Back in early days, we had tests in NUnit that even handled stack overflow exceptions!

Starting with .NET 4, it became impossible to catch certain exceptions that indicate a corrupted state of the application. The logic of the change on Microsoft's part is that you can't know how to recover in such cases. AccessViolationException is one of those exceptions that we can't catch.

If this arises only in certain tests, you can use the HandleProcessCorruptedStateExceptionsAttribute on those tests in order to allow the exception to be caught by NUnit. You can also modify the app config (of the exe in use) to include the <legacyCorruptedStateExceptionsPolicy> element, according to the docs.

That said, I have no experience with this - especially in a .NET Core environment. Please help us out by reporting back anything you learn if you try this approach.

[NightOwl888]

Looks like no dice on the attribute - it isn't supported by .NET standard 1.5.

The "exe in question" is dotnet.exe from the .NET Core 1.1 with SDK Preview 2.1 build 3177 (https://github.com/dotnet/core/blob/master/release-notes/download-archive.md). Actually, I haven't worked with any .NET Standard applications (lately anyway), but I don't believe they support app.config settings and according to https://msdn.microsoft.com/en-us/library/dd638517(v=vs.110).aspx, that setting is for .NET Framework only.

I also found this issue, but I have no idea what they are referring to between "desktop" and ".NET Core". I sure hope this doesn't mean that there is no way to make a test runner just ignore this... You might want to weigh in on that one.

So, looks like my only option for the time being is to manually fail or ignore these tests until I have a chance to work out how to reliably reproduce the error and submit an issue.

BTW - Switching the runner for the .NET 4.5.1 part seems to have been a partial fix. It is only failing on the .NET Standard side.

[jnm2]

The "Desktop" runtime is the Windows .NET CLR, currently at v4, and the ".NET Core" runtime is CoreCLR.

[NightOwl888]

UPDATE

I finally was able to isolate the AccessViolationException to a specific scenario and rule out anything in our project as being a factor. However, I discovered that one contributor that is making it occur is the fact that NUnit is the test runner. It does not occur when running as an xUnit test or a console application.

This makes me wonder if there is something about the way the test is run in NUnit that is causing the AccessViolationException to happen. Could you take a look at the repro project to see if you can make that determination?