15

I have a strange error on a specific Windows Server 2008 R2 machine (it works on other 2008 R2 machines) when starting a Windows Service. The service uses Common.Logging and log4net. However, on this specific machine the config section handler for Common.Logging can not be created.

It fails with the following stack traces (formatted for better readability). What surprises me most is the SecurityException. What can cause this?

Does anyone have a clue?

System.TypeInitializationException: The type initializer for
    'MyWindowsService.Program' threw an exception.
--->
Common.Logging.ConfigurationException: Failed obtaining configuration for
    Common.Logging from configuration section 'common/logging'.
--->
System.Configuration.ConfigurationErrorsException: An error occurred creating
    the configuration section handler for common/logging: Request failed.
    (C:\Path\MyWindowsService.exe.Config line 7)
--->
System.Security.SecurityException: Request failed.
at System.RuntimeTypeHandle.CreateInstance(
    RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached,
    RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis,
    Boolean fillCache)
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly,
    Boolean skipVisibilityChecks, Boolean skipCheckThis, Boolean fillCache)
at System.Activator.CreateInstance(Type type, Boolean nonPublic)
at System.Configuration.TypeUtil.CreateInstanceWithReflectionPermission(Type type)
at System.Configuration.RuntimeConfigurationRecord.RuntimeConfigurationFactory.Init(
    RuntimeConfigurationRecord configRecord, FactoryRecord factoryRecord)
at System.Configuration.RuntimeConfigurationRecord.RuntimeConfigurationFactory.InitWithRestrictedPermissions(
    RuntimeConfigurationRecord configRecord, FactoryRecord factoryRecord)
at System.Configuration.RuntimeConfigurationRecord.CreateSectionFactory(
    FactoryRecord factoryRecord)
at System.Configuration.BaseConfigurationRecord.FindAndEnsureFactoryRecord(
    String configKey, Boolean& isRootDeclaredHere)
--- End of inner exception stack trace ---

It continues with:

at System.Configuration.BaseConfigurationRecord.FindAndEnsureFactoryRecord(
    String configKey, Boolean& isRootDeclaredHere)
at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(
    String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject,
    Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
at System.Configuration.BaseConfigurationRecord.GetSection(String configKey)
at System.Configuration.ConfigurationManager.GetSection(String sectionName)
at Common.Logging.LogManager.<>c__DisplayClass6.<BuildLoggerFactoryAdapter>b__3()
at Common.Logging.Configuration.ArgUtils.<>c__DisplayClass13.<Guard>b__12()
at Common.Logging.Configuration.ArgUtils.Guard[T](Function`1 function,
    String messageFormat, Object[] args)
--- End of inner exception stack trace ---

at Common.Logging.Configuration.ArgUtils.Guard[T](Function`1 function,
    String messageFormat, Object[] args)
at Common.Logging.LogManager.BuildLoggerFactoryAdapter()
at Common.Logging.LogManager.get_Adapter()
at Common.Logging.LogManager.GetLogger(Type type)
at MyWindowsService.Program..cctor()
--- End of inner exception stack trace ---

at MyWindowsService.Program.Main(String[] args)

My configuration looks like this (the Common.Logging part of it anyway).

<configSections>
  <sectionGroup name="common">
    <section name="logging"
             type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
  </sectionGroup>
</configSections>

<common>
  <logging>
    <factoryAdapter
     type="Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter,Common.Logging.Log4net">
      <arg key="configType" value="INLINE" />
    </factoryAdapter>
  </logging>
</common>
Ronald Wildenberg
  • 31,634
  • 14
  • 90
  • 133

4 Answers4

18

I've seen strange things happening when customers downloaded our zip (ASP.NET application) file from our website. Because of the security feature "This file came from another computer and might be blocked to help protect this computer".

Unblocking the files solved all strange problems, this would explain why this is only happening on some computers with exactly the same configuration.


The Unblock option is shown only when the file is actually blocked in the General tab of the file properties dialog:

enter image description here

Flores
  • 8,226
  • 5
  • 49
  • 81
3

You might also check in Visual Studio 2013 if the Project > Properties > Application Tab > Startup Object dropdown is configured to point to the Program class of the windows service. If the value isn't set, the service will fail to start with System.TypeInitializationException.

Stamen
  • 595
  • 4
  • 7
1

Seems like you need to give permissions to the service account to access the config file.
EDIT: Actually on second glance it doesn't seem like that's the problem, because it's actually reading the config file, but you should double check the permissions anyways.

UPDATE: This is a known issue with .NET 4.0, but there is a workaround - see http://social.msdn.microsoft.com/Forums/en-US/clr/thread/1e14f665-10a3-426b-a75d-4e66354c5522.

Richard Anthony Hein
  • 10,550
  • 3
  • 42
  • 62
  • Is this .NET 4.0? There may be a bug in the framework ... see the accepted answer to http://stackoverflow.com/questions/2725432/net-4-0-application-on-network-share-causes-securityexception ... still wouldn't explain why it works on a different machine, unless you are getting this only when debugging remotely? Well, I guess you aren't since you say it happens when you start the service. – Richard Anthony Hein Aug 10 '10 at 18:54
  • See http://social.msdn.microsoft.com/Forums/en-US/clr/thread/1e14f665-10a3-426b-a75d-4e66354c5522 ... this is a known issue with .NET 4.0 – Richard Anthony Hein Aug 10 '10 at 18:59
  • Ah, hadn't found this myself. Thanks. The problem occurred on a customer test environment so it was becoming a bit of an issue. – Ronald Wildenberg Aug 11 '10 at 09:03
  • This doesn't appear to be the same problem. After running the proposed work-around the problem still exists. Do you have any other ideas? – Ronald Wildenberg Aug 11 '10 at 14:52
0

Turned out for me to be because I was running the executable from a network mapped drive which .NET considers unsecure

Simon L
  • 31
  • 3