SharePoint Dragons

Nikander & Margriet on SharePoint

Category Archives: Tools

The scientific methodology for troubleshooting SharePoint

A methodology is a set of methods, rules or ideas that are important in a science or art. The scientific methodology for troubleshooting SharePoint is a set of ideas important for troubleshooting SharePoint issues based on the traditional scientific method for problem solving. This methodology comprises 7 steps, each step containing several ideas.

1.      Define the problem


  • Talk to the person that found out about the issue.
  • If possible, talk to other people experiencing the same problem. They may approach the problem at different angles getting you different insights, or they may be able to provide more accurate details (such as: how long does the issue exist? When did it start?)
  • How long does the problem exist?
  • How bad is it (what’s the priority)?
  • Identify possible parties (and contact persons) that possibly suffer from either the problem or potentially the troubleshooting of the problem (business people, companies, departments). Also identify parties that may play a role in fixing the issue (dba, network admin, 3rd party vendor, etc).
  • Forget what you think you know, don’t assume much and doubt everything.
  • Most important of all: forget pressure, try to free yourself from emotions. This will improve your chances to solve the problem a lot.

Core tasks:

  • Determine what the expected behavior is.
  • Determine what is really happening.
  • Take the trouble to describe what the difference between both scenarios is?

2.      Do research


  • Know your environment, know relevant code.
  • Read literature.
  • Post a forum question.
  • Discuss the problem with others.
  • Tell it to a rubber duck (which forces you to explain the problem thereby helping you to gain insights).
  • If you don’t make any progress within the hour, talk to others.
  • Contact other parties that can help you to get more insight into the problem.
  • Read the error message with attention, preferably aloud.
  • Collect data:
    • ULS logs
    • Event viewer general info
    • Event viewer SharePoint application logs
    • Health log database
    • Temporarily set monitoring logging to verbose
    • Turn on ASP.NET debugging settings
    • Decode add-in access token
    • Turn on developer dashboard
    • Debug issue (client-side JavaScript, C#, PS)
    • Fiddler trace logs
    • IIS logs (inc. request tracing)

Core tasks:

  • Reproduce the problem. Preferably in an environment where you can experiment safely.
  • If there is a working environment and an environment with a problem: keep calm, methodically check what is different and the solution will come!



Establish a hypothesis about the problem.

Core tasks:

  • Ensure the hypothesis is testable.

Design the experiment


  • Contact all parties that are impacted by the experiment (typically business).
  • Test hypothesis.
  • Run automated tests.
  • Comment code that is not needed to test the hypothesis.
  • Add break points.
  • Limit the number of variables you’re testing in a single experiment.
  • Try something funny (this probably won’t solve the issue, but let’s try it anyway).
  • Eliminate most likely causes, such as:
    • Recent code.
    • Custom code instead of MS code.
  • Do “half-splitting”: eliminate the problem by splitting it in half (comment code, determine if the problem is client-side or server-side, determine if the problem is environment specific and so on).
  • Don’t rush. Now is an easy time to break more. Take your time because often you need to temporarily break something to fix it.

Core task:

  • Execute the experiment.
  • Take rudimentary notes.
  • Try variations.

Gather data

Core task:

  • Establish the result of the experiment.
  • Take some distance and disconnect from emotions while you’re observing what is happening.
  • Gather log files.
  • Read error messages carefully. We repeat: Read error messages carefully.

Analyze results

Core tasks:

  • Is the problem solved?
  • Did you learn anything? If you didn’t, the whole troubleshooting experience was pretty useless. Remember, even in the unfortunate event where you didn’t solve the problem, there is still value in having learned from the experience.
  • Do you understand why the problem was solved?
  • Keep notes.
  • Add automated test that check for the issue.
  • Document failed experiments.

Draw conclusions


  • Enjoy successfully solving a problem.
  • Harder to do: enjoy progress.
  • Write about it (blog?).
  • Update documentation.

Core tasks:

  • Determine the next step:
    • The problem is fixed.
    • You need to revisit one of the previous steps.
    • You need to get help from others (MS support, external help, another department, colleagues).


Over the course of time we’ve used lots of sources to improve our bag of tricks. Unfortunately, we didn’t keep track of those sources. So, if you feel you need to be credited but didn’t, we’re awfully sorry. Contact us and we’ll add you to the references section.

We recommend you to check out:




Finding Filtdump

The Filtdump tool, if you don’t know it, is a really useful tool for troubleshooting index problems coming from the days of yore. What’s more, you can do really sneaky things with it, but that’s a topic for another story. We’ve referred to it in one of our golden olden blog posts, at Now, it’s not every day that we have to solve index problems, so it was a long time since we’ve used it. We found out it was surprisingly hard to find, so for our future reference (and anybody else’s), you can find it here: , as a part of the Windows Search 3.x SDK.

When you have performance troubles, you need a PAL!

Is it just us or did we miss a great tool that aids in troubleshooting performance troubles? It’s easy enough defining and reading tons of performance counters, but analyzing them is the tricky part. That’s where the Performance Analysis of Logs tool comes in. Download it at Read more about it at: Apparently, it’s especially great for BizTalk, but we’re just using it for standard Windows performance counters.

IntelliSense for CAML

Wow, we tried to do something similar for SharePoint features, which only partially succeeded. But this sounds like the real deal:

The CAML.NET IntelliSense extensions for Visual Studio 2010 is simply a must-have for SharePoint developers. It can help you tame that sometimes finicky, but ever-so-essential CAML language we all know and love.

You probably already know how to add the out-of-the-box SharePoint schemas to Visual Studio so you get IntelliSense when editing your CAML files.

This is a good first step, but CAML.NET Intellisense takes it even further by adding the following enhancements:

  • Extends the default schema files with detailed annotations imported directly from the SharePoint SDK documentation.
  • Adds a custom WPF IntelliSense Presenter to the Visual Studio environment for a greatly enhanced developer experience.
  • Automatically detects and downloads schema updates so you are always working with the most current information available.
  • Links directly to the online SDK documentation for the currently visible element, so you can “drill down” into the documentation with a single click.

Let’s face it – even with an up to date set of bookmarks, who wants to go searching all over the place for that missing tidbit that tells you just what that obscure attribute is for when you’re right in the middle of building the CAML for your spiffy new feature?

SharePoint 2010 PowerShell Command Builder

Hmm, a visual tool for building SharePoint command tools. We’re not convinced, but we’re giving it a test spin:

MetaVis Migrator

That’s interesting, a SharePoint migration tool with support for Office 365:

SharePoint Manager 2010

Using SharePoint Manager 2010 you can browse every site on a local farm and take a look at every property. It is an easy to use and handy tool.


You can download SharePoint Manager 2010 here:

SharePoint Log Investigation Tool: SPLIT

You can use the SharePoint Log Investigation Tool (SPLIT) to search SharePoint 2010 logs using a correlation ID. The SharePoint logging has been extended with a new correlation ID that is unique for each request or operation. It is easy using this  correlation ID to track down any unexpected errors because you can search for the correlation ID in the trace logs. This unique ID is also maintained between servers for instance when making a call to a service application. With SPLIT you can use this correlation ID to search logs using a Windows interface or a Web-based interface.

You can download SPLIT here:

Community Kit for SharePoint: Development Tools Edition: CKSDev

The Community Kit for SharePoint: Development Tools Edition (CKSDev) extends the Visual Studio 2010 SharePoint project system with advanced templates and tools. This is a really handy tool because using these extensions you will be able to find relevant information from your SharePoint environment in Visual Studio. Useful features are added to Visual Studio to provide help while developing  or deploying SharePoint components.

You will be able to install the components via the Visual Studio Gallery from within the Extension Manager. Or you can download them via the links below.


Creating a Silverlight web part in SharePoint 2010

Don’t forget to install the Silverlight SharePoint web parts and Visual Studio 2010 SharePoint Power Tools when you start building Silverlight web parts. Go to for the power tools consisting of the following:

  • Sandboxed-compatible Visual Web Part
    This item template enables you to use a visual designer to create SharePoint web parts that can be deployed in a sandboxed solution for SharePoint 2010.
  • Sandboxed Compilation
    This extension displays build errors when you use types or members in a SharePoint 2010 sandboxed project which are not allowed in the SharePoint sandbox environment.

After that, find the Silverlight SharePoint web parts at: It contains:

  • The Silverlight Web Part is designed to be very lightweight and as a result using very little or no custom code to create the Web Part. This makes it easy for developers to understand how to use and extend their code after adding the Silverlight Web Part.
  • The Silverlight Custom Web Part takes advantage of the Sandboxed Visual Web Part that was released by the Visual Studio team. This Web Part enables developers to extend the Web Part for advanced scenarios such as adding JavaScript/JQuery and other controls in addition to the Silverlight application.