If the exception you set in the DLL (a) will not get out of the "black box of the process where it is running," then you do not have to worry about serialization. If you have a DLL (b) or an EXE (c) that reference the DLL (a), and their code catch exception, you're still in the same process box, and the exception is just another object in memory, which is shared by all the components (exe and dll) of the process. This is the case for most applications.
If your exception can escape the process - for example, you have a service with an external method that can throw the exception, then the serialization needs to be implemented so that it is sent to the (via the "network" (it can be the real network, a named pipe between processes, or any other way where the object has to be transformed into a of bytes). Other examples are if you want to persist the exception information on the disk, or for any reason perform the "on hand" serialization of the exception (or an object containing it).
Note that even in situations where you want to pass an error to a client (for example, in a web service), you rarely want to pass the exception object directly because it contains much more information than the client needs (for example, stack trace). In this case it is common to create data transfer objects (DTOs) to contain only the relevant information.
