Hvordan du feilsøker mystiske SharePoint-feil.

Oversikt:

Feilsøking er vanskelig når du utvikler egendefinerte funksjonaliteten for Windows SharePoint Services 3.0 (WSS) eller Microsoft Office SharePoint Server (MOSS). Den viktigste årsaken er at SharePoint normalt overflater lite diagnostisk informasjon på web-leseren når en feil oppstår. Dette blogginnlegget beskriver hvordan du finner flere systemgenererte diagnoseinformasjon som kan ofte gi det ekstra bit av detaljer som man trenger for å identifisere årsakene. Dette kan deretter føre til løse problemet.

Jeg har brukt denne teknikken med stor suksess for å løse ellers mystisk feil.

Tilnærming:

SharePoint sparer mye informasjon til en diagnostisk logg i en loggfil i den 12 struktur.

"12 strukturen" ligger vanligvis på "C:\Programmet FilesCommon FilesMicrosoft SharedWeb Server Extensions12 ". (Jeg er ikke sikker på om det er mulig for den 12 struktur for å leve alt annet, faktisk).

Ideen er å finne gjeldende loggfil, tvinge feilen og raskt åpne loggfilen. Disse loggfilene er preget av:

  • Store mengder informasjon. SharePoint genererer en stor mengde diagnoseinformasjon og skriver det til at loggfilen svært raskt. Du må være rask til å fange den.
  • Mangfold. SharePoint skriver ikke til en enkelt loggfil men heller genererer flere loggfiler i rekkefølge.
  • Kopiere og lime pent inn i MS Excel.

Min favoritt metode:

  1. Åpne et windows Utforsker peker til den 12 hivelogs.
  2. Sortere visningen Vis etter endringsdato (siste første).
  3. Markere mest gjeldende loggfil.
  4. I et webleservindu, tvinge feilen oppstår.
  5. Raskt åpne gjeldende loggfil og kopiere innholdet til Excel.
  6. Hoppe til slutten og analysere de aktuelle postene.

Andre notater:

Som standard, diagnoseloggen som er plassert i den 12 hiveLOGS mappe.

MS beste praksis (Ifølge Mike T. Microsoft) staten der loggfilene skal lagres til en egen harddisk. Man gjør dette via Sentraladministrasjon. Systemansvarlig kan ha gjort dette, i så fall ville du åpenbart trenger å finne loggfilen det for standard 12 strukturen plassering).

Denne oppføringen løser problemer som:

  • SharePoint-arbeidsflyt kan ikke starte på grunn av en intern feil.
  • (flere skal legges over tid)
  • Denne oppføringen har vært nyttig diagnostisere arbeidsflytfeil (f.eks. "Arbeidsflyten kan ikke starte på grunn av en intern feil").

4 tanker om “Hvordan du feilsøker mystiske SharePoint-feil.

  1. Larry Virden

    Så, Det er tider når jeg går til den 12 hive logger og finne det er liten eller ingenting i dem, Selv om Loggnivåene er slik at det skal være data der. For eksempel, Jeg sitter her ser på windows Utforsker-visningen i mappen logger og jeg ser at, i gjennomsnitt, loggene er 1-2 konsert. Men så jeg ser flere timer der loggene er 10k. Nå, sharepoint-områder i spørsmålet er i bruk ganske mye 24 timer i døgnet. Så skjer noe med tråder/prosessene generere informasjonen som hindrer dem i å loggingsinformasjonen, Jeg må anta. Så, Hvordan kan jeg finne ut hva som forårsaker problemet?

    Jeg oppdaget alt dette når jeg gikk for å gå til loggene til å prøve og feilsøke et problem. En bruker lagt til en webdel og webdelen forteller dem å sjekke loggene. Men selvfølgelig, Det er ikke noe i loggen.

    Svar
  2. Kelly Ford
    Hvis ingen loggfiler finnes i standardplasseringen for 12HIVE, Du kan sjekke loggfilplasseringen finnes i Sentral administrasjon->Operasjoner->Logging og rapportering->Diagnoselogging.
    Svar
  3. Nafees skrev:
    Takk mann! Dette er flott. Jeg var endelig i stand til å spore feil fra loggfil generert. og hva jeg did var bare glem å endre navnet på samlingen i manifestfilen workflow.xml angitt i feature.xml.
    Utmerket.
    "RunWorkflow: System.io.FileNotFoundException: Kunne ikke laste fil eller montering ' NewWorkFlowewWorkFlow, Versjon = 1.0.0.0, Culture = neutral, PublicKeyToken = ed96fa43c5396ebe’ eller en av dens avhengigheter. Systemet finner ikke den angitte filen. Filnavn: ‘NewWorkFlowewWorkFlow, Versjon = 1.0.0.0, Culture = neutral, PublicKeyToken = ed96fa43c5396ebe’ ved System.Reflection.Assembly._nLoad(AssemblyName filnavn, Streng kodebase, Bevis assemblySecurity, Montering locationHint, StackCrawlMark& stackMark, Boolsk throwOnFileNotFound, Boolsk forIntrospection) ved System.Reflection.Assembly.nLoad(AssemblyName filnavn, Streng kodebase, Bevis assemblySecurity, Montering locationHint, StackCrawlMark& stackMark, Boolsk throwOnFileNotFound, Boolsk forIntrospection) ved System.Reflection.Assembl…"
    Svar

legg igjen et svar

e-postadressen din vil ikke offentliggjøres. Obligatoriske felt er merket *