views:

826

answers:

4

Bashing our heads against the wall here

We are an ISV and have hundreds of companies using our software with no problems. The software is Winforms/C# on .NET 2.0.

One of our clients has installed our software and it crashes on startup on all of their machines, apart from on one guy's laptop where it works fine.

On calling OdbcConnection.Open(), we get the following exception:

The type initializer for 'System.Transactions.Diagnostics.DiagnosticTrace' threw an exception.
  at System.Transactions.Diagnostics.DiagnosticTrace.get_Verbose()
  at System.Transactions.Transaction.get_Current()
  at System.Data.Common.ADP.IsSysTxEqualSysEsTransaction()
  at System.Data.Common.ADP.NeedManualEnlistment()
  at System.Data.Odbc.OdbcConnection.Open()
  at OurCompany.OurForm.connectionTestWorker_DoWork(Object sender)

This has an InnerException:

Configuration system failed to initialize
  at System.Configuration.ClientConfigurationSystem.EnsureInit(String configKey)
  at System.Configuration.ClientConfigurationSystem.PrepareClientConfigSystem(String sectionName)
  at System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(String sectionName)
  at System.Configuration.ConfigurationManager.GetSection(String sectionName)
  at System.Configuration.PrivilegedConfigurationManager.GetSection(String sectionName)
  at System.Diagnostics.DiagnosticsConfiguration.GetConfigSection()

Google just says "app.config is syntactically incorrect, rebuild it" yet the same app.config works fine on hundreds of other machines.

Here's app.config, as requested:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
      <section name="OurApp.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <system.diagnostics>
  </system.diagnostics>
  <applicationSettings>
    <OurApp.Properties.Settings>
      <setting name="OurApp_WebServices_OurServiceName" serializeAs="String">
        <value>http://ourdomain.com/OurService.asmx&lt;/value&gt;
      </setting>
    </OurApp.Properties.Settings>
  </applicationSettings>
  <appSettings>
    <add key="WorkflowEngine" value="old" />
    <add key="ProductID" value="3" />
    <add key="EnableMigrationWizard" value="false" />
    <add key="UseAlternativeFtpPort" value="true" />
    <add key="FeedbackWhileConnecting" value="true" />
  </appSettings>
</configuration>

A repair of the .NET Framework hasn't fixed this. I'm at a total loss. Any ideas?

+2  A: 

Check machine.config and user.config. Along with app.config, those are the 3 that make up the config sections.

Reflector shows EnsureInit has 2 exception paths:

catch (Exception exception) {
    this._initError = new ConfigurationErrorsException(SR.GetString("Config_client_config_init_error"), exception);
    throw this._initError;
} catch {
    this._initError = new ConfigurationErrorsException(SR.GetString("Config_client_config_init_error"));
    throw this._initError;
}

Since the 2nd would only handle a non-CLS exception, I'd guess that you're hitting the first one. If that's the case, you probably need to recursively go through InnerException to get the full details.

Mark Brackett
Interestingly in the meantime our support guys have removed and reinstalled .NET completely, and the app has started working. Perhaps that deleted machine.config and copied in a fresh one. Logically then it would make sense that this installation will stop working again at some point in the future, if some automated process is overwriting machine.config on their machines with something that .NET is taking exception to (no pun intended), that our app is hitting. Time will tell...
tomfanning
Oh, I've baked another build that grabs the next level of InnerException too if available, we'll see what that brings back on another of their machines in the morning...
tomfanning
@id.tomfanning.eu - I'd grab each InnerException until it's null, especially in a remote situation. No telling how many levels it goes down. Otherwise, you'll just be releasing daily builds just to get the bottom level fault.
Mark Brackett
Good catch, I'll keep this updated.
tomfanning
A: 

Just for anyone's future reference, I had this problem with a local app that I was developing on my desktop and found that the problem was simply that I had the case wrong in . Once that was fixed it worked like a charm again.

Jared
A: 

Solved this by overwriting machine.config with a known working copy from another machine at the same SP/patch level.

tomfanning
A: 

I had this exact same error occur when trying to open an OLE DB connection with ASP/VB.NET 3.5 SP1. If I add my URL to the list of trusted sites in IE, then the error goes away and the connection opens successfully. I don't know if this will fix things in other browsers.

I hope this helps!

Mike
Huh- what? Changing a setting on the client causes an exception to happen/not happen on the server?
tomfanning