WWW Causing crash

Unity Engine
1

Now I’ve always had this issue: http://answers.unity3d.com/questions/17683/fatal-error-in-gc-getthreadcontext-failed

Where I get a GetThreadContext failed when loading unity, and it’s due to me having eset and I can deal with this because it’s only me. My problem is I’ve had people previously report they get the error with a build version of my game and I just got it myself for the first time.

The exact error is

    Fatal error in gcc

    GetThreadContext failed

Now I’ve been able to narrow it down, and it happens when WWW tries to return something.

The specific code that is causing it in my app is pretty much the wiki version of highscores.

public IEnumerator GetScores(string level)
{
    _highScore = "Loading Scores";

    var highscoreUrl = HighscoreUrl + "level=" + [url]WWW.EscapeURL(level);[/url]

    var hsGet = new WWW(highscoreUrl);
    yield return hsGet;

    if (hsGet.error != null)
    {
        Debug.Log("There was an error getting the high score: " + hsGet.error);
    }
    else
    {
        _highScore = hsGet.text;
    }
}

Seems to cause the error every time. The error just pops up in the middle of the screen maybe 3-4s after the coroutine starts and causes the application to freeze.

Now assuming it’s caused by the same error in the editor, I don’t think it’s acceptable to have to require every user of eset or Kaspersky to allow their game through their firewall to make it work.

Now my only real options I can think of if there is no easy fix is to rewrite my own version of WWW to download webpages.

Or does anyone know a way to at least make the error fail silently. I can live with displaying a warning that users will need to allow through firewall to see high scores.

Note does not cause the error when Development Build is selected.

2

Get thread context is a good friend that shows up especially often with on access / live antivirus scanners.

ESET32 was especially bad, crash on nearly every single call.

What you need to do is go into your antivirus guard configuration and change its behavior to “statefull” so it does not “attack” running processes with its checking

3

I realize this, it’s specifically the “Application modification detection” unit in eset. When disabled it runs fine.

But I feel like that I should be able to have a solution that doesn’t inconvenience users too much, or at least prevent them from having to google a response to the error. An error in a game is never a good look for a new user.

If there is no way to suppress the error, guess I’ll try use System.Diagnostics to check if nod32 is running and if it is, give the user a one off warning and a solution on how to fix it with the option of turning off high score showing if they don’t want to turn off the firewall feature.

4

Unhappily there isn’t too much to do aside of seeing if its there which means that you can no longer target web builds as you have no system.diagnostics there.

It would be easier if ESET wouldn’t fuck up threads with its realtime checking.

I’ve recently switched to Comodo (after 3.5 years with ESET) cause I found out that ESET basically is a norton with another name nowadays (as secure as a piece of paper with holes, but impacts other applications like a pro) and have to say that I’m pretty happy :slight_smile:

5

Didn’t intend to target web builds anyway but I just had a look at steam statistics, 8.81% of users have ESET installed. So there’s a fair portion of people who are going to run into problems.

Thanks for your help anyway.