Vă mulțumim pentru susținere

Manipulatorul de excepții nefolosit în .NET 1.1

Mă mențin o aplicație .NET 1.1 și unul dintre lucrurile cu care am fost însărcinat este să vă asigur că utilizatorul nu vede nicio notificare de eroare neprietenoasă.

Am adăugat aplicații de manipulare la Application.ThreadException și AppDomain.CurrentDomain.UnhandledException , care sunt apelate. Problema mea este că dialogul standard de eroare CLR este încă afișat (înainte de a fi apelat un handler de excepție).

Jeff vorbește despre această problemă pe blogul său aici și aici . Dar nu există nicio soluție. Deci, care este modul standard în .NET 1.1 pentru a face față excepțiilor necontrolate și a afișa o casetă de dialog prietenoasă?

Răspunsul lui Jeff a fost marcat ca fiind răspunsul corect, deoarece link-ul pe care la furnizat are cele mai complete informații despre cum să facă ceea ce este necesar.

0
adăugat editat
dacă credeți că răspunsul la acest mesaj este răspuns, marcați ca răspuns.
adăugat autor Anonymous User

8 răspunsuri

Pe lângă jurnalul ULS pe ​​care îl menționează Jaap, veți găsi, de asemenea, informații relevante în jurnalul de evenimente "Cerere".

Puteți găsi Event Viewer în Instrumente de administrare sau pur și simplu scrie eventvwr.exe în Run.

De asemenea, există multe proiecte pe Codeplex, care sunt utile pentru gestionarea fișierului jurnal ULS. Doar căutați ULS pe ​​Codeplex.com

În cele din urmă, vă recomandăm să utilizați SPTraceView de Hristo Pavlov, care vă oferă evenimente ULS în timp real. Mai ales puternic atunci când faci depanare de producție. Acesta poate fi combinat și cu DebugView .

EDIT: A good blog post on all the logs of SharePoint: How do i troubleshoot SharePoint? So many logs!

8
adăugat
Serviciu unificat de înregistrare
adăugat autor Anonymous User
Jurnalele ULS sunt înregistrări de urmărire pe care SharePoint le scriu în momentul executării API-urilor. Puteți configura niveluri de urmărire pentru ULS și jurnale de evenimente individual pentru diferite categorii din CA> Operații> Logare de diagnosticare. Fiți conștienți de faptul că aceasta poate afecta performanța și stocarea dacă setați nivelurile de jurnal prea mari. În cazul depanării unei probleme, le puteți seta pe Verbose și le puteți seta înapoi la Medium după aceea. Citiți mai multe: te
adăugat autor Anonymous User
ULS este scurt pentru?
adăugat autor engtech
Ce este serviciul de logare unificat? Ceva specific serverului SharePoint? Aveți alte documente de citit?
adăugat autor engtech

Jurnalele ULS sunt generate de server în următorul dosar:

C: \ Program Files \ Fișiere obișnuite \ Microsoft Shared \ extensii server web \ 12 \ LOGS

Puteți modifica nivelul înregistrării prin intermediul administratorului central, de ex. mai verbose sau mai puțin verbose.

Este recomandat să adăugați o bară de instrumente "12 stup" la bara de pornire, astfel încât să puteți accesa cu ușurință jurnalele și restul de SharePoint care se află în unitatea de 12.

Există, de asemenea, unelte open source care vă permit să vizualizați jurnalele printr-o interfață ușor de utilizat. Un exemplu este Reader de fișiere log WSS/MOSS , dezvoltat de Stuart Starrs .

4
adăugat
Este, de asemenea, o idee bună să mutați aceste fișiere de jurnal de la C: și în unitatea de date :-) Puteți determina atât diagnostice, cât și traiectoria căilor de fișiere în Administrația Centrală
adăugat autor Anonymous User
asta pentru că jurnalul de urmărire este în mod continuu scris în funcție de punctul de partajare
adăugat autor Anonymous User
Când văd cel mai recent jurnal de fișiere, m-am întâlnit cu eroare - fișierul este utilizat de alt proces. Orice idei ce este greșit?
adăugat autor engtech
MS a lansat, de asemenea, instrumentul ULS Viewer aici code.msdn.microsoft.com/ULSViewer
adăugat autor Alex Angas
@AlexAngas Linkul pentru ULS Viewer nu mai este bun. (5 ani mai târziu, asta este ...)
adăugat autor bgmCoder
@ BGM Acum re-lansat aici: microsoft.com/en- noi/download/details.aspx? id = 44020 . Cronometru ciudat ...
adăugat autor Alex Angas
@AlexAngas Vă mulțumim pentru actualizarea link-ului!
adăugat autor bgmCoder

"Serverul a returnat o eroare nespecifică atunci când încearcă să obțină date din sursa de date. Verificați formatul și conținutul interogării dvs. și încercați din nou, dacă problema persistă, contactați administratorul de server." eroare este o eroare SharePoint Designer și este puțin probabil să vedeți nimic în jurnalele despre acest lucru.

If you are only doing Data View -> Insert Dataview and getting this error, I'd be surprised. Are you doing anything else before you get the error? It could be that you are trying to insert the Dataview in a part of the page where it cannot be, such as inside another control.

1
adăugat
ar trebui să creați, probabil, un subiect nou dacă doriți un răspuns la ceea ce ar putea fi eroarea. Întrebarea era despre logarea în general.
adăugat autor Anonymous User
Bună, Marc, trag Dataview într-o pagină de aspect WebPart (creez o nouă pagină Webpartartă, bazată pe aspect). Pot să trag Dataview într-un WebPart?
adăugat autor engtech
Am primit asta în astfel de cazuri - implică, de obicei, adăugarea unui câmp de căutare într-o listă care are deja o mulțime de elemente și fluxuri de lucru și alte distracții - există o combinație ciudată pe care SP nu o place. Înlăturarea elementelor de test stabilește totul în lume.
adăugat autor ebruchez

Este o aplicație de consolă sau o aplicație Windows Forms? Dacă este o aplicație consola .NET 1.1, acest lucru este, din păcate, de design - este confirmat de un dev de MSFT în al doilea post blog pe care l-ați referit :

BTW, pe mașina mea 1.1 exemplul din MSDN nu are rezultatul așteptat; este doar faptul că a doua linie nu apare decât după ce ați atașat un depanator (sau nu). În v2 am răsturnat lucrurile astfel încât evenimentul UnhandledException se declanșează înainte ca atașatorul să atace, ceea ce pare să fie ceea ce majoritatea oamenilor așteaptă.

Suna ca .NET 2.0 face acest lucru mai bine (multumesc bunatate), dar sincer, nu am avut timp sa ma intorc si sa verific.

0
adăugat

Oh, în Windows Forms trebuie cu siguranță să poți să-l dai la lucru. Singurul lucru pe care trebuie să-l urmăriți sunt lucrurile care se întâmplă pe diferite fire.

Am un articol vechi Cod de proiect care ar trebui să ajute:

Manipulare excepțională pentru utilizatori

0
adăugat

Este o aplicație Windows Forms. Excepțiile care sunt prinse de Application.ThreadException funcționează bine, și nu primesc caseta de excepție urgentă .NET ( OK pentru a termina, Anulați pentru a depana? cu ce??).

Aveam câteva excepții care nu au fost prinse de asta și au ajuns la evenimentul AppDomain.UnhandledException care provoacă probleme. Cred că am prins majoritatea excepțiilor și le afișez acum în cutia noastră de erori frumoasă.

Așadar, trebuie să sper că nu există alte circumstanțe care ar cauza excepții pentru a nu fi prins de aplicația Application.ThreadException.

0
adăugat

AppDomain.UnhandledException is an event, not a global exception handler. This means, by the time it is raised, your application is already on its way down the drain, and there is nothing you can do about it, except for doing cleanup and error logging.

Ceea ce sa întâmplat în spatele scenei este următorul: Cadrul a detectat excepția, a mers până la capătul stivei de apel, nu a găsit niciun manipulator care să se recupereze din eroare, deci nu a putut stabili dacă este în siguranță pentru continuarea executării. Așa că a început secvența de închidere și a tras concursul ca o curtoazie pentru tine, astfel încât să îți poți plăti respectul față de procesul tău deja condamnat. Acest lucru se întâmplă atunci când o excepție este lăsată nefolosită în firul principal.

Nu există nicio soluție în acest punct de eroare. Trebuie să puneți un handler de excepție real (un bloc de captură) în amonte de toate locurile în care apare această eroare și să îl transmiteți (de exemplu) unei metode / clase globale care vor determina dacă este sigur să se raporteze și să se continue, pe baza tip de excepție și / sau conținut.

Editare: Este posibil să dezactivați (= hack) mecanismul de raportare a erorilor încorporat în Windows, astfel încât dialogul obligatoriu de "crash and burn" să nu fie afișat atunci când aplicația dvs. coboară. Cu toate acestea, acest lucru devine eficient pentru toate aplicațiile din sistem, nu doar cele ale dvs.

0
adăugat

Un comportament de excepție nefolosit într-o aplicație .NET 1.x Windows Forms depinde de:

  • Tipul firului care a aruncat excepția
  • Dacă a apărut în timpul procesării mesajelor de ferestre
  • Dacă un proces de depanare a fost atașat procesului
  • Setarea registrului DbgJitDebugLaunchSetting
  • Steagul jitDebugging din App.Config
  • Fie că depășiți manualul de excepție Windows Forms
  • Dacă ați gestionat evenimentul de excepție CLR
  • Faza lunii

Comportamentul implicit al excepțiilor nefolosite este:

  • Dacă se produce o excepție la firul principal când se pompează mesajele din fereastră, acesta este interceptat de dispozitivul de tratare a excepțiilor Windows Forms.
  • Dacă se produce o excepție la firul principal când se pompează mesajele din fereastră, acesta va termina procesul de aplicație dacă nu este interceptat de dispozitivul de tratare a excepțiilor Windows Forms.
  • Dacă excepția apare pe un fir manual, threadpool sau finalizer, este înghițit de CLR.

Punctele de contact pentru o excepție nefolosită sunt:

  • Handler de excepție Windows Forms.
  • Comutatorul de registry JIT-debug DbgJitDebugLaunchSetting.
  • Evenimentul de excepție CLR neautorizat.

Modul de tratare a excepțiilor încorporate în formularul Windows are următoarele valori implicite:

  • Catches an unhandled exception when:
    • exception is on main thread and no debugger attached.
    • exception occurs during window message processing.
    • jitDebugging = false in App.Config.
  • Shows dialog to user and prevents app termination.

Puteți dezactiva ultimul comportament setând jitDebugging = true în App.Config. Dar amintiți-vă că aceasta ar putea fi ultima șansă de a opri terminarea aplicației. Deci, următorul pas pentru a prinde o excepție nefolosită este înregistrarea pentru evenimentul Application.ThreadException, de exemplu:

Application.ThreadException += new
Threading.ThreadExceptionHandler(CatchFormsExceptions);

Rețineți setarea registrului DbgJitDebugLaunchSetting sub HKEY_LOCAL_MACHINE \ Software.NetFramework. Aceasta are una din cele trei valori pe care le cunosc:

  • 0: afișează dialogul de utilizator care cere "debug sau termin".
  • 1: permite excepția prin intermediul căruia CLR se ocupă.
  • 2: lansează depanatorul specificat în cheia de registry DbgManagedDebugger.

În Visual Studio, accesați meniul Instrumente ? Opțiuni ? Debugging ? JIT pentru a seta această tastă la 0 sau 2. Dar o valoare de 1 este de obicei cea mai bună pe mașina unui utilizator final. Rețineți că această cheie de registry este acționată înainte de evenimentul de excepție nefolosit CLR.

Acest ultim eveniment este ultima ta șansă de a loga o excepție nefolosită. Este declanșată înainte de executarea blocurilor "În cele din urmă". Puteți intercepta acest eveniment după cum urmează:

AppDomain.CurrentDomain.UnhandledException += new
System.UnhandledExceptionEventHandler(CatchClrExceptions);
0
adăugat