1

I have a program which reports errors/stack trace back to me in case of crash and if user wishes to send it.

Occasioanly I receive wierd charcters in error message and also stack trace as you can see below.

ファイルã¾ãŸã¯ã‚¢ã‚»ãƒ³ãƒ–リ 'Interop.iTunesLib, Version=1.11.0.0, Culture=neutral, PublicKeyToken=null'ã€ã¾ãŸã¯ãã®ä¾å­˜é–¢ä¿‚ã® 1 ã¤ãŒèª­ã¿è¾¼ã‚ã¾ã›ã‚“ã§ã—ãŸã€‚指定ã•ã‚ŒãŸãƒ•ã‚¡ã‚¤ãƒ«ãŒè¦‹ã¤ã‹ã‚Šã¾ã›ã‚“。


stack trace
------------------------------------------------------
  å ´æ‰€ STLib.TInfo.Init(Form f)
  å ´æ‰€ STLib.FormMain..ctor() å ´æ‰€ C:\repo_sync\ST\FormMain.cs:è¡Œ 37
  å ´æ‰€ STLib.Program.Main() å ´æ‰€ C:\repo_sync\ST\Program.cs:è¡Œ 54

My code that builds up the stack trace looks like this

  private static void GlobalThreadExceptionHandler(object sender, System.Threading.ThreadExceptionEventArgs e)
    {
        ...
        String stackTrace = "";
        Exception currentEx = e;

        do
        {
            stackTrace += string.Format("\r\n{0}", currentEx.Message);
            stackTrace += "\r\n------------------------------------------------------";
            stackTrace += string.Format("\r\n{0}", currentEx.StackTrace);
            currentEx = currentEx.InnerException;
            if (currentEx != null)
            {
                stackTrace += "\r\nCaused by";
            }
        }
        while (currentEx != null);
        .....
      }

I guess probably it has to do Non English language of that machine, can someone please advise me on this as to whats wrong here..

Added after Hans Pasant's comment

I have following code which converts the stack trace to bytes before posting to a web..

byte[] postdata = System.Text.Encoding.UTF8.GetBytes(stackTrace)

I post this data using exactly the same code as here

Multipart forms from C# client posted by Brian Grinstead

Community
  • 1
  • 1
Ahmed
  • 14,503
  • 22
  • 92
  • 150
  • Could be memory corruption causing this. Is this happening all the time? – Oded Jun 02 '12 at 09:38
  • Well not on all machine, but occasianly when I get reports they contain strange characters – Ahmed Jun 02 '12 at 09:41
  • I'll get this too from time to time when users from non-latin regions of the world (e.g. arabia) report me errors. I simply pretend that my font doesn't display those characters correctly. Should have nothing to do with the actual error. Another option could be some kind of obfuscator. – Uwe Keim Jun 02 '12 at 09:41
  • 2
    Why are you using a custom implementation instead of the default `Exception.ToString()` (which returns practically the same information as you are)? – Douglas Jun 02 '12 at 10:31
  • @Douglas Thanks for code review, the answer is simple I did not know that untill you told me :) – Ahmed Jun 02 '12 at 20:01

3 Answers3

2

This is a text encoding problem. You'll get this when your code bombs on a machine that's for example Japanese, Korean or Chinese. Exception traces are generated using the machine's default language. The English version looks like:

at namespace.method(args) in C:\path\filename.cs:line 10

where the at, in and line parts of the message will be in the native language, using character glyphs for CJK languages. Everything will work in the snippet you posted. What goes wrong is what you do to get the string from the crashing machine to your machine. Which is entirely unclear from the question. But if you, say, do it with an email message then you are not using the proper BodyEncoding. Or you do but your email reader doesn't interpret it correctly.

The high incidence of ムmakes it likely that the original text was encoded in utf8, they are character codes 0xC3 and 0x83 when using a Western code page. Which are the first 2 bytes of 3 byte utf-8 sequences for codepoints U+30C0 and up. Which are Hiragana and Katakana glyphs. Thus making it pretty likely that your program crashed on a Japanese machine. And that you read the text with Encoding.Default on your machine instead of Encoding.UTF8

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Hi, I have added more information in my question after your comment could you please take a look,. – Ahmed Jun 02 '12 at 20:34
  • I have worked it out, the problem was Stacktrace viewer interpreting the text in wrong way after I used another viewer with UTF-8 it read it fine. it definitely seems Japnese or chinese :) Marking your answer as correct one. thanks – Ahmed Jun 02 '12 at 21:01
  • It is Japanese. Funny thing is: does it actually make a difference :) – Hans Passant Jun 02 '12 at 21:29
1

You are not using Culture. Maybe you should try:

 CultureInfo culture = CultureInfo.InvariantCulture;
 string output = String.Format(culture, ..., ...);

You will find more info on MSDN about String.Format and InvariantCulture.

Daniel Daranas
  • 22,454
  • 9
  • 63
  • 116
  • Thanks Daniel I would try that , but is there a way to test it on my own machine. Like can I change the language of my OS somehow to see if it is reproduced ? – Ahmed Jun 02 '12 at 10:04
  • @Ahmed, you can change a threads culture, which should change formatting and encoding behaviors, something like: http://msdn.microsoft.com/en-us/library/b28bx3bh(v=vs.80).aspx should do the trick. – Phil Price Jun 02 '12 at 21:23
0

Why the characters occur I'm not sure, perhaps as suggested changing the culture will help, but there's also a nifty way to get stack information not preformatted by the exception object with the System.Diagnostics.StackTrace. By using that you can format the stack how you want and it might be that it doesn't display the formatting problem. Not sure of course. Still, it contains a lot of usefull info

            //get stack trace information from Exception ex
            StackTrace st = new StackTrace(ex, true);

            foreach(StackFrame frame in st.GetFrames())
            {
                //you can get file, file line number, column number, 
                //precise method info ets here
            }

Personally I use a wrapper for exceptions that can create the html or be used to send serialzed info. When the serialized info is openened on my own computer the viewer program adds the lines out of the source file where the error occured.

Me.Name
  • 12,259
  • 3
  • 31
  • 48
  • Thanks Robert, the info you provided is very useful. I would defintiely take that into account .. – Ahmed Jun 02 '12 at 10:12