Sådan foretages fejlfinding af mystiske SharePoint fejl.

Oversigt:

Debugging er vanskeligt, når udvikle brugerdefineret funktionalitet til Windows SharePoint Services 3.0 (WSS) eller Microsoft Office SharePoint Server (MOSS). Den største synder er, at SharePoint normalt overflader meget lidt diagnostiske oplysninger på webbrowseren, når der opstår en fejl. Dette blogindlæg beskriver, hvordan du finde yderligere systemgenererede diagnostiske oplysninger, som ofte kan give ekstra detaljer, at man har brug for at identificere årsagerne. Dette kan så føre til at løse problemet.

Jeg har brugt denne teknik med stor succes for at løse ellers mystisk fejl.

Tilgang:

SharePoint sparer en hel del oplysninger til en diagnosticeringslogfil i en logfil i den 12 hive.

"12-bikuben" er normalt placeret i "C:\Programmere fælles filer FilesMicrosoft SharedWeb Server Extensions12 ". (Jeg er ikke sikker på om det er muligt for den 12 bikuben for at bo hvor som helst ellers, Faktisk).

Ideen er at finde den aktuelle logfil, tvinge fejlen og derefter hurtigt åbne logfilen. Disse logfiler er karakteriseret ved:

  • Rigelige mængder af oplysninger. SharePoint genererer en meget stor mængde af diagnosticeringsoplysninger og skriver det til denne logfil meget hurtigt. Du skal være hurtig med fingrene til at fange det.
  • Mangfoldighed. SharePoint kan ikke skrive til en enkelt logfil, men snarere genererer flere logfiler i rækkefølge.
  • Kopiere og indsætte pænt i MS Excel.

Min foretrukne metode:

  1. Åbn et windows explorer peger på den 12 hivelogs.
  2. Sortere visningen til at vise efter ændringsdato (Seneste første).
  3. Fremhæve den mest aktuelle logfil.
  4. I et webbrowservindue, tvinge fejlen at forekomme.
  5. Hurtigt åbne den aktuelle logfil og kopiere dens indhold til MS Excel.
  6. Springe til slutningen og analysere de relevante poster.

Andre noter:

Som standard, den diagnosticeringslogfil ligger i den 12 hiveLOGS bibliotek.

MS Best practices (Ifølge Mike T. af Microsoft) stat, log-filer skal gemmes på en separat harddisk. Man gør dette via central administration. Systemadministratoren kan have gjort det, i så fald skal du naturligvis finde logfil der i stedet for standarden 12 hive placering).

Denne post omhandler spørgsmål som:

  • SharePoint-arbejdsproces undladt at starte på grund af en intern fejl.
  • (mere tilføjes over tid)
  • Denne løsning har været hjælpsom diagnosticering arbejdsproces fejl (strømsparetilstand. "Arbejdsprocessen kunne ikke starte på grund af en intern fejl").

4 tanker om ”Sådan foretages fejlfinding af mystiske SharePoint fejl.

  1. Larry Virden

    Så, der er tidspunkter, når jeg går til den 12 hive logs og finde der er lidt at intet i dem, Selvom logføringsniveauerne er sådan, at der bør være data der. For eksempel, Jeg sidder her kigger på windows Stifindervisning af mappen logs og jeg kan se, at, i gennemsnit, logfilerne er 1-2 gig. Men så kan jeg se flere timer som logs er 10k. Nu, de pågældende sharepoint-websteder er i brug temmelig meget 24 timer om dagen. Så sker noget der med de tråde/processer genererer oplysninger, der forhindrer logføringsoplysninger, Jeg ville have til at påtage sig. Så, Hvordan kan jeg finde ud af hvad der forårsager dette problem?

    Jeg opdagede dette, da jeg gik til gå til logfilerne til at prøve og fejlfinde et problem. En bruger har tilføjet en webdel og webdelen fortæller dem at tjekke logs. Men selvfølgelig, der er intet i log.

    Svar
  2. Kelly Ford
    Hvis ingen logfiler findes i standard 12HIVE placering, Du kan kontrollere logfilens placering findes i Central Administration->Operationer->Logføring og rapportering->Logføring af diagnosticering.
    Svar
  3. Birthe skrev:
    Tak mand! indeværende er stor. Jeg var endelig i stand til at spore fejl fra logfilen genereres. og hvad jeg gjorde var bare glemme at ændre navnet på assemblynavnet i manifestfilen arbejdsproces.XML angivet i feature.xml.
    Fremragende.
    "RunWorkflow: System.IO.FileNotFoundException: Kunne ikke indlæse filen eller assemblyen ' NewWorkFlowewWorkFlow, Version = 1.0.0.0, Kultur = neutral, PublicKeyToken = ed96fa43c5396ebe’ eller en af dens afhængigheder. Systemet kan ikke finde den angivne fil. Filnavn: ‘NewWorkFlowewWorkFlow, Version = 1.0.0.0, Kultur = neutral, PublicKeyToken = ed96fa43c5396ebe’ på System.Reflection.Assembly._nLoad(AssemblyName filnavn, Streng codeBase, Beviser assemblySecurity, Assemblyen locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) på System.Reflection.Assembly.nLoad(AssemblyName filnavn, Streng codeBase, Beviser assemblySecurity, Assemblyen locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) på System.Reflection.Assembl…"
    Svar

Efterlad et svar

Din e-mail adresse vil ikke blive offentliggjort. Krævede felter er markeret *