-
Notifications
You must be signed in to change notification settings - Fork 559
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EtwDiagnosticTrace throw exception if fault message contains certain Unicode characters #5583
Comments
We can fix this with the sledgehammer approach and simply catch any exception that gets thrown while trying to log this, but for me that leaves a bad taste. Can you confirm that the fault looks like a regular fault other than having the record separator character in the fault message? Something like that should get XML encoded so I'd like to work out why the XML writer is getting into a bad state instead of doing something sensible. |
The fault looks like all the other faults but as soon as a record separator is in the message, it causes the Exception during logging. I tried to create a reproduction of the problem (with some reflection code, because the tracing classes are internal) but so far I was unable to create a fault exception that would demonstrate my problem... One thing I did wonder though: Why is this kind of tracing enabled by default and why does there not seem to be a way to disable it? |
I managed to create a reproduction of the problem. The solution has wcfCore Service and a simple client and if you run both projects at the same time the client receives a "writer is in closed state" exception. The server creates a rather harmless looking fault: |
Describe the bug
A returned fault containing a record separator (�) causes an exception in EtwDiagnosticTrace.ExceptionToTraceString(), which hides the fault from the client.
To Reproduce
Call a wcf service that returns a fault with a message containing a record separator. Instead of the fault an InvalidOperationException is thrown:
Expected behavior
A FaultException based on the returned fault is thrown.
Additional context
The same faults can be processed without any problem in .NET48
The text was updated successfully, but these errors were encountered: