Fiddler captures HTTPS traffic by generating on-the-fly a fake certificate for the intended server, thereby running a complete Man-in-the-Middle attack. This requires that the client is configured to accept the Fiddler-controlled CA as a trusted CA, as described in the documentation.
This kind of interception breaks client certificates. When there is a client certificate in SSL/TLS, the client technically signs (during the handshake) what amounts to a hash of all received and sent handshake messages so far; the signature computed by the client will then cover (among other things) the server's certificate as seen from the client, i.e. the fake one generated by Fiddler, not the genuine server's certificate. Therefore, the client signature will not match the handshake messages that the server saw.
If the documentation is to be believed, then Fiddler can fix that, but this requires Fiddler to recompute the client signature. This works only if Fiddler has access to the client's private key. The ".cer" file is not sufficient; the private key is needed. The documentation is a bit unclear; my guess is that Fiddler uses the ".cer" file to know what client certificate to use, then will look for that certificate and private key within the local user's certificate store (which would be why Fiddler's documentation says that you should first import the certificate "as a .pfx file", i.e. with its corresponding private key, and then just export the ".cer" file). In any case, without access to the client private key, Fiddler will not be able to masquerade as the true client when talking to the server.
Now Fiddler could also have a limitation with regards to EC certificates; that I don't know. From what I explain above, Fiddler must run as a TLS client when talking to the genuine server, so if there is a client EC certificate, then Fiddler's code must support it, meaning that Fiddler must be able to generate an ECDSA signature.
From the documentation we see that the private key remains within the entrails of the client machine (a Windows system). Thus, any signature generation will need to go through the cryptographic API offered by Windows. Windows has two completely distinct API: CryptoAPI and CNG. CryptoAPI is the old one; CNG was introduced with Windows Vista and 2008. From the point of view of an application (e.g. Fiddler), a private key stored and managed with CNG can be used only with specific function calls; an application that knows only CryptoAPI cannot use a CNG-stored private key.
Unfortunately, CryptoAPI has no support for elliptic curve. An EC-based key can be used only through CNG. Moreover, Fiddler is said to be written in .NET, and .NET's cryptographic API relies on CryptoAPI only (you can use CNG but you have to do it with explicit invocations of the native DLL ncrypt.dll and bcrypt.dll). Therefore, I find it quite plausible that Fiddler uses only CryptoAPI and, thus, may support only RSA and DSA keys for client certificates, not EC keys.
