The .NET Framework Exception class is declared as:

[Serializable]
public class Exception : ISerializable
{
    ....
}

This means that all custom exceptions deriving from Exception must also be marked [Serializable] and must implement the ISerializable interface. Implementing ISerializable involves implementing the GetObjectData method and providing a special constructor for deserialization.

The problem is that custom exceptions that have a lot of custom data would have to serialize all that custom data, which typically means that all the custom data must be [Serializable] also, as well as all of its fields (and so on...). This can result in requiring a lot of classes to be [Serializable] that we might not otherwise have any reason to support serialization for.

An easy shortcut is for custom exceptions to just drop the custom data it doesn't know how to serialize. That means that when the custom exception is deserialized at the receiving end all of its custom data will be zero or null.

We don't think many people care about throwing driver custom exceptions across boundaries that require them to be serialized (.NET remoting and cross-AppDomain for example).

Therefore we probably won't bother to make custom exceptions fully [Serializable]. They will serialize, just that when deserialized all the custom data will be missing.

If you have any use cases where you need custom exceptions to fully support [Serializable] please comment on this ticket.