Home Dashboard Directory Help
Search

System.Configuration.ConfigurationErrorsException: Unrecognized configuration section system.serviceModel. (c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Config\machine.config line 146) by hognala


Status: 

Closed
 as Not Reproducible Help for as Not Reproducible


13
0
Sign in
to vote
Type: Bug
ID: 510186
Opened: 11/12/2009 2:45:30 PM
Access Restriction: Public
2
Workaround(s)
view
11
User(s) can reproduce this bug

Description

Our Windows Service (.NET 2.0 SP2 based) is getting this exception once .NET 3.5 SP1 is installed. It adds a system.serviceModel tag to the machine.config without adding the config sections that define the tag.

System.Configuration.ConfigurationErrorsException: Unrecognized configuration section system.serviceModel. (c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Config\machine.config line 146)

We are seeing this on a German system in the UK.

Attached the machine.config file to this issue. XP SP3.
Details
Sign in to post a comment.
Posted by mehrtash.souri on 5/20/2014 at 8:18 AM
i delete System.serviceModel section in the webconfig
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG

god bless you pisambert . it takes 1 day. to understand problem.
Posted by Johnny from CBS on 6/22/2012 at 1:11 PM
you need to add <configSections></configSections> in your app.config to point to your own configuration node like this:
<configuration>
<configSections>    
    <section name="ActiveMqProviders" type="ActiveMQHelper.AMQProviderConfigurationSection, ActiveMQHelper"/>
</configSections>
<ActiveMqProviders DefaultProvider="AMQProviderETL.SIT">
    <Providers>
     <add name="AMQProviderETL.DIT"
         type="ActiveMQHelper.AMQProvider, ActiveMQHelper"
         description="ActiveMQ Provider for OWB services"
         brokerUri="activemq:tcp://dit26w104m7:61616?wireFormat.maxInactivityDuration=0"
         userName=""
         password=""
         disabled="true"
         clientId="REIService.ETL"
         messageGroupId="REI.ETL"
         topic=""
         requestTimeout="1:00"
         requestQueue="OpsEtlRequestQueue"
         responseQueue="OpsEtlResponseQueue"
         exceptionQueue=""/>    
    </Providers>
</ActiveMqProviders>
</configuration>
Posted by HKSADFDDMXCMNZXC34 on 5/22/2012 at 12:19 PM
Another here, a WSS installation got stopped because this error manifested itself after running windows update. Using both workarounds fixed the problem.
Posted by pisambert on 1/2/2012 at 6:20 AM
Same problem here

As a workaround I dropped the System.serviceModel section in the machine.config.

seems to work OK

Patrick
Posted by SamBlackjack on 12/20/2010 at 11:56 AM
We're having the same issue on a Windows 2003 virtual server. It started after the latest patching was done. I compared the machine.config on the "bad" server to a good server and the differences are the System.serviceModel sections. I then copied the machine.config file from the good server to the bad server as suggested in the workaround and rebooted the server. However, the server went into a restart loop.
Posted by keef_riff_hard on 12/20/2010 at 11:28 AM
I had an XP Professional Version 2002 PC that was giving me similar CLR errors on Applications developed in VS 2005 using .NET 2.0
(2 separate applications gave me such errors - actually each was a little different - but both deep nasty CLR)

To resolve I did the following
1) Uninstalled .NET 3.5 SP1
2) Uninstalled .NET 2.0 SP2
3) Uninstalled .NET 2.0

note: Have to do it in that order (newest to oldest - since 3.5 is wrapper dependent on 2.0)

Then I installed
4) .NET 2.0 (and then tested my apps - yes they worked now!!!)
5) .NET 2.0 SP2 (and then tested my apps - yes still worked !!)
6) .NET 3.5 SP1 (and then tested my apps - yes still worked !!)


My best guess then is the problem occurs on such PCs when .NET 3.5 SP1 is installed and it installs .NET 2.0
Posted by Barry Peacock on 11/8/2010 at 10:35 AM
I had the same issue on one machine. It took both workarounds to fix.
Posted by Jim Black - November on 3/11/2010 at 6:16 PM
We have a large customer who had done some upgrades and then reported that our application stopped working. Our application uses ADO.NET to open a ODBC database connection with .NET 2.0. The customer's machine is XP SP2.    Our software reported the following detailed error message:

System.Configuration.ConfigurationErrorsException
Unrecognized configuration section system.serviceModel.
(C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Config\machine.config line 146)

Traceback is :
at System.Transactions.Transaction.get_Current()
at System.Data.Common.ADP.IsSysTxEqualSysEsTransaction()
at System.Data.Common.ADP.NeedManualEnlistment()
at System.Data.OleDb.OleDbConnection.Open()

This looks very similar to what is being discussed on this thread.    We, too, need some way of detecting this problem and fixing it automatically in our code.    This p
Posted by Microsoft on 1/28/2010 at 9:38 AM
We have continued to investigate this issue, but are still not able to track down the root cause. Greg: I assure you, we tried the exact steps you mentioned in our lab and have not been able to reproduce the problem. In fact, we test that explicit scenario (upgrade from .NET 2.0 to 3.5 SP1) in automation, so we're not sure what the difference is between our lab setup and your customer's environment.

-- Dave, WCF Team
Posted by Microsoft on 1/28/2010 at 9:37 AM
We have continued to investigate this issue, but are still not able to track down the root cause. Greg: I assure you, we tried the exact steps you mentioned in our lab and have not been able to reproduce the problem. In fact, we test that explicit scenario (upgrade from .NET 2.0 to 3.5 SP1) in automation, so we're not sure what the difference is between our lab setup and your customer's environment.

As a workaround, since uninstall/repair and running ServiceModelReg.exe explicitly don't work, you can either remove the offending <system.servicemodel> section from machine.config and re-run the repair, or simply replace the entire file with a well-known "good" configuration file.
Regarding the other workaround presented, .NET 3.5 SP1 installation does not take a dependency on Visual Studio, so it is not required that Microsoft.VisualStudio.Diagnostics.ServiceModelSink.Behavior be present in the extensions collection. Can you give me more information about what is already previously installed on the machine (since it's not a clean install)? What version of VS is installed?

-- Dave, WCF Team
Posted by hognala on 1/25/2010 at 4:13 PM
Finally got the vslogs.cab file from my customer, attached.
Posted by NicWise on 1/19/2010 at 3:01 AM
I am having this issue also. I'm trying to get more info from the client, however:

Clean .NET 3.5 SP1 install.
.NET 2.0 targetted app
No WCF used at all
Danish language version of .net

We are about to try the workaround.
Posted by gcadmes on 1/6/2010 at 10:58 AM
My dissatisfaction is related to the inability for an msdn member to ‘re-open’ a Connect ID Item with some steps to reproduce.

This connect item has been deemed ‘Resolved as Not Reproducible’, yet I didn’t see any steps to reproduce provided by the msdn member or tried by Microsoft’s connect team. How can we be sure that this item was actually researched and tested? IMHO, I think it would be beneficial to have a feature on this Connect site that provided the actual steps used by M$ to reproduce this issue. In doing so would give other members who visit this Connect item some idea’s that might not have otherwise been thought of. My $0.02 feature request.

At any rate, I’d like this item to be re-opened and for the following steps to be applied for testing:
1.    Format and install a clean installation of XP, with SP3 applied.
2.    Save a copy of the uncorrupted machine.config file to a different location for later viewing.
3.    Install or re-install .NET Framework 3.5, with SP1 applied
4.    Compare the two machine.config files and notice the minor difference in the ServiceModel xml element.

Note: ServiceModelReg.exe should not be executed while applying the steps provided.

Greg
Posted by gcadmes on 1/6/2010 at 10:29 AM
Although I provided a practical work-a-round for this issue, I'm still puzzled as to why installing fx 3.5 SP1 fails to update the machine.config’s ServiceModel element properly.

Does anyone at Micro$oft have any idea if the installer process could be causing this, or some other oddity with regard to installing 3.5 SP1?

Thanks much

Greg
Posted by Microsoft on 12/20/2009 at 11:34 PM
Hmmm ... sorry, I don't know how your machine.config can get in that state as we haven't been able to reproduce the problem locally. Since it's a 2.0 SP2 app that doesn't require WCF, you can remove the System.ServiceModel sections altogether and your app should run just fine. ServiceModelReg.exe -u should do that. Can you try that?

Question: are you seeing this same machine.config corruption issue on different machines also? Or is this a one-off case?

-- Dave, WCF Team
Posted by hognala on 12/18/2009 at 3:06 PM
I tried repairing .NET 3.5 SP1, that didn't solve the problem. I tried running ServiceModelReg.exe -i, that didn't work and gave the following error:

! ServiceModelReg.exe -i
Microsoft(R) Windows Communication Foundation Installation Utility
[Microsoft (R) Windows (R) Communication Foundation, Version 3.0.4506.2152]
Copyright (c) Microsoft Corporation. All rights reserved.


Error: Configuration system failed to initialize


How to move forward?

I really need a reliable way to repair the machine.config file.
Posted by Microsoft on 12/14/2009 at 9:47 AM
I'm not aware of anything, but there may be something in the System.Configuration namespace that might help. In the worst case, you can just write a simple app that tries to load config and catches any ConfigurationExceptions that might arise before invoking ServiceModelReg.exe.

-- Dave, WCF Team
Posted by hognala on 12/7/2009 at 10:09 AM
How can I detect that the machine.config file is in a bad state? I.e. is there a schema that I can check against the machine.config file to see if the file is corrupt?

I want to put together an automated "fixer" that detects the problem, then runs ServiceModelReg.exe -i

Posted by Microsoft on 12/3/2009 at 3:45 PM
Thanks for reporting this issue. Here are a couple of workarounds to try:
1) Repair the .NET Framework 3.5 SP1 after it has been installed.
Or, 2) Run ServiceModelReg.exe -i to make sure that machine.config is properly setup. You can find that here: http://msdn.microsoft.com/en-us/library/ms732012.aspx

We will continue to investigate the root cause of this issue and how we can address it going forward. Thanks,

-- Dave, WCF Team
Posted by Microsoft on 12/3/2009 at 3:45 PM
Thanks for reporting this issue. Here are a couple of workarounds to try:
1) Repair the .NET Framework 3.5 SP1 after it has been installed.
Or, 2) Run ServiceModelReg.exe -i to make sure that machine.config is properly setup. You can find that here: http://msdn.microsoft.com/en-us/library/ms732012.aspx

We will continue to investigate the root cause of this issue and how we can address it going forward. Thanks,

-- Dave, WCF Team
Posted by Microsoft on 12/3/2009 at 3:12 AM
Thanks for your feedback.

We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution.
These specialized experts will follow-up with your issue.
Posted by hognala on 12/2/2009 at 2:54 PM
The customer took a while to respond.

I believe that .NET 2.0 SP2 was installed by .NET 3.5SP1 in this case.
Posted by Microsoft on 11/22/2009 at 7:37 PM
Hi, given that we have not heard back from you in 7 days, we will go ahead and close this Connect Issue. If you get a chance to review and provide the information requested earlier, you can go ahead and reactivate this issue.
Posted by Microsoft on 11/20/2009 at 12:09 PM
Thanks for reporting this issue. Can you provide the exact configuration of the machine before you ran the .Net 3.5SP1 setup? You mention that the machine has .Net2.0 SP2 but that gets installed by the 3.5SP1 setup (they are packaged together). We need to know the oriiinal machine configuration to reproduce the problem locally.

Thanks,
-Asad
WCF Team
Posted by Microsoft on 11/15/2009 at 7:31 PM
Thanks for reporting the issue.
In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided.

Could you please upload a setup log file to help us investigate the issue?
You can get the log files with the following steps:
1) Download collect.exe from the link below. http://go.microsoft.com/?LinkId=8967043
2) You may choose to save the tool for later use, or to run directly.
3) The utility creates a compressed cabinet of all the VS and .NET logs to %TEMP%\vslogs.cab.

You can get more details about how to get the log files here:
http://blogs.msdn.com/heaths/archive/2009/05/22/updated-log-collection-utility-available-for-visual-studio-2010-and-net-4-0-beta-1.aspx

Thanks again for your efforts and we look forward to hearing from you.
Visual Studio Product Team
Posted by Microsoft on 11/13/2009 at 4:41 AM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
Posted by Richard Meyer on 4/6/2010 at 10:22 AM
I have several systems that are experiencing this as well, but I have found that after teh upgrade there is a section missing from the <configSections>.
I have added these lines to the end of the this section Just after the <section name="system.webServer"... entry and it seems to be working at least in our environment.

<sectionGroup name="system.serviceModel" type="System.ServiceModel.Configuration.ServiceModelSectionGroup, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
     <section name="behaviors" type="System.ServiceModel.Configuration.BehaviorsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
     <section name="bindings" type="System.ServiceModel.Configuration.BindingsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
     <section name="client" type="System.ServiceModel.Configuration.ClientSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
     <section name="comContracts" type="System.ServiceModel.Configuration.ComContractsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
     <section name="commonBehaviors" type="System.ServiceModel.Configuration.CommonBehaviorsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowDefinition="MachineOnly" allowExeDefinition="MachineOnly"/>
     <section name="diagnostics" type="System.ServiceModel.Configuration.DiagnosticSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
     <section name="extensions" type="System.ServiceModel.Configuration.ExtensionsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
     <section name="machineSettings" type="System.ServiceModel.Configuration.MachineSettingsSection, SMDiagnostics, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowDefinition="MachineOnly" allowExeDefinition="MachineOnly"/>
     <section name="serviceHostingEnvironment" type="System.ServiceModel.Configuration.ServiceHostingEnvironmentSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
     <section name="services" type="System.ServiceModel.Configuration.ServicesSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
    </sectionGroup>
    <sectionGroup name="system.serviceModel.activation" type="System.ServiceModel.Activation.Configuration.ServiceModelActivationSectionGroup, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
     <section name="diagnostics" type="System.ServiceModel.Activation.Configuration.DiagnosticSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
     <section name="net.pipe" type="System.ServiceModel.Activation.Configuration.NetPipeSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
     <section name="net.tcp" type="System.ServiceModel.Activation.Configuration.NetTcpSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
    </sectionGroup>
Posted by gcadmes on 12/30/2009 at 4:13 PM
I hope I’m not presumptuous, but I think I may have discovered a work around for this particularly odd exception; at least it works for the apps at my company.

Inside the machine.config file; within the system.serviceModel\extensions\behaviorExtensions\, there should be at least be a minimum of 5 elements. The order in which they appear does not matter. It was my experience that the last <add> listed below was missing from my machine.config file with FX 3.5 SP1 installed.

<behaviorExtensions>
<add
name="persistenceProvider" type="System.ServiceModel.Configuration.PersistenceProviderElement, System.WorkflowServices, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add
name="workflowRuntime" type="System.ServiceModel.Configuration.WorkflowRuntimeElement, System.WorkflowServices, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    <add
name="enableWebScript" type="System.ServiceModel.Configuration.WebScriptEnablingElement, System.ServiceModel.Web, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add
name="webHttp" type="System.ServiceModel.Configuration.WebHttpElement, System.ServiceModel.Web, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    <add
name="Microsoft.VisualStudio.Diagnostics.ServiceModelSink.Behavior" type="Microsoft.VisualStudio.Diagnostics.ServiceModelSink.Behavior, Microsoft.VisualStudio.Diagnostics.ServiceModelSink, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
</behaviorExtensions>


Hope this helps!
If this did not help, please let me know.

Cheers,

Greg Cadmes
gcadmes@extron.com
Extron Electronics