Jaap Vossers' SharePoint Blog

Just another WordPress.com site

Archive for the ‘SharePoint 2013’ Category

SharePoint Asynchronous Event Receivers and the powershell.exe process

with 5 comments

We recently had a very strange problem with one of our custom Event Receivers in our production SharePoint environment. The Event Receiver implemented the Asynchronous ItemUpdated event. It was used to generate and set a value on one of our fields on the document being updated. The code in the Event Receiver appeared to work most of the times, but would fail at seemingly random occasions and would leave the updated document without the generated field set.

We were struggling to isolate the combination of factors that made it fail. The weirdest thing was that there were no errors to be found in the ULS logs or the Event Log. We added lots of logging and try/catch blocks, but for some reason when the Event Receiver failed it would never enter the catch block, so there was no exception to log.

One key point that helped us with the troubleshooting was that we had noticed that the Event Receiver ALWAYS worked when the document was being updated through the SharePoint web UI. We also had a PowerShell script which was used for bulk updating of documents. This script was scheduled to run at regular intervals using Windows Task Scheduler. It appeared that the issue only occurred when the Updated event was triggered via this scheduled PowerShell script, but even then it still seemed intermittent as it would often work just fine.

We were unable to reproduce the issue at all when calling the ps1 file directly from the PowerShell console. So what was different when the script was run from the Task Scheduler vs directly from the PowerShell console? Well, the Task Scheduler actually calls a BATCH script which in turn invokes the PowerShell script which fires up a new PowerShell process. This process dies when it finishes execution of the ps1 file!

Remember, our Event Receiver is an Asynchronous one, so it would not block the execution of the PowerShell script. The Event Receiver is actually executed on a thread inside the PowerShell process since the ps1 script triggered the Updated event. So, when the PowerShell.exe process dies, it does not seem to wait for any background threads to complete, which in our case causes our Event Receiver to suffer from a sudden death. I was a bit surprised to see this to be honest!

Anyway, I guess one of the reasons why in our case the problem seemed to be appearing randomly is that only the last document in a batch would be affected, which sometimes meant 1 in a couple thousand documents. Only recently users had started feeding the script with “batches” consisting of just one document, which is what highlighted the problem to us and lead to this investigation. We were wondering what had changed recently (we had not touched this part of the code for a while!), since it was all working fine before (we thought), but in reality the bug had always been there but it had never occurred to us!

So everyone please beware when invoking PowerShell scripts from BATCH scripts when you have Asynchronous Event Receivers in your SharePoint environment!

What did we do to work around our problem? We just put a little Sleep at the end of our PowerShell script… 🙂

Written by jvossers

February 3, 2014 at 10:10 pm

Getting query string values in JavaScript

leave a comment »

With the introduction of the new SharePoint 2013 App Model, many SharePoint Developers will have to get their hands dirty writing JavaScript. One operation that is going to be very common is to read query string values from JavaScript. C# Developers are used to things like HttpContext.Current.Request.QueryString[“param1”], but unfortunately it is slightly more complicated to get the same result in JavaScript.

Searching the web for an answer on how to do this in JavaScript yields many different results. I would say that the best suggestions are listed on this popular question on StackOverflow. The most upvoted answer to this StackOverflow question has been improved by James Padolsey which has lead to the following function:

function getParameterByName(name) {

    var match = RegExp('[?&]' + name + '=([^&]*)')

    return match ?
        decodeURIComponent(match[1].replace(/\+/g, ' '))
        : null;


This is my favourite solution as it’s brief, readable, and it works 🙂




Written by jvossers

August 30, 2012 at 11:18 am

Hyperlinks with target=”_blank” inside SharePoint 2013 ClientWebPart blocked in Chrome

leave a comment »

Recently I have been playing a bit with the new SharePoint 2013 App model. I was using the new Napa tools to develop a little App that could be be hosted in an App Part, also known as ClientWebPart, which is essentially an iframe which loads your App.

My App consisted of an ASPX page with a bunch of hyperlinks with target=”_blank” on them. I noticed that when the ASPX page was loaded by the ClientWebPart in its iframe, the hyperlinks wouldn’t work at all in Chrome (Firefox and IE were fine!). I started inspecting the DOM and noticed a “sandbox” attribute on the iframe element.

The sandbox attribute rendered on the ClientWebPart iframe contains the following four options:

  • allow-forms
  • allow-scripts
  • allow-same-origin
  • allow-top-navigation

After a bit of research, I found that adding the “allow-popups” option unblocks the hyperlinks.

I would say that this is a bug in the ClientWebPart, as Chrome appears to be the only browser affected. Let’s hope this will be fixed soon! In the meantime, consider using target=”_top” as an alternative, as this does work.

Written by jvossers

August 28, 2012 at 5:03 pm