none
Empty User.Config file causes exception RRS feed

  • Question

  • Somehow the User.Config file was corrupted for an instance of my VB .NET app.  When access one of my user level  config property (My.Settings.MyProp) I get the a ConfigurationErrorsException with the message "Configuration system failed to initialize."  I looked at the User.Config file and found that it is empty, it can be opened but there is no XML text contained within.

    I would like to programmatically fix the file if an exception is seen.  When I attempt to use any of my user level properties, I continue to get the same exception.  I've tried calling the Reset() but that yeilds the same exception. I then tried Save() to see if it would write out a default version, but it appears to do nothing (the file is not updated).  My.Settings appears to be useless at this point.

    How can I reinitialize the User.Config file to the default config settings without deleting the old file?  I would think that there should be some mechanism for restoring this file back to its default.  And how can I update/reinitialize the My.Settings instance so that I can access the properties normally?

    Thanks,
    Nate
    Thursday, September 13, 2007 12:58 PM

Answers

  • I will use the Upgrade feature, which I should have been using already.  I'm surprised no one has complained that their settings were being lost at each new version.  I guess my only options at this point are delete the file and restart the app or push out a new version.  Sending out a new version of the app when this occurs isn't practical for us at this time.  I'm now trying to see if I can piece together the location of the user.config file with Application and System.Reflection starting with the information found at this site.  It states the file should be located here:

    <Profile Directory>\<Company Name>\<App Name>_<Evidence Type>_<Evidence Hash>\<Version>\user.config.

    I think I could parse out the Profile Directory from Application.LocalUserAppDataPath.
    Company Name could then be generated from Application.CompanyName, but replace spaces with underscores.
    App Name could be parsed from Application.ExecutablePath.
    Version from System.Reflection.Assembly.GetExecutingAssembly.GetName.Version.ToString() or Application.ProductVersion.

    Any ideas how I could get Evidence Type (which appears for me to be "Url") and Evidence Hash (which is something like "05w4oao5ih30e4czzjzmxrc0mzekhlvz")?  Also, are there any strong reasons on why I should not be doing this?

    Thanks again,
    Nate
    Friday, September 14, 2007 2:34 PM
  • I should have noticed this sooner, but the inner exception message of the ConfigurationsErrorException object has the path of the User.Config file embedded in it.  Here's the message I get when the file is empty:

    Root element is missing. (C:\Documents and Settings\naxtell\Local Settings\Application Data\Progeny_Systems_Corp.\NITSSClient.exe_Url_gw5wbefo0cwee2aihvkse4dd5tqupzrh\2.1.2813.12436\user.config)

    I've implemented a parse routine that grabs the file path, then I delete the file, close the applciation .  The next time the user opens the app, the user.config file will be regenerated in its normal fashion.


    Thanks for all your help,

    Nate

    Friday, September 14, 2007 6:19 PM

All replies

  • You'll need to treat this as unrecoverable file damage, not unlike damaged to one of your assemblies.  After the configuration manager failed to initialize, there is no way to rewrite the file with My.Settings or System.Configuration.  I don't see how you could automatically restore a backup file, the path of the file is impossible to find.  This will take a sysadmin (she could perhaps salvage some data) or a re-install.
    Thursday, September 13, 2007 4:35 PM
    Moderator
  • So if I wanted to programmatically delete the User.Config file after the initial exception is seen, I can't because there is no way to find the file?  The application knows how to access the file, does it not expose at least the location where the User.Config file should be?

    If this is the case, I would then have to instruct the user to go delete their User.Config file in order for Settings to be used again.  Its either that or have them wait for some admin to come and help with the file cleanup...

    It just seems like the settings classes should handle this better.

    Thanks, Nate
    Thursday, September 13, 2007 5:56 PM
  • How often does this happen to you?  This is the first time I ever heard of it on these forums.  You might be better off looking for the cause of the damage.
    Thursday, September 13, 2007 6:40 PM
    Moderator
  • It has happened once so far; but since it happened once, I have to write some form of "fix" for it.  Since the file is managed by internal .NET Framework functionality, I can only speculate as to the reason for how it occurred.  Do you have a suggestion for looking for the cause?  I can easily reproduce this problem seen by a user of my app by deleting the contents of the User.Config for my current development build.  I have no idea how it could happen.  Does the Settings management processes ever clear the file contents in entirety then write in the new XML?  There's just no way to tell.

    Thanks, Nate
    Thursday, September 13, 2007 6:49 PM
  • Hmya, hard disks.  The bad things happen to the files that change most often.  Make sure your re-install or repair procedure is solid.
    Thursday, September 13, 2007 7:28 PM
    Moderator
  • The settings goo should (obviously) *not* wipe out all the contents of the user.config file. This is the first time I've heard this happening, and there is a high probability that any bug report on this would come my way sooner or later.

     

    When I've seen the "Configuration system failed to initialize" issues, the two most common causes are:

     

    1) The user has deleted the app.config/app.exe.config file. By default, the section handler for the application settings section is declared in this file, and without that, the configuration system doesn't know what to do with the userSettings section in the user.config file.

     

    2) The user has changed the type of a setting where the user have already saved a value of the old type, particularly if the serialization scheme changed from string to an XML serializable type.

     

    If you own the application, and can release a new version, you could try to bump the assembly version and upgrade the settings by calling My.Settings.Upgrade method. If you wrap the Upgrade call in a try/catch, any machines where the user.config is empty would fail, and you'd be back to the default values. If the user.config file is correct, the settings would be preserved.

     

    Raghavendra outlines how to determine when to call upgrade in his client config FAQ.


    Best regards,

    Johan Stenberg

    Friday, September 14, 2007 3:54 AM
    Moderator
  • I will use the Upgrade feature, which I should have been using already.  I'm surprised no one has complained that their settings were being lost at each new version.  I guess my only options at this point are delete the file and restart the app or push out a new version.  Sending out a new version of the app when this occurs isn't practical for us at this time.  I'm now trying to see if I can piece together the location of the user.config file with Application and System.Reflection starting with the information found at this site.  It states the file should be located here:

    <Profile Directory>\<Company Name>\<App Name>_<Evidence Type>_<Evidence Hash>\<Version>\user.config.

    I think I could parse out the Profile Directory from Application.LocalUserAppDataPath.
    Company Name could then be generated from Application.CompanyName, but replace spaces with underscores.
    App Name could be parsed from Application.ExecutablePath.
    Version from System.Reflection.Assembly.GetExecutingAssembly.GetName.Version.ToString() or Application.ProductVersion.

    Any ideas how I could get Evidence Type (which appears for me to be "Url") and Evidence Hash (which is something like "05w4oao5ih30e4czzjzmxrc0mzekhlvz")?  Also, are there any strong reasons on why I should not be doing this?

    Thanks again,
    Nate
    Friday, September 14, 2007 2:34 PM
  • I should have noticed this sooner, but the inner exception message of the ConfigurationsErrorException object has the path of the User.Config file embedded in it.  Here's the message I get when the file is empty:

    Root element is missing. (C:\Documents and Settings\naxtell\Local Settings\Application Data\Progeny_Systems_Corp.\NITSSClient.exe_Url_gw5wbefo0cwee2aihvkse4dd5tqupzrh\2.1.2813.12436\user.config)

    I've implemented a parse routine that grabs the file path, then I delete the file, close the applciation .  The next time the user opens the app, the user.config file will be regenerated in its normal fashion.


    Thanks for all your help,

    Nate

    Friday, September 14, 2007 6:19 PM
  • I have encountered this issue -- empty user.config -- a couple times now, during testing of my .NET application. The latest time was after a power bump. Upon reboot, my application would not start and I found that, though the file size was accurate, the file contained "blanks" and was literally empty.


    Tuesday, August 19, 2008 7:54 PM
  • Hi there.

    This is an old thread but I hope we can bring it back to life again a little. I sometimes also get the error above but some times I also get some form of initializing error even before my applications gets to its Main function making it impossible to wrap any configuration initializing in a try catch block and managing an error...

    Have any of you guys experienced an error like that?

    Has the OP since elaborated on his findings with the deleting of the file?
    Did it work?
    Did you have to restart the application or was a reset/save/load enough?
    Tuesday, February 16, 2010 9:34 AM
  • I have just started seeing this error on .NET 2.0 app we recently delivered

    I'm still trying to get the details - but the last user got the error after an upgrade (such as from 2.0.3.0 to 2.0.3.4)

    In my code I do have a

    My

     

    .Settings.Upgrade()

    I use the trick of having a flag AttemptToUpgradeSettings in the settings which is true and then after Settngs.Upgrade() I set it to false (i.e. so it should only be true on new installs or upgrades) but this logic is only called after main window is shown - and the error is happening just as the splash screen is displaying.

    The fix I have told users to do is use the path in the error message to locate and delete the user.config
    Then the next time the app starts it "corrects itself"

    Between these upgrades settings had been added and the app has a lot of settings - I am not sure if that has anything to do with it.
    Other than manually blank out the user.config I have not been able to recreate the issue.

    Still trying to gather info on the exact scenario of when the error occurs.
    Thursday, February 18, 2010 5:29 PM
  • We also have experienced this issue.  I have hundreds of users, but two so far have had it happen.  One user has had it happen twice and the other user just a single time.  In both instances, the user.config file was empty even though it previously had data.  I had the user delete the file and that allowed them to continue running.  But there is no explanation for why the file was empty in the first place.

    Monday, February 22, 2010 7:34 PM
  • Unfortunately, I have thousands of users and have had many with this problem.  Most often after I put out a new update (Upgrade() is being called with any new version).  Though, some users report that all was working fine but the next time they used the software, it would throw this exception.  I have even seen this with a couple of XML files that the software uses.

    I try to catch the exception the first time that a setting is accessed, but haven't been able to restore the file.  Calling My.Settings.Reset() or anything else from that class just throws the same exception.

    Has anyone found a way to programatically recover from this?  If so, the user could at least be warned that their settings were lost and to reset them.  Certainly not ideal, but better than trying to get them to navigate to the user.config file and delete it.  Of course, addressing the root cause would be even better.
    Tuesday, March 16, 2010 5:49 AM
  • gpraceman - you say you do My.Settings.Upgrade()

    And you say you have tried to resolve by capturing when a setting is first accessed

    So does that mean you have isolated the cause to My.Settings.Upgrade() ?

    i.e. .Settings.Upgrade() is called without exception, but then later when a setting is accessed "kapow"

    If so, I'm wondering if you put in any logic to read the XML contents inside the code before the call to My.Settings.Upgrade() and then after to prove that is where the config file is getting "whacked"

    It almost seems like something inside the Upgrade() logic such as an open write stream

    Tuesday, March 16, 2010 6:22 PM
  • First, I deleted out all contents of the user.config file to reproduce the exception.

    The first time any property of My.Settings is called, the ConfigurationErrorsException is thrown.  It just happens that the first call in my code is my boolean property to see if Upgrade() needs to be called.  I try to catch that exception right there, but it seems to be too late to try to recover.  Any other call to My.Settings, like to Reset() just throws that same exception.  The only way to recover that I have found is to delete the user.config file and restart the app.

    What actually causes the problem in the first place, I do not know.  But adding a new property may be somehow related.  Here is the stack trace from a user that just today ran into that same problem.  This problem also is more common with my XP users.  I just wish I had him send me his file before he deleted it.  I don't know if it was zero length or not.

    Application Error: Root element is missing. (C:\Documents and Settings\...\9.0.901.9\user.config)
    Source: System.Configuration OS: Microsoft Windows XP Professional Service Pack 3 Version: 5.1.2600 Stack Trace: at System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(ignoreLocal As Boolean) at System.Configuration.BaseConfigurationRecord.ThrowIfParseErrors(schemaErrors As ConfigurationSchemaErrors) at System.Configuration.Configuration..ctor(locationSubPath As String, typeConfigHost As Type, hostInitConfigurationParams As Object[]) at System.Configuration.ClientConfigurationHost.OpenExeConfiguration(fileMap As ConfigurationFileMap, isMachine As Boolean, userLevel As ConfigurationUserLevel, exePath As String) at System.Configuration.ConfigurationManager.OpenExeConfigurationImpl(fileMap As ConfigurationFileMap, isMachine As Boolean, userLevel As ConfigurationUserLevel, exePath As String) at System.Configuration.ConfigurationManager.OpenMappedExeConfiguration(fileMap As ExeConfigurationFileMap, userLevel As ConfigurationUserLevel) at System.Configuration.ClientSettingsStore.ReadSettingsFromFile(configFileName As String, sectionName As String, isUserScoped As Boolean) at System.Configuration.LocalFileSettingsProvider.GetSettingValuesFromFile(configFileName As String, sectionName As String, userScoped As Boolean, properties As SettingsPropertyCollection) at System.Configuration.LocalFileSettingsProvider.Upgrade(context As SettingsContext, properties As SettingsPropertyCollection, isRoaming As Boolean) at System.Configuration.LocalFileSettingsProvider.Upgrade(context As SettingsContext, properties As SettingsPropertyCollection) at System.Configuration.ApplicationSettingsBase.Upgrade() at LisanoEnterprises.GrandPrix.frmMain..ctor() Exception Hierarchy: Top Level System.Configuration.ConfigurationErrorsException Void ThrowIfErrors(Boolean) Inner Exception 1 System.Xml.XmlException Void Throw(System.Exception)

    For this particular user, it looks to be a problem when Upgrade() is called and then it chokes.  The latest version of my app added in a new Size property to remember the size of a particular screen.  The file listed in the exception message is actually is in the old version number folder, not the new.
    Tuesday, March 16, 2010 8:02 PM
  • I have the same problem. I managed to only find that file becomes corrupted if writing off (or restart) the computer. Then either the file has zero length or contains not valid XML.

    I'm surprised that it probably can not be easily programmed to solve. So far, I said users, where some file is located and that it be deleted. This is the only thing she helps :-(

    Lukas

    Tuesday, May 4, 2010 1:25 PM
  • For Windows Vista, 7 and 8 only: 

    Instead of all the methods of finding the user.config file, go to C:\\ Drive and type "user.config" in the search box in the top right corner of the window
    You'll be displayed with many files as Windows keeps searching.
    Delete the files and all the settings will be proper during run-time

    Thursday, May 3, 2012 7:51 AM