Overview:
Debugging is difficult when developing custom functionality for Windows SharePoint Services 3.0 (WSS) or Microsoft Office SharePoint Server (MOSS). The main culprit is that SharePoint normally surfaces very little diagnostic information on the web browser when an error occurs. This blog entry describes how to locate additional system-generated diagnostic information that can often provide that extra bit of detail that one needs in order to identify root causes. This can then lead to solving the problem.
I have used this technique with great success to solve otherwise mysterious errors.
Approach:
SharePoint saves a great deal of information to a diagnostic log in a log file in the 12 hive.
The "12 hive" is usually located at "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12". (I’m not sure if it’s possible for the 12 hive to live anywhere else, in fact).
The idea is to locate the current log file, force the error and then quickly open the log file. These log files are characterized by:
- Copious amounts of information. SharePoint generates a very large amount of diagnostic information and writes it to that log file very quickly. You need to be quick with the fingers to capture it.
- Multiplicity. SharePoint does not write to a single log file but rather generates multiple log files in sequence.
- Copy and paste nicely into MS Excel.
My favorite method:
- Open up a windows explorer pointing to the 12 hive\logs.
- Sort the view to show by modified date (most recent first).
- Highlight the most current log file.
- In a web browser window, force the error to occur.
- Quickly open the current log file and copy its contents to MS Excel.
- Jump to the end and analyze the relevant entries.
Other Notes:
By default, the diagnostic log is located in the 12 hive\LOGS directory.
MS Best practices (as per Mike T. of Microsoft) state that the log files should be saved to a separate hard drive. One does this via central admin. Your system administrator may have done this, in which case you’d obviously need to find the log file there instead of the default 12 hive location).
This entry addresses issues such as:
- SharePoint workflow failed to start due to an internal error.
- (more to be added over time)
- This entry has been helpful diagnosing workflow errors (e.g. "The workflow failed to start due to an internal error").
So, there are times when I go to the 12 hive logs and find there is little to nothing in them, even though the logging levels are such that there should be data there. For instance, I’m sitting here looking at the windows explorer view of the logs folder and I see that, in average, the logs are 1-2 gig. But then I see several hours in which the logs are 10k. Now, the sharepoint sites in question are in use pretty much 24 hrs a day. So something is happening to the threads/processes generating the information that prevent them from logging information, I would have to assume. So, how do I figure out what is causing this issue?
I discovered all this when I went to go to the logs to try and debug a problem. A user added a web part and the web part tells them to check the logs. But of course, there’s nothing in the log.
help me with error: LOG ID 5566