AccessViolationException since last week

[tg2k]

I have been getting this exception just since last week in a long-running lighting program:

mscorlib.dll!System.Threading._IOCompletionCallback.PerformIOCompletionCallback(uint errorCode, uint numBytes, System.Threading.NativeOverlapped* pOVERLAP) Unknown [Native to Managed Transition]
kernel32.dll!@BaseThreadInitThunk@12() Unknown ntdll.dll!_RtlUserThreadStart@8() Unknown ntdll.dll!RtlUserThreadStart@8() Unknown

A first chance exception of type 'System.AccessViolationException' occurred in mscorlib.dll Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

There is no native or unsafe code on my end, it's all pure managed code. Also, my code didn't change for several days prior to the issues; it ran for that time almost constantly on and didn't have this issue. I had been running a few-month-old build of HueApi, and just upgraded it this weekend. It still crashes, usually 3-5 times a day now.

Here's my suspicion: I believe the problem started right after installing the latest Windows Updates. So I wonder if either this update is the entire issue, or if this update triggered a latent bug in the HueApi code. I didn't know if the HueApi code is pure safe, managed or not, but if it's all safe, managed code, then it does seem to point entirely at Microsoft.

I'm curious whether anyone else is having this issue.

[michielpost]

Does this happen when you call a specific function of the HueApi? So I can try to reproduce it.

The library is 100% managed C#, so it's probably something in the framework or windows update. I've seen a similar error in another project I have where other people have no issues but I get an AccessViolationException.

[tg2k]

As you can see the call stack doesn't tell us anything about either my code or HueApi, so I'm not really sure. My current program is set to periodically run a call to turn the lights off during the daytime (just to make sure they're off) and to do it's "real" work in the night hours, and I know it's crashed during the day, so it's possible for code this simple to crash it:

    private void TurnOffLights()
    {
        LightCommand lightCommandOff = new LightCommand();
        lightCommandOff.TurnOff();
        _client.SendCommandAsync(lightCommandOff, _lightIds).Wait();
    }

(I should have cached and reused the LightCommand itself, but so far I hadn't done so.)

Two things I did though: I put in an AppDomain.CurrentDomain.UnhandledException handler that restarts the process on failure, and instead of executing from the debugger, I just ran it in the command line. Now it's hard to tell because I also get a lot of sporadic exceptions like this (which I am currently printing and which eat up the entire console buffer):

System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond [ip address](the call stack on this one is a bit long)

I also get these:

System.AggregateException: One or more errors occurred. ---> System.Threading.Tasks.TaskCanceledException: A task was canceled. --- End of inner exception stack trace --- at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceled Exceptions) at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationTo ken cancellationToken) at System.Threading.Tasks.Task.Wait() at LightingController.HueController.Connect() in c:\prog\VS_NET\HomeAutomatio n\LightingController\HueController.cs:line 172 ---> (Inner Exception #0) System.Threading.Tasks.TaskCanceledException: A task w as canceled.<---

System.Threading.Tasks.TaskCanceledException: A task was canceled.

In any case I've changed my code so it won't print these out in detail, and we'll see if it still is having crashes. My hunch is that the debugger itself triggered the problem. I don't know if one of last week's updates was in Visual Studio itself, but if so then that might explain this.

[tg2k]

No crashes outside the debugger, so I'll just close this out. I really didn't think it was a Q42.HueApi issue, but I thought it might be useful for people to see this mode of crash. Hopefully Microsoft fixes it in whatever recent update made the problem appear.

On a side note, I submitted a pull request relating to the above-mentioned exceptions.