Catastrophic Failure, GetLocationEvidence, winform startup with arguments

[EDN Admin]

We are running a Winform VB.net application with command line arguments via an automation system so we can run scheduled maintenance jobs, etc., it has worked perfectly for years.
On a few select jobs, over the past few days, we have noticed a few jobs failing, with the following exception info:
<pre>
<ExceptionInformation><AdditionalInformationProperty MachineName="*removed from post*" TimeStamp="12/29/2011 2:15:22 PM" FullName="*removed from post*, Version=4.0.0.0, Culture=neutral, PublicKeyToken=f1ffc79106150be8" AppDomainName="ARS2.exe" ThreadIdentity="" WindowsIdentity="*removed from post*" /><Exception ExceptionType="System.Runtime.InteropServices.COMException" ErrorCode="-2147418113" Message="Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))" Data="System.Collections.ListDictionaryInternal" TargetSite="Void GetLocationEvidence(Microsoft.Win32.SafeHandles.SafePEFileHandle, System.Security.SecurityZone ByRef, System.Runtime.CompilerServices.StringHandleOnStack)" Source="mscorlib <StackTrace> at System.Security.Policy.PEFileEvidenceFactory.GetLocationEvidence(SafePEFileHandle peFile, SecurityZone&amp; zone, StringHandleOnStack retUrl)
at System.Security.Policy.PEFileEvidenceFactory.GenerateLocationEvidence()
at System.Security.Policy.PEFileEvidenceFactory.GenerateEvidence(Type evidenceType)
at System.Security.Policy.AssemblyEvidenceFactory.GenerateEvidence(Type evidenceType)
at System.Security.Policy.Evidence.GetHostEvidenceNoLock(Type type)
at System.Security.Policy.Evidence.GetHostEvidence(Type type, Boolean markDelayEvaluatedEvidenceUsed)
at System.Security.Policy.AppDomainEvidenceFactory.GenerateEvidence(Type evidenceType)
at System.Security.Policy.Evidence.GetHostEvidenceNoLock(Type type)
at System.Security.Policy.Evidence.RawEvidenceEnumerator.MoveNext()
at System.Security.Policy.Evidence.EvidenceEnumerator.MoveNext()
at System.Configuration.ClientConfigPaths.GetEvidenceInfo(AppDomain appDomain, String exePath, String&amp; typeName)
at System.Configuration.ClientConfigPaths.GetTypeAndHashSuffix(AppDomain appDomain, String exePath)
at System.Configuration.ClientConfigPaths..ctor(String exePath, Boolean includeUserConfig)
at System.Configuration.ClientConfigPaths.GetPaths(String exePath, Boolean includeUserConfig)
at System.Configuration.Internal.ConfigurationManagerInternal.System.Configuration.Internal.IConfigurationManagerInternal.get_ExeProductName()
at System.Configuration.ApplicationSettingsBase.get_Initializer()
at System.Configuration.ApplicationSettingsBase.CreateSetting(PropertyInfo propInfo)
at System.Configuration.ApplicationSettingsBase.EnsureInitialized()
at System.Configuration.ApplicationSettingsBase.get_Properties()
at System.Configuration.SettingsBase.SetPropertyValueByName(String propertyName, Object propertyValue)
at System.Configuration.SettingsBase.set_Item(String propertyName, Object value)
at System.Configuration.ApplicationSettingsBase.set_Item(String propertyName, Object value)
at *removed from post*.My.MySettings.set_CurrentDbConnectionFriendlyName(String Value)
at *removed from post*.CommandLineHandler.Process()</StackTrace></Exception></ExceptionInformation>

[/code]
<br/>
Checked out a lot of posts about catastrophic failures, seems pretty unrelated to what we are experiencing.
I do not believe the automation system is the issue, it is doing really simple stuff, I believe we may have changed a build setting or configuration perhaps, but Im not seeing anything that has changed and can use some guidance...

View the full article