dotnet.exe has exited - Access violation

Question

After upgrading .NET core from 2.0 to 2.1 I started getting following error when running the tests:

The program '[12372] dotnet.exe' has exited with code -1073741819 (0xc0000005) 'Access violation'.

When in debug mode VS just exits debug mode and prints the message above in the output -> Debug window.

The error happens when stepping over httpClient.SendAsync(...).

I think this might be the same issue.

Running the test via dotnet test shows:

The active test run was aborted. Reason: Process is terminating due to StackOverflowException.

Update

The issue was caused by a bad IoC mapping.

Lisalisabet

Make sure you rebuild entire application after a Net Update. The dependencies of the compiler doesn't always recognize a different version of Net. Usually I recommend making copy of project bin folder and then delete which will cause entire project to get rebuilt. – Kaunas

@Kaunas I did rebuild the entire solution. Also this can be reproduced on another computer. – Bissextile

This error code looks like it is from the microprocessor. So it means you are sending data from an address outside the scope of the program. It is possible you are sending a null to the SendAsync(). – Kaunas

I checked and the request is not null. – Bissextile

It is not null when you send it. It could be deleted between the time you put it into the SendAsync and the time it actually get sent. It looks like you have to put break points into the SendAsync and find where the exception is actually occurring. I would add more try/catch blocks as I debug to help isolate issue. – Kaunas

I had a similar problem when executing HttpListener.Start method. Adding a proper firewall-rule OR starting Visual Studio 'as admin' solved it for me. For trouble shooting, try starting VS as admin. – Dupin

@Dupin I tried both the firewall and running as admin and it did not fix it. – Bissextile

@Kaunas It does not matter how many try catch I would use. VS won't break on this type of exception, only logs it in Output window. – Bissextile

You still can use the Catch to add break points for debugging. If you have loops adding a break point in a loop makes it more difficult to locate issue then putting break point in the catch. – Kaunas

@Kaunas That won't work because dotnet.exe dies inside the async function without throwing any exception that is catchable. – Bissextile

Are there any try/catch already in the code? Is there any Using Statements? Using statement often don't report exceptions. I usually replace using with try/catch. You can always put a break point in the async. If you reach the break point than the issue is after the break point. Then keep on adding break point until you find where is doesn't break. What I have seen in the past when you do not have a try/catch the code moves up the execution stack until it finds a try/catch any place in a method. So sometimes it gives erroneous failure points. – Kaunas

Answer 1

In my case there was a hidden endless recursion. I was overriding the == operator and then within that override I was using the == operator without noticing the irony! As @jdweng suggests use breakpoints to drill down into the problem area. It can be well hidden!

Inaccessible

Same here. I wrote an extension method containing boolean logic to avoid repetitive code and then did a change-all for that logic accidentally changing the extension method (too) to call itself. Oops! – Barnabe

This saved my sanity. Thanks – Hadwyn

This is great an all, but it's really not acceptable that any of this would end up in a low-level access violation. Wondering if .net core frameworks got around this issue in newer versions and actually throw a useful exception at the place where the stackoverflow occured. – Curiosity

Answer 2

I also ran into this same error, but in my case it was caused by a typo in the set statement for a property. The offending code:

private bool _isCompressed;
public bool isCompressed {
    get { return _isCompressed; }
    set { isCompressed = value; } //Should be _isCompressed
}

Werth

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Thermistor

Answer 3

I ran in the same issue, because I did't use proper backing fields together with my properties, like:

public int Number {
    get => Number;
    set
    {
        Number = value;
        // infinite loop here
    }
}

instead do:

private int _number
public int Number {
        get => _number;
        set
        {
            _number = value;
        }
    }

Ase

Answer 4

Another possible reason for this is circular class instantiation:
Class A creates an instance of class B.
And Class B creates an instance of class A.

.Net Core has no mechanism of detecting this problem at compile time.

Flaming

Except it does now detect it at runtime and you get an explicit error stating there is a circular reference in the dependency injection. You do not get an Access violation error. – Nord

Answer 5

In my case, infinite recursion was caused by DeepCopy extension while attempting to make a deep copy of an object contained CancellationTokenSource. I don't know why.

Expeditionary

Answer 6

For me my app suddenly closed without raising any exception. I was using unit of work pattern and i did a ridiculous mistake.

private IProductRepository ProductRepository { get; set; }

public IProductRepository Product
{
    get
    {
        ProductRepository ??= new ProductRepository(dbContext);
        return Product; // this should be: retutn ProductRepository;
    }
}

The error code 3221225477 (0xc0000005) indicates an Access Violation, which occurs when your application tries to access memory that it shouldn’t.

But why this happens?

1. Recursive Call:

In my getter, return Product; is supposed to return ProductRepository;. Instead, it calls the Product property again, leading to an infinite recursion.

2. Stack Overflow:

This recursion keeps adding calls to the stack until it overflows. When the stack overflows, it can corrupt memory, leading to an access violation.

3. Access Violation:

The corrupted memory causes the application to try to access an invalid memory location, resulting in the access violation error.

In sum, whenever you get this weird behavior, check if you create a recursive call somewhere

Cirro