Troubleshooting SharePoint Quick Tip with the Logs
I just discovered a little trick for easing the process of reading and reviewing the SharePoint logs, so I thought I’d share.
Open a SharePoint log and you get an incredibly large file with so much info, especially if your logging is set to verbose. As I develop and I receive generic errors, I need to go into these aggravatingly large logs to find my real issue. Most cases it is easy enough to open it in Notepad++, search for the error and go from there.
I figured out this trick when troubleshooting a web part. I get a typical SharePoint generic error when trying to add it to a page. I find the error in the logs, and it’s just as generic there as well. Now I want to see the entire log history for adding the solution, activating the feature, and adding the web part to a page. I hope to find an error on solution install or feature activation.
So all I want to see is a small window of the log, not the entire thing. I could track my start time by staring at the server clock when I press Deploy and Activate, but even 10 seconds off can add dozens of lines in the logs.
What to do… let’s create a fresh new log for my activity.
Right before I’m about to perform my steps I want to monitor, I restart the SharePoint 2010 Tracing service. (go to Start > Administrative Tools > Services)
By restarting the service, this will create a new log file with the current date and time stamp. Now I walk through my process, recreate the error, and restart the service again. A new log file is created, and the previous one has that small window of time in it! Now I take this and I can comfortably read it, knowing I’m not reading more than I need. Sure enough, I found an assembly reference error on solution deployment.
Open a SharePoint log and you get an incredibly large file with so much info, especially if your logging is set to verbose. As I develop and I receive generic errors, I need to go into these aggravatingly large logs to find my real issue. Most cases it is easy enough to open it in Notepad++, search for the error and go from there.
I figured out this trick when troubleshooting a web part. I get a typical SharePoint generic error when trying to add it to a page. I find the error in the logs, and it’s just as generic there as well. Now I want to see the entire log history for adding the solution, activating the feature, and adding the web part to a page. I hope to find an error on solution install or feature activation.
So all I want to see is a small window of the log, not the entire thing. I could track my start time by staring at the server clock when I press Deploy and Activate, but even 10 seconds off can add dozens of lines in the logs.
What to do… let’s create a fresh new log for my activity.
Right before I’m about to perform my steps I want to monitor, I restart the SharePoint 2010 Tracing service. (go to Start > Administrative Tools > Services)
By restarting the service, this will create a new log file with the current date and time stamp. Now I walk through my process, recreate the error, and restart the service again. A new log file is created, and the previous one has that small window of time in it! Now I take this and I can comfortably read it, knowing I’m not reading more than I need. Sure enough, I found an assembly reference error on solution deployment.
