ULS Viewer, for SharePoint 2010 Troubleshooting

Jie Li — Tue, 22 Dec 2009 08:54:00 GMT

My friend Dan Winter posted 2009 SharePoint Toolbox Review today on his blog. Within the post, the best tool I like is the ULS Viewer. If there’s an election of SharePoint Administrator troubleshooting tools, I would vote it as the president!

So what is ULS? It stands for Unified Logging Service. Mr. Winter explained that a lot in his blog so I would not repeat. But, it is the top one thing you should look at when you want to troubleshoot some SharePoint issue. Of course, troubleshooting is not always to get the symbols, debug and trace problems… If that is indeed needed, then it may be a bug. Most of the time, ULS log is already quite helpful. For example, sometimes I got a service error in the webpage, some errors in event log, but nothing told the exact root of the problem. Then when I looked into ULS log, it told me that the credential of the user did not work. It is really helpful.

I did a user research earlier this year, more than 75% of SharePoint Administrators had no idea about ULS log. There’re some reasons. Since the ULS log is designed mainly for product group and customer service usage, the default format is not very user friendly. The log is hard to read, and you may get overwhelming messages instead of the useful ones. Now, we have ULS Viewer to solve the problem.

For SharePoint 2010, by default, ULS log is at

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS

You can check the directory and try to read those logs. I was quite used to that, with notepad:)

ULS Viewer can be used in different modes. The log can be read from log files, real time ULS log, or even clipboard. Here’s some examples:

On a machine running SharePoint 2010, run ULS Viewer. Click File, Open From, then choose ULS (This could also be done by simply press Ctrl+U). Immediately the logs will be shown in real-time. You can filter message level by click the icons in the middle. This can tell you what is going on inside SharePoint.

The best feature I love is the Toggle Correlation Tree button. In SharePoint 2010 we can use correlation id to trace a series of event inside SharePoint. For example, in this screenshot, my machine is trying to flush usage log. The different entries may be buried in the big ULS log file, but with correlation id you can easily track them – they shared the same id “c000006c-5b56-412b-9de1-78aae06d121f”.

Another good feature is the notifications. You can set notification level for ULS Viewer, by default it will pop up notification for Critical message. For example in this screenshot, when Health Analyzer checked my machine for a security rule, it wrote a critical message into the log. With ULS Viewer, you can quickly identify the location of the message. If there’s an exception, you can also check the detail of that.

I’m ready to throw my notepad away – ULS Viewer is the one to go with, for troubleshooting.

Jie.

Troubleshooting Windows Search CPU Consuming Problem

Jie Li — Sun, 13 Jul 2008 20:23:08 GMT

I have heard a lot of complains from my friends and the community that desktop search interferes their daily usage of the computer. These applications, such as Windows Search(also known as WDS, Windows Desktop Search, and the builtin search engine in Vista/2008), Google Desktop Search, index your files while the computer is idle. In this theory, it should not affect your PC’s performance. However, sometimes you can notice that your CPU usage goes up to 100% (or 50% for a dual core system, with 100% usage for one of the cores) for quite a few minutes, even when you are busily working with some applications. This not only brings down the performance of your current applications, but also affects your battery life if you are using a laptop in mobile, and boring fan noise.

So, it is really a nasty problem. When you bring up task manager, you can see something relates with Search is sucking power from your CPU. In my experience, the name is SearchFilterHost.exe. Let’s take a look at it with Sysinternal’s Process Explorer, to understand the relationship of the services.

This is a child process of Windows Search. Without any thoughts, I killed this process, and after a short while it restarted, again with 50%+ CPU usage. Nasty. It’s quite hard to identify Windows Search problem because it cannot tell you what kind of thing it is working on (except those guys who can understand minidumps and can trace into the process, who is really a minority in our IT guys). But by its name, I can know it is a filter host, and with another child process in this tree, I can understand the two process is working on search job, one for the protocol of the file, one for the filter of the file.

Filter daemon is a common part of Microsoft Search architecture. SharePoint, SQL and Windows Search using this daemon to load ifilters, and extract information from different types of files. If this process takes a lot of CPU power, it is quite possible the ifilter is suffering from some problem. And it’s quite likely, the ifilter encountered something it cannot process.

Let’s take a look at the threads of SearchFilterHost. You can notice that one of the thread, RPCRT4.dll, is sucking CPU power. RPC stands for Remote Procedure Call, this can be another evidence.

Now, I’m suspecting there’s a corrupt or misformat file caused the problem. Because it’s corrupt, the ifilter might not be able to process it correctly, and the dead cycles drained all the processing power of the core. But with no log of activity from Windows Search, how can I know which file caused the problem?

Process Monitor is the tool this time. It is also from Sysinternal, as a combination or replacement for FILEMON/REGMON. Run it with filter setting to include all related processes, monitor only file activities, and wait for the problem to reappear.

After a short while, CPU usage goes up again. Stop the capture, and take a look at the log.

Only SearchIndexer is working, and this already lasts for quite a moment. This is abnormal, because it should load protocol daemon and filter daemon to process different files. Another evidence for the suspect of corrupt file. Now scroll up, try to find what is the last file it accessed.

Now it is clear, the indexer loaded “KurzfassungvonInhalt.docx” into memory, and stuck there for a few minutes. That file, should be the root cause of the problem.

I really didn’t have a idea that why this file is on my harddisk. But then I remembered this file was sent to me by one of my friend in Germany, she told me she had a word doc which she cannot open any more, and asked me to try to fix it if possible. If you open this file by Word, you will see an error notice.

I removed the file, and the CPU usage problem went away.

In a similar case, I observed some doc files which produced by WPS Pro edition(a Office clone in China, while its personal edition does not have the problem) caused the same problem. These files can be opened in MS Word, but cannot be processed by the ifilter. I don’t have the idea with doc files from OpenOffice, but these experiences might help you to identify the reason if you are suffering from the same problem.

Process Explorer and Process Monitor can be downloaded from http://technet.microsoft.com/en-us/sysinternals/default.aspx, or www.sysinternals.com. Don’t capture too many events with Process Monitor at one time, otherwise your RAM will run out.

Jie Li's GeekWorld : Troubleshooting

ULS Viewer, for SharePoint 2010 Troubleshooting

Troubleshooting Windows Search CPU Consuming Problem