App crash when profiling console application

slaneyrw

I'm getting the following exception when I profile a console application.

I don't get this when running without the profiler or if I use Model-level timings.

Version : 4.1.0.45
Windows Server 2008, x64
.NET 3.5 SP1

Line that fails :

ExeConfigurationFileMap map = new ExeConfigurationFileMap() { ExeConfigFilename = unityFilePath };

The file being opening in question is a configuration file from the Unity 1.2 application block.

== Exception ==
System.Configuration.ConfigurationErrorsException was unhandled
Message="An error occurred creating the configuration section handler for unity: Exception has been thrown by the target of an invocation."
Source="System.Configuration"
BareMessage="An error occurred creating the configuration section handler for unity: Exception has been thrown by the target of an invocation."
Line=0
StackTrace:
at System.Configuration.BaseConfigurationRecord.CallCreateSection(Boolean inputIsTrusted, FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentConfig, ConfigXmlReader reader, String filename, Int32 line)
at System.Configuration.BaseConfigurationRecord.CreateSectionDefault(String configKey, Boolean getRuntimeObject, FactoryRecord factoryRecord, SectionRecord sectionRecord, Object& result, Object& resultRuntimeObject)
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, Boolean getLkg, Boolean checkPermission)
at System.Configuration.Configuration.GetSection(String sectionName)
at SEEK.SalaryCentre.Unity.EnsureDefaults() in \SourceCode\SalaryCentre\SalaryCentre\Mainline-DEV-SCE\Components\SEEK.SalaryCentre\Framework\Unity.cs:line 191
at SEEK.SalaryCentre.Unity.get_DefaultContainer() in \SourceCode\SalaryCentre\SalaryCentre\Mainline-DEV-SCE\Components\SEEK.SalaryCentre\Framework\Unity.cs:line 36
at SEEK.SalaryCentre.Business.SurveyValidator.LoadReferenceData() in \SourceCode\SalaryCentre\SalaryCentre\Mainline-DEV-SCE\Components\SEEK.SalaryCentre\Business\Survey\SurveyValidator.cs:line 811
at SEEK.SalaryDataTransfer.SalaryDataTransfer.LetsProcessGo() in \SourceCode\SalaryCentre\SalaryCentre\Mainline-DEV-SCE\Apps\SalaryDataTransfer\SalaryDataTransfer.cs:line 31
at SEEK.SalaryDataTransfer.Program.Main(String[] args) in \SourceCode\SalaryCentre\SalaryCentre\Mainline-DEV-SCE\Apps\SalaryDataTransfer\Program.cs:line 9
InnerException: System.Reflection.TargetInvocationException
Message="Exception has been thrown by the target of an invocation."
Source="mscorlib"
StackTrace:
at System.RuntimeMethodHandle._InvokeConstructor(Object[] args, SignatureStruct& signature, IntPtr declaringType)
at System.RuntimeMethodHandle.InvokeConstructor(Object[] args, SignatureStruct signature, RuntimeTypeHandle declaringType)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.ConstructorInfo.Invoke(Object[] parameters)
at System.Configuration.TypeUtil.InvokeCtorWithReflectionPermission(ConstructorInfo ctor)
at System.Configuration.MgmtConfigurationRecord.CreateSection(Boolean inputIsTrusted, FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentConfig, ConfigXmlReader reader)
at System.Configuration.BaseConfigurationRecord.CallCreateSection(Boolean inputIsTrusted, FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentConfig, ConfigXmlReader reader, String filename, Int32 line)
InnerException: System.TypeLoadException
Message="Bad unmanaged code entry point."
Source="Microsoft.Practices.Unity.Configuration"
TypeName="<Module>"
StackTrace:
at Microsoft.Practices.Unity.Configuration.UnityConfigurationSection..ctor()
InnerException:

Brian Donahue

Hi Robert,

It looks like your program is using Platform Invoke to get a struct from an unmanaged dll and cast it as a managed type. ANTS Profiler is causing this to fail when using line-level timings, so I'd suspect that the IL rewriting must be interfering with this, but I don't know enough about it to say exactly how or why. The fact that the application is 64-bit aligned may have something to do with it, moreso if the EntryPoint in question is an ordinal, I think.

I'll pass this information on to the development team and see if there is an answer. In the meantime, you should already have got a support ticket reference number from us via email, so we will be getting to the bottom of this for you.

slaneyrw

Hi Brian,

Just got back from xmas break so catching up on posts. Thanks for escalating the issue.

Extra information if needed :

System used patterns and practices' Unity application block v 1.2. This internally uses ObjectBuilder2 which emits in-memory IL to cache the dynamic creation of objects.

If you need sample code / config let me know.

Cheers...

Robert

Brian Donahue

Hi Robert,

From what I've been told, the issue could be that generated code is being added to an existing assembly. Typically, code generation would apply to new assemblies only, so this problem hasn't come up before.

I do not know yet if this is feasible to fix, but it may impossible for you to use line-level timings if this is the case. You can get more data if you disable line-level timings only for the offending assembly. You can do that by deleting the assembly's PDB file so that ANTS Profiler will not be able to identify individual lines of code.

slaneyrw

Hi all,

This is still causing us issues and whilst removing the PDB removes the problem, I don't think this is a solution long term. I need to remove the PDBs manually as visual studio will keep putting it in the bin folder.

Can we maybe have the ability to specify namespaces or assemblies to exclude when running with maximum detail

Brian Donahue

Hi,

You could stop Visual Studio from making PDBs by going into the project properties and turning off the "generate debugging information" setting. This is not ideal either, but probably easier than a "search and destroy" operation on all of the PDBs.