Your question is devoid of details and the stack trace is short but gives lots of clues towards the underlying problem. Some visible facts:
- the exception occurs on the finalizer thread, the reason the stack trace is so short. An unhandled exception in a finalizer is fatal, they'll always terminate the program. The reason that trying to use try/catch in your code had no effect.
- a connection-point cookie is a COM term, you get one when you subscribe a COM event. That cookie needs to be used again when you unsubscribe the event, that happens in the finalizer. There is only one class in WPF that uses it, the WebBrowser control. The WPF class is a wrapper around Internet Explorer, a COM component.
- the exception, while it has a managed exception name, is not caused by managed code. The finalizer already checks for null references, it is Internet Explorer that throws an unmanaged AccessViolationException under the hood. These are treated the exact same way by the CLR since they have the exact same cause, the finalizer doesn't otherwise do anything to make the distinction clearer. Unmanaged code is just as vulnerable as managed code to null pointers. More so, heap corruption is a very common cause.
- the finalizer already catches all exceptions, an NRE is however a critical exception so it rethrows it, that's the end of your program.
Using WebBrowser is a liability, browsers in general are rather crash-prone. This is amplified when you use the control in your app, it runs in-process and doesn't have the kind of crash protection that Internet Explorer itself uses. So anything that goes wrong in the browser will directly affect the stability of your app, often with a very hard to diagnose crash reason since it is unmanaged code that bombs.
And such crashes repeat very poorly, the core reason that you trouble getting a repro for it yourself. The most common troublemakers in browsers are add-ins, ActiveX controls (like Flash) and anti-malware. You'll have extra trouble if you can't control the kind of web sites that are navigated, there are plenty that probe a browser for vulnerabilities intentionally.
There is one specific countermeasure you can use, call the control's Dispose() method when you no longer use it. Typically in the Window's Closing event handler. That will immediately unregister the COM event and trigger the crash, now you can catch it. Do strongly consider shutting down your program when that happens, you do have a dead corpse in your process that will turn in a zombie when you try to revive it.
