Mysterious null value bug
-
Suddenly several people are reporting problems with the XML .config file of our application, it is filled with null values only. It seems to be related to PC resets or power loss, see: c# - What could cause an XML file to be filled with null characters? - Stack Overflow[^] Anyone else ever encountered this?
-
Suddenly several people are reporting problems with the XML .config file of our application, it is filled with null values only. It seems to be related to PC resets or power loss, see: c# - What could cause an XML file to be filled with null characters? - Stack Overflow[^] Anyone else ever encountered this?
Yes, I encountered it numerous times on numerous different machines, despite them all having a UPS to ensure a clean shutdown on power failure. I created a
ConfigurationUncorrupterclass. It detects when an app startup is complete and configuration has been successfully loaded then it creates a safe copy of the config file. If, on the other hand, loading configuration fails, it replaces the config file with the backup from the last successful start and tries again. Every app gets that class incuded. That has pretty much eliminated the problem for me.Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
-
Yes, I encountered it numerous times on numerous different machines, despite them all having a UPS to ensure a clean shutdown on power failure. I created a
ConfigurationUncorrupterclass. It detects when an app startup is complete and configuration has been successfully loaded then it creates a safe copy of the config file. If, on the other hand, loading configuration fails, it replaces the config file with the backup from the last successful start and tries again. Every app gets that class incuded. That has pretty much eliminated the problem for me.Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
I like that idea a lot, as part of a belt-and-suspenders system. But this begs the question, I'd be very curious to know what happens so frequently and in such a repeatable fashion that such a thing had to be written in response to this recurring situation. I mean, a config file is typically something that should be read (in read-only mode) at startup and then closed and left alone. Then even if the system isn't shut down cleanly, that config file should be safe. The only time it should be at risk is when it's opened to write new data into it or edit existing data. What gets it corrupted so easily? And I hope that when your Uncorrupter class knows it has to intervene and restore the config file from a backup, it logs everything it possibly can to try to narrow down any potential source. Because that's not a "normal" state of operation. I'd be very uncomfortable knowing this auto-restore code gets triggered on a regular basis without understanding why.
-
Yes, I encountered it numerous times on numerous different machines, despite them all having a UPS to ensure a clean shutdown on power failure. I created a
ConfigurationUncorrupterclass. It detects when an app startup is complete and configuration has been successfully loaded then it creates a safe copy of the config file. If, on the other hand, loading configuration fails, it replaces the config file with the backup from the last successful start and tries again. Every app gets that class incuded. That has pretty much eliminated the problem for me.Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
Article?
Wrong is evil and must be defeated. - Jeff Ello
-
Article?
Wrong is evil and must be defeated. - Jeff Ello
Verb?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
Verb?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
Expletive!
This thread is almost like CCC: The - article s**t - expletive happens - verb :laugh:
Mircea
-
Suddenly several people are reporting problems with the XML .config file of our application, it is filled with null values only. It seems to be related to PC resets or power loss, see: c# - What could cause an XML file to be filled with null characters? - Stack Overflow[^] Anyone else ever encountered this?
Part of me is thinking this is a wind-up, right? I mean; power goes off, computer dies; and with the last few spare electrons the dedicated "XML File Writer" chip is enabled and the special write-only head on the slowing diskdrive momentarily lights up to zap the file to all zeros. Or wait, does it convert them to spaces? Or re-write the entire file removing the data between the XML tags? But surely it also needs to adjust the sectors after the end-of-file, or maybe even move the file elsewhere, which means updating the FAT, which means knowing where it is... Man, that chip has some pretty intense logic hard-wired into it. But seriously; a power failure causing a specific type of file to have a specific type of corruption written to it? However, having read that SO issue, it does begin to sound like there is some logic to it. All I can say is that in 25 years of using Windows, with a fair number of power failures and OpSys crashes along the way, I'm not aware of such a situation arising, ever. That's not to say it hasn't; maybe the software has corrected itself or maybe I've never needed to access affected files. That XML configuration files are frequently the victims, though, suggests to me that there is something in the CLR that is inappropriately readying the XML file for a write FAR too soon. This smacks of just really poor design within the MS subsystem, or an actual bug. This doesn't surprise me. Thank for highlighting it here!
-
Part of me is thinking this is a wind-up, right? I mean; power goes off, computer dies; and with the last few spare electrons the dedicated "XML File Writer" chip is enabled and the special write-only head on the slowing diskdrive momentarily lights up to zap the file to all zeros. Or wait, does it convert them to spaces? Or re-write the entire file removing the data between the XML tags? But surely it also needs to adjust the sectors after the end-of-file, or maybe even move the file elsewhere, which means updating the FAT, which means knowing where it is... Man, that chip has some pretty intense logic hard-wired into it. But seriously; a power failure causing a specific type of file to have a specific type of corruption written to it? However, having read that SO issue, it does begin to sound like there is some logic to it. All I can say is that in 25 years of using Windows, with a fair number of power failures and OpSys crashes along the way, I'm not aware of such a situation arising, ever. That's not to say it hasn't; maybe the software has corrected itself or maybe I've never needed to access affected files. That XML configuration files are frequently the victims, though, suggests to me that there is something in the CLR that is inappropriately readying the XML file for a write FAR too soon. This smacks of just really poor design within the MS subsystem, or an actual bug. This doesn't surprise me. Thank for highlighting it here!
It might also have to do with the complicated way the settings are written by several applications to the same config file. We use Mutexes to prevent applications accessing this file at the same time. In the past the applications just wrote to their own config file, but it was decided that everything should be written to the same file ... :~
-
Suddenly several people are reporting problems with the XML .config file of our application, it is filled with null values only. It seems to be related to PC resets or power loss, see: c# - What could cause an XML file to be filled with null characters? - Stack Overflow[^] Anyone else ever encountered this?
Years ago, I ran into something similar with compiles. I eventually tracked it down to "endpoint" software which would "see" a change and try to back up files that would stop them from being written correctly.
-
I like that idea a lot, as part of a belt-and-suspenders system. But this begs the question, I'd be very curious to know what happens so frequently and in such a repeatable fashion that such a thing had to be written in response to this recurring situation. I mean, a config file is typically something that should be read (in read-only mode) at startup and then closed and left alone. Then even if the system isn't shut down cleanly, that config file should be safe. The only time it should be at risk is when it's opened to write new data into it or edit existing data. What gets it corrupted so easily? And I hope that when your Uncorrupter class knows it has to intervene and restore the config file from a backup, it logs everything it possibly can to try to narrow down any potential source. Because that's not a "normal" state of operation. I'd be very uncomfortable knowing this auto-restore code gets triggered on a regular basis without understanding why.
Yes, it does all the appropriate logging. The problem only occurs on startup and I'm sure it's not caused by any of my code. My code never explicitly writes to the config file. I have a much more complex, multi-application, shared configuration system that doesn't suffer from the same problem. It's only the very simple, standard, AppName.exe.config file that is ever affected.
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
-
It might also have to do with the complicated way the settings are written by several applications to the same config file. We use Mutexes to prevent applications accessing this file at the same time. In the past the applications just wrote to their own config file, but it was decided that everything should be written to the same file ... :~
See my reply to dandy72, above.
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
-
Yes, it does all the appropriate logging. The problem only occurs on startup and I'm sure it's not caused by any of my code. My code never explicitly writes to the config file. I have a much more complex, multi-application, shared configuration system that doesn't suffer from the same problem. It's only the very simple, standard, AppName.exe.config file that is ever affected.
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
Gotcha. I wasn't trying to blame your code, and the fact that others have reported the same problem doesn't surprise me. That pretty much rules yours out. So given those circumstances, I think you're doing exactly the right thing - it's out of your control, but you anticipate it and do the best to recover gracefully given the circumstances. And you log it so you know when it happens. So you should have all the ammunition you need when someone tries to place some blame.
-
Gotcha. I wasn't trying to blame your code, and the fact that others have reported the same problem doesn't surprise me. That pretty much rules yours out. So given those circumstances, I think you're doing exactly the right thing - it's out of your control, but you anticipate it and do the best to recover gracefully given the circumstances. And you log it so you know when it happens. So you should have all the ammunition you need when someone tries to place some blame.
Thanks. I didn't think you were blaming me; I just wanted to be clear for the sake of others encountering the same problem.
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
