2015-02-24 10 views
13

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.

+1

Jacco: hai avuto fortuna a inchiodarlo? Stiamo avendo lo stesso problema, ma con un servizio di Windows. – YtramX

+0

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

+0

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

risposta

7

Ho pensato di pubblicare una soluzione, che abbiamo trovato a questo problema, perché abbiamo iniziato a riscontrare il problema di recente.

Abbiamo molti server che eseguono il nostro codice, ma solo 1 si è verificato un arresto anomalo un paio di volte alla settimana con questo errore. Credo che questo server fosse su .net 4.5.2.

Abbiamo aperto un ticket con Microsoft poiché l'eccezione non gestita si stava verificando nel loro stack.

Hanno guardato la discarica e sono tornati con questa soluzione che ha funzionato.

Una nuova correzione è disponibile presso https://support.microsoft.com/en-us/kb/3139544

Sarebbe meglio se si sposta NET 4.6.1

Spero che questa soluzione aiuterà chiunque altro che trova se stessi leggendo questo .

+1

+1 perché sembra esattamente il problema che ho riscontrato. 1-3 si schianta al giorno, come descritto - questo ha avuto inizio solo dopo l'installazione di .NET 4.5.2 e durante i periodi di carico più intenso. I nodi con arresto anomalo 4.5.2 intermittenza, i nodi senza esso vanno bene. Dopo una chiamata con MS, esito simile - problema noto, la raccomandazione era di aggiornare a 4.6.x. – AdaTheDev

0

Difficile dire se non si vede alcun codice Linq ma vorrei azzardare un'ipotesi che sia un errore interno (di trasmissione) con la libreria linq che si sta utilizzando.

Come lei ha ricordato che è stato aggiornato di recente
(quale versione di .NET hai l'aggiornamento da e per?)

ho avuto problema simile che è stato risolto con l'installazione di aggiornamenti di Windows, di cui dite che avete fatto con un po ' successo risultante?

Cercare di identificare gli input utente che causano errori. Prova a gestire tu stesso il casting piuttosto che affidarti a Linq