none
Directory.CreateDirectory could create an unhandled exception with CF3.9 on WEC2013 RRS feed

  • Question

  • Hi all,

    The sample piece of code could crate sometime an handled exception...... Is this method is thread safe....normally yes Or is it could be a bug in the CF3.9 ?

    We don't have the same thing with the same code on WInCE6 and CF3.5!

    Someone has an idea ?

    Regards

        class Program
        {
            const string dir = "/sdmemory/test";
            const int delay = 10; //Anything between 0ms and 25ms has crashed.

            static void Main(string[] args)
            {
                // Add handler to handle the exception raised by additional threads
                AppDomain.CurrentDomain.UnhandledException += currentDomain_UnhandledException;
                Console.WriteLine("Welcome to C# on Windows Embedded Systems");

                Thread a = new Thread(() => { Directory.CreateDirectory(dir); });
                Thread b = new Thread(() => { Directory.CreateDirectory(dir); });
                Thread c = new Thread(() => { Directory.CreateDirectory(dir); });
                Thread d = new Thread(() => { Directory.CreateDirectory(dir); });
                Thread e = new Thread(() => { Directory.CreateDirectory(dir); });

                a.Start();
                Thread.Sleep(delay);
                b.Start();
                Thread.Sleep(delay);
                c.Start();
                Thread.Sleep(delay);
                d.Start();
                Thread.Sleep(delay);
                e.Start();

                Console.WriteLine("Done");
                Console.ReadLine();
            }

            private static void currentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
            {
                int error = Marshal.GetLastWin32Error(); //This returns 0 even in a crash.

                Console.WriteLine(error);
            }
        }
    • Edited by FredXerox Tuesday, June 18, 2019 9:10 AM
    Tuesday, June 18, 2019 9:09 AM

All replies

  • Hi Fred,

    Do you have the ability to debug what is going on at the file system / driver level here?  Note that the Windows CE heartbeat is 20ms so it does not surprise me that the granularity below 25ms is lost.  My assumption is that you are hitting a single thread based storage media with Multiple threads.  I have seen similar issues with old SD driver implementations that would actually corrupt the media if you tried something like this.  

    PS Xerox is a Microsoft Partner, would it make sense to reach out to your TAM with this?

    Sincerely,

    IoTGirl


    Tuesday, June 18, 2019 7:33 PM
    Moderator
  • Hi IoTGirl,

    I'm agree with that but if we do the same test in native code (C language, everything works well) with no exception !

    So i think that the SD driver is OK. More than that if we change the destination folder to an internal Nand Flash (with specific drivers) the same behavior appear with CF3.9 and not with native code!

    For the TAM support, now i'm in CONDUENT company (separate few months ago from Xerox) and the transfer of licensing is not really easy lol

    Regards and many thanks.

    Fred

    Wednesday, June 19, 2019 8:51 AM
  • Hi Fred,

    I have reached out internally to see if I can find an Account Exec for CONDUENT.  The company is listed as IoT / Embedded so I expect that is the correct one.

    As to the issue, the interpreter *should* be equivalent so I am not sure where the error condition is introduced. ARM or X86? # of Cores?  Do you have a PB and App debug connection? Call stack?

    Sincerely,

    IoTGirl


    Wednesday, June 19, 2019 6:59 PM
    Moderator
  • Hey Fred,

    Feel free to shoot me a note.

    isaacl at microsoft

    Wednesday, June 19, 2019 7:09 PM
  • Thanks for your answer.

    We use an ARMv7 processor (Imx6DL). An interesting think that i've discovered...

    Our processor is a dual core (imx6DL), if I assign each thread created by the sample application to the same processor core (number 0 for example), the problem and the unhandled exception disappeared !

    I 'm quite sure that there is something wrong with the CF3.9 and the way of managing the multi core with WEC2013 : is it possible ?

    Beside that, the device is running properly without strange behaviour except this one.

    Regards,

    Fred

    Thursday, June 20, 2019 7:23 AM
  • Hi Fred,

    Yes, by design CF should only be sending to one core. Prior versions like CF 3.5 had that restriction in place but I wonder if they tried to get multicore support into CF 3.9 but I'd have to dig through emails from 2012 to find out. I would suspect an update may have broken that restriction and you should definitely report that finding to the Sustained Engineering Team.  

    Email Isaac above and he can route this info to the right team.  You should get to know him as I believe if he isn't your TAM he can find that person for you.

    Sincerely,

    IoTGirl

    (Formerly CEGadgetGirl)

    Thursday, June 20, 2019 4:36 PM
    Moderator
  • Hi Isaac,

    IoTGirl say to me that you can help us lol

    Is it the right place ?

    Regards,

    Fred

    Friday, June 21, 2019 7:10 AM
  • Hi Fred,

    Isaac gives you his email address above, isaacl at Microsoft dot com.  Please contact him directly rather than in the forums.

    Sincerely,

    IoTGirl


    Friday, June 21, 2019 3:47 PM
    Moderator
  • Hi Isaac,

    I've sent you an email. Have you received it ?

    Regards,

    Fred

    Friday, June 28, 2019 8:08 AM
  • Hey there, did not get your email... Please try islevin at microsoft
    Friday, June 28, 2019 9:17 PM
  • Any news about my email ; Have you received it at the new addres ?

    Regards,

    Tuesday, July 16, 2019 9:43 AM