CLR Exceptions debuggen

[PdeBie]

Heren developers,

wij hebben met 'Process explorer' van Microsoft ontdekt dat onze applicatie zo af en toe een CLR error uitspuugt. Om te ontdekken wat er fout gaat, wilden we dit gaan debuggen in VS2010.

Hiervoor heb ik in het menu 'Debug > Exceptions' de vinkjes 'Thrown' bij CLR Exceptions ingeschakeld. Maar de applicatie vangt geen errors af. Later las ik op een site dat je de configuratie op x86 moet zetten op een 64-bit machine (bron even kwijt). Helaas ook hierbij geen succes.

Iemand een idee wat ik nog kan controleren?

NB: het is voor mij voor de eerste keer dat ik zo 'diep' ga met debuggen, dus denk aan het kerstgevoel en heb geduld met deze 'newb'

[beany]

Misschien handig om te weten wat voor een CLR error er uitgespuugt wordt. Kan je daar wat meer info over geven?

[PdeBie]

dat probeer ik juist te achterhalen.
De tool Process Explorer geeft dit niet weer. Alleen maar het aantal wat er optreedt.

[RobIII]

pdebie schreef op maandag 24 december 2012 @ 09:41:
Hiervoor heb ik in het menu 'Debug > Exceptions' de vinkjes 'Thrown' bij CLR Exceptions ingeschakeld. Maar de applicatie vangt geen errors af.

Euh, dat vinkje geldt voor de debugger; ik neem aan dat je de debugger attached hebt aan 't proces? Het is niet zo dat als je dat vinkje aanzet dat je applicatie op magische wijze exceptions gaat vangen

[Niemand_Anders]

Daarom plaats ik de inhoud van Main() altijd in een try/catch block zodat ik de foutmelding kan afvangen en wegschrijven naar een bestand. Als 'Automatically upload errors' aanstaat, probeert een achtergrond process indien een error bestand aanwezig is, deze periodiek te uploaden naar een webservice als de applicatie weer gestart is. Ook toont de applicatie dan een dailog waarin staat dat de error is doorgegeven. Als het upload vinkje uitstaat, krijgt de klant in het dialog alsnog de mogelijkheid de foutmelding (eenmalig) door te sturen..


Maar als je niet weet waarom je applicatie crashed, dan kun je wel een debugger eraan hangen, maar dat is alleen nuttig als je de error kunt reproduceren..

[RobIII]

Niemand_Anders schreef op maandag 24 december 2012 @ 13:50:
Daarom plaats ik de inhoud van Main() altijd in een try/catch block zodat ik de foutmelding kan afvangen

Daar is AppDomain.CurrentDomain.UnhandledException voor bedoeld

C#:

//In je main()
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(MyHandler);

static void MyHandler(object sender, UnhandledExceptionEventArgs args) {
    Exception e = (Exception) args.ExceptionObject;
    //Log or do whatever you want
}

[ Voor 39% gewijzigd door RobIII op 24-12-2012 14:14 ]

[PdeBie]

RobIII schreef op maandag 24 december 2012 @ 12:30:
[...]

Euh, dat vinkje geldt voor de debugger; ik neem aan dat je de debugger attached hebt aan 't proces?

Uiteraard.

Kan ik die AppDomain.CurrentDomain.UnhandledException gebruiken in de pagina om deze vervolgens te loggen op het moment dat hij optreedt?

--edit-- ja dus, je past je eigen bericht net aan

-- edit 2 --
ik ga dit artikel eens uitpluizen en proberen:
http://mlichtenberg.wordp...ed-exceptions-in-asp-net/

Wellicht dat ik dan meer info over de errors te weten kom.

[ Voor 26% gewijzigd door PdeBie op 24-12-2012 14:38 ]

[R4gnax]

pdebie schreef op maandag 24 december 2012 @ 14:15:
-- edit 2 --
ik ga dit artikel eens uitpluizen en proberen:
http://mlichtenberg.wordp...ed-exceptions-in-asp-net/

Wellicht dat ik dan meer info over de errors te weten kom.

Oh. Het is een ASP.NET applicatie.

Dan kun je de CLR exceptions met naam en toenaam gewoon terug vinden in de windows event logs. Die worden daar standaard al gelogd, inclusief stack trace.

[PdeBie]

Correct, alleen staat er dus niet altijd een stacktrace bij.
Heb wel enige foutcodes al uit de event log kunnen halen, maar sommigen dus niet. En daarom dat ik wilde debuggen.