Přehled:
Ladění je obtížné při vývoji vlastních funkcí pro službu Windows SharePoint Services 3.0 (WSS) nebo Microsoft Office SharePoint Server (MECH). Hlavním viníkem je, že SharePoint obvykle povrchy velmi málo diagnostické informace o webovém prohlížeči dojde-li k chybě. Tato položka blogu popisuje, jak najít další generované systémem diagnostické informace, které mohou často poskytnout to extra kousek detailu, že potřebuje zjistit příčiny. To může vést k řešení problému.
Použil jsem tuto techniku s velkým úspěchem řešit jinak záhadné chyby.
Přístup:
SharePoint ukládá velké množství informací do diagnostického protokolu v souboru protokolu v 12 podregistr.
"12 Podregistru" je obvykle umístěna v "C:\Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12 ". (Nejsem si jistý, jestli je to možné, 12 podregistr žít nikde jinde, Vlastně).
Myšlenka je k nalezení aktuální soubor protokolu, Vynutit chybu a pak rychle otevřít soubor protokolu. Tyto soubory protokolu jsou charakterizovány:
- Velkým množstvím informací. SharePoint generuje velké množství diagnostických informací a zapíše jej do tohoto souboru protokolu velmi rychle. Musíte být rychlý prsty zachytit to.
- Násobnost. SharePoint nelze zapisovat do jediného souboru protokolu, ale spíše vytváří několik souborů protokolů v posloupnosti.
- Zkopírujte a vložte pěkně do MS Excel.
Můj oblíbený způsob:
- Otevřete Průzkumníka windows, přejděte 12 hivelogs.
- Řazení zobrazení podle data změny (poslední první).
- Zvýraznit aktuální soubor protokolu.
- V okně webového prohlížeče, síla chybě dochází.
- Rychle otevřít aktuální soubor protokolu a zkopírujte jeho obsah do MS Excel.
- Přeskočit na konec a analyzovat příslušné údaje.
Jiné poznámky:
Ve výchozím nastavení, na diagnostický protokol se nachází v 12 hiveLOGS adresář.
MS Best practices (podle Mike T. Microsoft) stát, že by měly být soubory protokolů ukládány na samostatný pevný disk. Jeden je realizováno prostřednictvím centrální správy. Správce systému může udělat, v takovém případě by samozřejmě potřebujete najít soubor namísto výchozího protokolu 12 umístění úlu).
Tato položka řeší problémy jako například:
- Pracovní postup služby SharePoint se nepodařilo spustit z důvodu vnitřní chyby.
- (více přidáno postupem času)
- Tato položka byla užitečná, diagnostikování chyby pracovního postupu. (např.. "Pracovní postup se nepodařilo spustit z důvodu vnitřní chyby").
Tak, jsou chvíle, kdy jdu na 12 podregistr protokoly a zjistit, že je málo k nic v nich, i přesto, že úrovně protokolování jsou takové, že by měla být data tam. Například, Já tady sedím, při pohledu na zobrazení Průzkumníka windows logs složky a vidím, že, v průměru, protokoly jsou 1-2 koncert. Ale pak jsem viděl několik hodin, v nichž jsou protokoly 10k. Nyní, předmětné weby služby sharepoint jsou používány pěkná hodně 24 hodin denně. Takže něco se děje vlákna/procesy vytváření informací, které jim zabránit protokolování informací, Já bych předpokládat. Tak, Jak zjistit, co je příčinou tohoto problému?
Zjistil jsem to, když jsem jít do protokolů vyzkoušet a ladění problému. Uživatel přidat webovou část a webová část říká, zkontrolovat logy. Ale samozřejmě, není nic v protokolu.
Pomozte mi s chybou: ID PROTOKOLU 5566