Fix For Bit Rate Throttling W3WP Crashes

Over the Summer, we dove deep in to SharePoint 2010 for WCM when we re-launched our corporate website. As I mentioned the other day, I spent a decent amount of time looking at caching and some of the new supporting technologies, like Bit Rate Throttling, an IIS.NET extension to IIS 7.x – part of the IIS Media Services 3.0. package that also includes Smooth Streaming. Bit Rate Throttling is like when you watch a YouTube clip and it only buffers a short time in advance of what you’re watching, also known as Progressive Download. In Microsoft’s words, Bit Rate Throttling is…

“…an IIS 7.0 extension that meters the download speeds of media file types and data between a server and a client computer. The encoded bit rates of media file types such as Windows Media Video (WMV), MPEG-4 (MP4), and Adobe Flash Video, are automatically detected, and the rate at which those files are delivered to the client over HTTP are controlled according to the Bit Rate Throttling configuration.”

It basically saves you bandwidth by only transferring what you’ve watched plus a small, configurable buffer. Think about each user that starts watching a ten minute video but only watches one minute. In that time, they may have downloaded five minutes of content – quadrupling the bandwidth consumption unnecessarily. Bit Rate Throttling shares some user experience characteristics with Streaming Media, but it works on a normal web server over HTTP. It’s really quite a simple tool and I won’t devote space here to explaining it when the IIS.NET site already has some great content, including a brief introductory video. Definitely check it out.

So why am I writing about it?

• It’s cool! We wanted to turn it on to better manage bandwidth while delivering video with SharePoint 2010’s Silverlight Media Web Part.
• Unfortunately it didn’t work when we turned it on. In fact, it crashed our w3wp.exe for the web application where it was enabled.

At the time, I reported the issue on the SharePoint 2010 TechNet forums and IIS.NET, but didn’t get very far. We eventually decided to live with it, leaving BLOB Caching on, even if the bandwidth was left unoptimised.  To summarise the fault, when Bit Rate Throttling was enabled, my web application would load a page or two, then that application’s w3wp.exe would (apparently) leak memory until it crashed. Repeat. The issue and my troubleshooting is explained in more detail on those two threads. These are the key error messages:

Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 0x4a5bd0eb
Faulting module name: bitratemodule.dll, version: 7.1.625.10, time stamp: 0x4aca8535
Exception code: 0xc0000005
Fault offset: 0x0000000000007669
Faulting process id: 0x2140
Faulting application start time: 0x01cb2cd16410dafa
Faulting application path: c:windowssystem32inetsrvw3wp.exe
Faulting module path: C:Program FilesIISMediabitratemodule.dll
Report Id: e3004397-98c4-11df-91ae-00155d06ab22

Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: w3wp.exe
P2: 7.5.7600.16385
P3: 4a5bd0eb
P4: bitratemodule.dll
P5: 7.1.625.10
P6: 4aca8535
P7: c0000005
P8: 0000000000007669
P9:
P10:

Attached files:

These files may be available here:

Analysis symbol:
Rechecking for solution: 0
Report Id: e3004397-98c4-11df-91ae-00155d06ab22
Report Status: 0

Luckily, I noticed that Jack over at IIS.NET recently posted:

I believe we have identified the problem and have a fix for the issue.  The fix will be available as part of IIS Media Services 4.0 which will be released in the very near future.

Good news! I see that a release is now available for IIS Media Services 4.0 Beta (second down in the right-hand column on the Bit Rate Throttling site). Unfortunately I haven’t had a chance to test this yet and I’m not sure when I’ll get the time. For now, I’m posting this incomplete, as it would be great if many people tested this and the IIS team got as much feedback on this technology as possible while it’s in a Beta release. Obviously, I’d caution against installing either version in production for now. 3.0 doesn’t work and 4.0 is very new.

A few related notes:

• BLOB Caching is not a requirement for Bit Rate Throttling in general, but it is a requirement for Bit Rate Throttling SharePoint 2010 web applications. The Plan for caching and performance document notes, “Bit rate throttling will not work correctly if you do not first enable the BLOB cache and configure it to cache the files types that you want to throttle.”
• We didn’t look at Smooth Streaming for very long, because the Silverlight Media Web Part hasn’t been built to adapt content in that manner.