Quite some exceptions cannot be caught and which these are differs from .NET version to .NET version. And some exceptions can be caught and logged, but cannot be recovered from (memory exceptions). However, it is possible to debug them (these are called first chance exceptions, the first chance is always for the debugger, the second chance is for the code, thanks to JeroenH for pointing this out). Here's a post at CodeProject that explains this principle.
What you should do is select some candidate exceptions in Visual Studio that you suspect might occur, and attach the debugger to the running instance.
Having unmanaged resources as you have (serial port) means you can have unmanaged leaks (not using IDisposable + using properly) and unmanaged exceptions. These exceptions can only be caught with an empty catch (i.e., without specification of even Exception, which is not the parent of unmanaged exceptions) in a try/catch block.
PS: some undefined behavior can occur when exceptions are raised in finally blocks or in finalizers/destructors. Also, not many exceptions propagate across thread boundaries and terminate all threads.
Edit
To make things a little clearer, there are a few exceptions that the CLR (and its specification) define as non-catchable. Basically, these are all exceptions that cross thread boundaries. These asynchronous exceptions, when occurring within a lock, will result in state corruption. Best known are OutOfMemoryException, ThreadAbortException and StackOverflowException. When the OutOfMemoryException or StackOverflowException occurs in synchronous code, it's unlikely that you can correct state and the CLR will terminate your application.
In addition there's the ExecutionEngineException and BadImageFormatException which should not happen in verifiable code and should not be caught. Exceptions such as the TypeLoadException and MissingMemberException can sometimes be caught and sometimes not (if a linked assembly is missing, it'll be hard to catch these, and you shouldn't, but if you use reflection, you should catch these).
In short: exceptions should be caught in the thread they happen in. You will not be able to catch exceptions if they happen in another thread, because they are not propagated (with the exception of the ThreadAbortException). Your application stays alive after an exception (at least, you think), so it is logical to assume that the exception doesn't happen in the thread where you're trying to catch it. Using the Debug > Exceptions window, you can select any exception and break on the code when they happen.
Note on Exception
An added note on managed and unmanaged exceptions. You cannot catch an unmanaged exception using catch (Exception e), because the unmanaged exception does not inherit from Exception. Instead, use an empty catch, which will trap any unmanaged exception for you. Wrap this around your application and thread entrypoint methods and you should be able to catch the majority of catchable exceptions.
