Da qualche settimana si verificano arresti anomali di W3WP con la nostra applicazione Web ASP.Net. Sono iniziati dopo l'aggiornamento dei nostri server web. La nostra applicazione non è cambiata ed è rimasta stabile per anni.
La nostra situazione sembra molto simile a this earlier question. E this question potrebbe anche essere correlato, anche se nel nostro caso le query funzionano bene nel 99,9% dei tempi utilizzati.LINQ to SQL: AccessViolationException intermittente incluso in TargetInvocationException
Utilizziamo molte query LINQ non compilate e abbiamo provato se la loro compilazione avrebbe impedito questi arresti anomali. Il numero di arresti anomali è diminuito drasticamente, ma si verificano ancora.
Anche il wrapping delle query in un try catch
e il rilevamento dello TargetInvocationException
non funziona. L'eccezione non viene catturata.
Quando si verifica un arresto anomalo, otteniamo un rapporto WER e possiamo recuperare un dump di arresto anomalo.
Una traccia di stack da una discarica per una query non compilato appare in genere in questo modo:
a System.RuntimeMethodHandle.InvokeMethod (target oggetto, oggetto [] argomenti, Signature, in ordine a costruttore booleano)
a System.Reflection .RuntimeMethodInfo.UnsafeInvokeInternal (obj Object, Object [] parametri, Object [] argomenti)
a System.Delegate.DynamicInvokeImpl (Object [] args)
a System.Data.Linq.SqlClient.QueryConverter.VisitInvocation (InvocationExpression invoke)
a System.Data.Linq.SqlClient.QueryConverter.VisitInner (Espressione nod e)
a System.Data.Linq.SqlClient.QueryConverter.VisitExpression (Expression exp)
a System.Data.Linq.SqlClient.QueryConverter.VisitBinary (BinaryExpression b)
a System.Data.Linq.SqlClient.QueryConverter .VisitInner (nodo Expression)
a System.Data.Linq.SqlClient.QueryConverter.VisitExpression (Expression exp)
a System.Data.Linq.SqlClient.QueryConverter.VisitBinary (BinaryExpression b)
a System.Data.Linq .SqlClient.QueryConverter.VisitInner (nodo Expression)
in System.Data.Linq.SqlClient.QueryConverter.Visit (nodo Expression)
a System.Data.Linq.SqlClient.QueryConverter.VisitWhere (sequenza Expression, LambdaExpression predicato)
a System.Data.Linq.SqlClient.QueryConverter.VisitSequenceOperatorCall (MethodCallExpression mc)
a System.Data.Linq.SqlClient.QueryConverter .VisitInner (nodo Expression)
a System.Data.Linq.SqlClient.QueryConverter.VisitWhere (sequenza Expression, LambdaExpression predicato)
a System.Data.Linq.SqlClient.QueryConverter.VisitSequenceOperatorCall (MethodCallExpression mc)
al sistema. Data.Linq.SqlClient.QueryConverter.VisitInner (nodo Expression)
a System.Data.Linq.SqlClient.QueryConverter.VisitSelect (espressione seque SNO, selettore LambdaExpression)
a System.Data.Linq.SqlClient.QueryConverter.VisitSequenceOperatorCall (MethodCallExpression mc)
a System.Data.Linq.SqlClient.QueryConverter.VisitInner (nodo Expression)
a System.Data.Linq. SqlClient.QueryConverter.VisitDistinct (sequenza di espressioni)
in System.Data.Linq.SqlClient.QueryConverter.VisitSequenceOperatorCall (MethodCallExpression mc)
a System.Data.Linq.SqlClient.QueryConverter.VisitInner (nodo Expression)
a System.Data.Linq.SqlClient.QueryConverter.ConvertOuter (nodo Expression)
a System.Data.Linq. SqlClient.SqlProvider.BuildQuery (query Espressione, SqlNodeAnnotations annotazioni)
a System.Data.Linq.SqlClient.SqlProvider.System.Data.Linq.Provider.IProvider.Execute (query Expression)
a System.Data.Linq.DataQuery '1.System.Collections.Generic.IEnumerable.GetEnumerator()
a System.Linq.Buffer'1..ctor (origine IEnumerable'1)
a System.Linq.Enumerable.To Array [TSource] (IEnumerable'1 fonte)
L'analisi dello stack da una discarica per una query compilato assomiglia:
a System.RuntimeMethodHandle.InvokeMethod (System.Object, System.Object [ ], System.Signature, booleano)
a System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal (System.Object, System.Object [], System.Object [])
a System.Delegate.DynamicInvokeImpl (System.Object [])
a System.Data.Linq.SqlClient.SqlProvider.AssignParameters (System.Data.Common.DbCommand, Syst em.Collections.ObjectModel.ReadOnlyCollection`1, System.Object [], System.Object)
a System.Data.Linq.SqlClient.SqlProvider.Execute (System.Linq.Expressions.Expression, QueryInfo, System.Data.Linq .SqlClient.IObjectReaderFactory, System.Object [], System.Object [], System.Data.Linq.SqlClient.ICompiledSubQuery [], System.Object)
a System.Data.Linq.SqlClient.SqlProvider.ExecuteAll (Sistema. Linq.Expressions.Expression, QueryInfo [], System.Data.Linq.SqlClient.IObjectReaderFactory, System.Object [], System.Data.Linq.SqlClient.ICompiledSubQuery [])
a System.Data.Linq.SqlClient.SqlProvider + CompiledQuery.Execute (System.Data.Linq.Provider.IProvider, System.Object [])
a System.Data.Linq.CompiledQuery.ExecuteQuery (System.Data.Linq.DataContext, System.Object [])
Qualcuno sa cosa potrebbe aver cambiato il comportamento della nostra applicazione? Sappiamo che era "un aggiornamento" (ma non esattamente quale), ma siamo più interessati al suo background tecnico.
Ovviamente, accogliamo con favore anche una soluzione per evitare che la nostra applicazione si arresti.
Jacco: hai avuto fortuna a inchiodarlo? Stiamo avendo lo stesso problema, ma con un servizio di Windows. – YtramX
No, non abbiamo trovato il KB esatto. Stiamo riducendo il numero di arresti anomali e ci auguriamo che MS risolva questo problema in un altro KB. – Jacco
Stiamo riscontrando lo stesso problema con un servizio Windows. Abbiamo appena convertito da x32 a x64, non sono sicuro se questo è collegato a tutti. – jhilden