Visual studio, debugging randomly throws SEHException unhandled exception in mscorlib.dll with no stackTrace

Question

I've got a C# Windows Forms application that (outside of debug mode) works perfectly. When I run it in debug mode, each action I take has a random chance of crashing the application (like clicking a button, or closing the main form). There is a lot of async code running in the background, but the app crashes even when no tasks seem to be running (the _formClosing method is an entirely Synchronous method). Notably, the first thing most button clicks in my app do is change the visibile and enabled properties of some buttons, and then will start writing messages to the log - the app crashes before any logs get written (using NLog)

The error being thrown is:

System.Runtime.InteropServices.SEHException
  HResult=0x80004005
  Message=External component has thrown an exception.
  Source=<Cannot evaluate the exception source>
  StackTrace:
<Cannot evaluate the exception stack trace>

With output

An unhandled exception of type 'System.Runtime.InteropServices.SEHException' occurred in mscorlib.dll

and trying to resume the application just ends the debugging session.

The fact that it's not any one specific section of code or event that's triggering the crash, and that the code never crashes outside of debug mode leads me to believe this might be a Visual Studio issue. Are there any settings I can configure within Visual studio to make this crash less prone to occurring? or if not, is there any way to get more information than 'cannot Evaluate the stackTrace'?

Other Information that may or may not be relevant, the memory and CPU usage are both very low at the time of crashing (40MB or so and about 5% CPU utilisation). I'm running the latest Visual Studio Community 2019. The app runs on .Net Framework 4.8. My OS is a local VM running windows 10 enterprise. I also don't think I'm running any Trusteer applications.

My code is also all heavily Try Catched, especially around the button clicks.

Thanks for any help, let me know if I'm missing any relevant information

Edit: I've discovered the line that's causing the issue, commenting out this line causes the app to run fine, completely error free

var ignore = currentJob.jobConfig.ToObject(t); //jobConfig is a JObject

The cast works fine, but by doing the cast, somehow the exception mentioned above and shown below is triggered

Edit #2: Repairing, updating and reinstalling visual studios has not changed the issue, the app still seems to work fine 10-40% of the time, and crash the rest of the time

Answer 1

I found a solution to my problem, by adding 'return;' statements everywhere and removing them one by one (removing large sections of my code). I eventually found the line that was causing problems. It turns out, if you serialise and then deserialise a CancellationToken, visual studio's debug session becomes prone to randomly crashing when, presumably, it tries to do a certain operation on the object you have deserialised to. The solution was just to make the cancellation token either private, or add [JsonIgnore]

Code to reproduce the problem: (run the void method, and then try closing the window)

    private void BreakVS()
    {
        ClassWithCancellationToken someClass = new ClassWithCancellationToken();
        someClass.ts = new CancellationToken();
        var json = JsonConvert.SerializeObject(someClass);
        JObject jObject = JObject.Parse(json);
        var test = jObject.ToObject(typeof(ClassWithCancellationToken));
    }

    public class ClassWithCancellationToken
    {
        public CancellationToken ts; //change to private to 
    }

The answer to my original question then, is to start with Jeroan's solution to try debugging on a different device, if the code still breaks on said device then try what worked for me (hack and slash your code until you find what's breaking it) - or a more sophisticated approach to debugging your code more thoroughly. If your code works on another device, then try Micheal's approach to update/repair/reinstall your Visual studios install

Of course, the one thing I still don't know how to do, is to locate the faulty code without spending an hour removing sections of my code until I find the cause.