Home/ Questions/Q 8551203
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-11T14:08:44+00:00

I have a timer function that serialize an object into a xml file once

  • 0

I have a timer function that serialize an object into a xml file once every minute. It works for awhile but after about 38 hours or so it has the IO exception below.enter image description here

I can see the directory is there as you can see in my screenshot. Also when this issue occurs I can even type the following command in dos: echo “test” > test.xml and I could create the test.xml file at that exact directory location.

My code is as follow:

try
  {
    if (!Directory.Exists(filePath))
      this.log.Write(LogLevel.Fatal, this.componentName, "Directory not exists: " + filePath);


     lock (lockObject)
        {
          filepath = filepath + "ApplicationState.xml";
          if (File.Exists(filePath))
             File.Delete(filePath);

          if (this.StateObject != null && !File.Exists(filePath))
          {
             using (Stream sWrite = File.Create(filePath))
             {
                this.Serializer = new XmlSerializer(typeof(State));
                this.Serializer.Serialize(sWrite, this.StateObject);
             }
           }
        }
     }catch (Exception ex)
     {
        if (this.log != null)
        {
           this.log.Write(ex, this.componentName);
        }
     }
     finally
     {
        if (this.StreamWriter != null)
        {
             this.StreamWriter.Close();
        }
        bRun = true;

      }

I tried by best to go over the code to make sure that don’t have any hanging IO resources and at this point I am at quite a lost to be honest… does window CE or C# has some type of lock resource on the general IO other than the one I use to open and read file?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I see that you’re writing to something called “\Hard Disk” which makes me think you’re likely writing to some persistent storage volume (e.g. on-board flash, a USB disk, CF card or whatever). Bear in mind that these peripherals require a device driver and likely some interrrupt handlers, which are provided by the device OEM and not Microsoft as part of the OS.

    There’s always the possibility that there’s a bug in the driver chain somewhere that’s causing the issue – it smells like a concurrency lock failure. Remember, when working with an embedded OS, never assume a failure you see is always your code. The OEM could easily have a bug in their code.

    I’d attack this two ways:

    1. Report the issue to the OEM and see if they can repro/fix it
    2. Try to add retry logic to your own code to look for and handle this issue as a workaround.
    • 0