Sometimes you might need to debug a windows service which is written in managed code and it is running on 64-bit windows, and to make the matter worse, the bug happens during the service startup. Without adding instrument codes into your binary, this could be a difficult setup to do debugging, because: 1.
Services Control Manager must start the service with the debugger attached.
2.
Starting from Windows Vista/2008, all windows services are running under a separated session 0 (which has a different WindowStations/Desktop than the normal user interactive desktop).
3.
The visual studio debugger cannot be attached in mixed mode (both native and managed) if the code is written prior to .NET 4.0One solution for this problem is to use WinDBG debugger with SOS extension, and configure the “Image File Execution” options to start the service under debugger server automatically. The following case study demonstrates this technique. The Bug:ManagedService is a winidows service, its binary managedservice.exe is implemented using C#. The following error occurs when ManagedService is trying to start:C:\Users\administrator>net start ManagedService
The ManagedService service is starting...
The ManagedService service could not be started.A system error has occurred.System error 1067 has occurred.The process terminated unexpectedly. In Event Viewer (Windows Logs/Application), the actual CLR exception and call stack are recorded: System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
at System.Reflection.Module._GetTypesInternal(StackCrawlMark& stackMark)
at System.Reflection.Assembly.GetTypes()
at MyCompany.MyProduct.IndigoSerializableObject.InitializeKnownTypesCache(List`1 assembliesToExamine)
at MyCompany.MyProduct.ManagedService.OnStart(String[] args) This gives a better insight to the problem: This service was probably going to host some WCF services and maybe it was preloading some managed types to improve performance, and the CLR loader encountered an error while loading them. However, assuming there are quite few assemblies and each has a few types, this information alone is not enough to tell which exact type causes the error. What is really needed is the content of LoaderExceptions property so that we can pinpoint the guilty type. Note: Fusion Log won’t help in this case, because it is a type loading exception not an assembly loading exception.Read more: Brandon's Blog
Services Control Manager must start the service with the debugger attached.
2.
Starting from Windows Vista/2008, all windows services are running under a separated session 0 (which has a different WindowStations/Desktop than the normal user interactive desktop).
3.
The visual studio debugger cannot be attached in mixed mode (both native and managed) if the code is written prior to .NET 4.0One solution for this problem is to use WinDBG debugger with SOS extension, and configure the “Image File Execution” options to start the service under debugger server automatically. The following case study demonstrates this technique. The Bug:ManagedService is a winidows service, its binary managedservice.exe is implemented using C#. The following error occurs when ManagedService is trying to start:C:\Users\administrator>net start ManagedService
The ManagedService service is starting...
The ManagedService service could not be started.A system error has occurred.System error 1067 has occurred.The process terminated unexpectedly. In Event Viewer (Windows Logs/Application), the actual CLR exception and call stack are recorded: System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
at System.Reflection.Module._GetTypesInternal(StackCrawlMark& stackMark)
at System.Reflection.Assembly.GetTypes()
at MyCompany.MyProduct.IndigoSerializableObject.InitializeKnownTypesCache(List`1 assembliesToExamine)
at MyCompany.MyProduct.ManagedService.OnStart(String[] args) This gives a better insight to the problem: This service was probably going to host some WCF services and maybe it was preloading some managed types to improve performance, and the CLR loader encountered an error while loading them. However, assuming there are quite few assemblies and each has a few types, this information alone is not enough to tell which exact type causes the error. What is really needed is the content of LoaderExceptions property so that we can pinpoint the guilty type. Note: Fusion Log won’t help in this case, because it is a type loading exception not an assembly loading exception.Read more: Brandon's Blog