Kevin Gearing's Blog : ASP.NET, Windows

Firefox, BinaryWrite and Compression

dotNetFreak — Sat, 14 Jul 2007 09:15:00 GMT

Whilst writing the sound support for FormShield v2, I came across quite an interesting issue, well it was interesting once I'd found the answer, but up until then I wasn't in the best of moods.

Basically, FormShield uses the BinaryWrite() method to write an audio file to the requesting browser to provide sound support. The issue was that this worked fine in IE, Safari and Opera, but for some reason Firefox didn't seem to like it.

The strange thing about it was that it would play the first x number of characters, but then stop. On a Mac, it would only play the first character before giving up.

Thinking that it must be something to do with how I was writing the file out, or perhaps the file size, or even my code that builds the sound file, I started to pull the code apart.

A few hours later, I was no further forward.

I came to the conclusion that it couldn't be my code, after all, writing images out this way seemed to work fine in every browser.

So, I started to look around the problem. I then stumbled across an old post related to writing out PDF files on the fly using BinaryWrite and whilst the issue didn't see to be the same, or affect the same browser (they were talking about IE), one word was mentioned that rang a bell - "Compression".

I suddenly remembered that HTTP compression was enabled in IIS on this particular server - Quickly turning it off and running an 'iisreset' and testing resulted in a perfect playback.

Thankfully all of the code I changed was only a CTRL-Z away from being put back to how it was originally and 10 minutes later I retested it and it worked fine.

So, why does HTTP compression in IIS only break Firefox? No idea - After spending seven hours on the problem I really couldn't care.

Slow Opening Web Project with Visual Studio .NET and w3wp.exe

dotNetFreak — Fri, 18 Feb 2005 12:51:00 GMT

Following on from my previous post, I've also started to experience another problem. This time with Visual Studio .NET and it taking forever to open a Web Project.

Whilst testing I noticed that opening the Web with FrontPage was as quick as I would expect, however when opening with Visual Studio, it took forever. After it had been opened with Visual Studio, trying to re-open with FrontPage was also extremely slow.

I noticed on the server, that two w3wp.exe processes were being spawned, one running under 'System' and one running under 'Network Service'. Whilst opening with Visual Studio, if I switch to the server and kill the process running under 'System', it opens the project immediately... strange!

Research on Microsoft's knowledgebase points to an article which has a hotfix available. However, upon contacting Microsoft, it would appear that this hotfix has been withdrawn and replaced with a new one, which I was sent. Unfortunately this didn't solve the problem, and as I'm not prepared to pay the £185+ fee to find out what's causing it, killing a second process when it happens, is a cheap workaround.

I believe MS are aware of this problem and it should be fixed in the .NET Framework v1.1 SP2.

ASP.NET, w3wp.exe, 100% CPU Usage and McAfee VirusScan Enterprise

dotNetFreak — Tue, 15 Feb 2005 17:15:00 GMT

Recently I've been experiencing a strange problem on one of our development servers that was hosting an ASP.NET application. The server in question was running Windows Server 2003 with IIS6 and VirusScan Enterprise v8.0i.

I was noticing that any ASP.NET page that was being hit would cause the CPU usage to jump to 100% for a period of a few seconds, before returning to it's typical 2-3% - The offending process? w3wp.exe.

I ruled out (as far as possible) the application as the fault, simply because the same application was running on a Windows 2000 Server as well as an identical Windows Server 2003 without any issue.

Running adplus (Windows Debugging Tools) revealed some interesting information, but nothing concrete. Further investigation pointed me to possibly McAfee VirusScan Enterprise, which had recently been upgraded and was a different version to that running on the other servers.

To cut a long story short, McAfee have introduced 'Buffer Overflow Protection' into VirusScan Enterprise v8.0i, which if set to 'Protection Mode' seems to interfere with w3wp.exe and throw the processors to 100% - disable it and no problem.

So, if you're running VS Enterprise v8.0i and start seeing strange 100% CPU usage, check that you have 'Buffer Overflow Protection' disabled, or set to 'Warning Mode', which might also solve the problem - For me, disabling is the route I'm going...