J'ai une application Windows planifiée pour s'exécuter quotidiennement et échoue par intermittence à cause du journal suivant dans EventViewer.
Faulting application name: MyApplication.exe, version: 1.0.0.0, time stamp: 0x4d54829a
Faulting module name: clr.dll, version: 4.0.30319.1, time stamp: 0x4ba21eeb
Exception code: 0xc0000005
Fault offset: 0x00000000000029e1
Faulting process id: 0xbb1c
Faulting application start time: 0x01cbd99223d8b4eb
Faulting application path: E:\MyApplication\MyApplication.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Report Id: 7e74ec7e-45a5-11e0-a95d-003048de380d
Et dans le deuxième journal EventViewer, il est indiqué:
The process was terminated due to an internal error in the .NET Runtime at IP 000007FEF97329E1 (000007FEF9730000) with exit code 80131506.
Le serveur est Win Server 2008 R2 et l’application utilise .Net 4.0 (comme vous pouvez le voir également dans le journal des erreurs).
L'application utilise le multi-threading de manière intensive et lit à partir d'une base de données distante et écrit sur le disque dur local.
Vous avez une idée de la cause de ce problème et de l'aide pour enquêter? Je ne sais pas du tout où cela a échoué dans la vie de l'application, qui dure environ 5 à 10 heures.
J'ai le même problème. Au bout de 8 à 10 heures environ de la durée de vie de l'application, l'erreur CLR augmente. Je soupçonnais que mon code non géré générait une exception dans le thread d'arrière-plan. Cependant, je ne pouvais pas vraiment savoir pourquoi. Vous pouvez toutefois essayer ce qui suit:
S'il vous plaît laissez-moi savoir si vous avez déjà trouvé une solution.
J'ai eu un problème similaire, cela peut donc aider les futurs utilisateurs à trouver une solution:
Nous utilisons Apache log4net pour le journal des applications.
Après une mise à jour de DLL version 1.2.15, pour dotnet Framwork 4.5, cette exception exacte commence à se déclencher dès que le fichier journal atteint sa taille maximale (10 Mo).
Le correctif a pratiquement disparu et j'ai été confronté à un problème similaire. Je vais donc partager ma réponse ici.
Ma solution tournait autour du fait que je passais d'une Lamda à une P/Invoke: