Recently a few FeedDemon users reported CPU spiking when updating their feeds. After finding a feed which triggered the problem, I debugged my code and discovered that the CPU spike was actually happening in Microsoft's WinINet.dll (a Windows library which provides Internet-related functions). Specifically, the CPU load was jumping during a call to InternetReadFile - and the load never decreased the whole time FeedDemon was running. Not good.
Googling for info turned up this Microsoft KB article, which describes the problem as a bug in InternetReadFile. Luckily it isn't a bug that many people will run into, since it requires a specific situation involving "chunked encoding" and a server not closing a connection correctly. But for those who run into this bug, it's definitely annoying and it requires a solution.
The article mentions a possible workaround: use HTTP/1.0 rather than HTTP/1.1. Sounds simple enough, but another Microsoft KB article explains why that won't work. In short, the only solution is for customers to change their Internet settings, which is a PITA since we'd obviously rather resolve the problem without requiring any user action.
Now, I'm not going to criticize Microsoft for the fact that this bug exists - as much as programmers try to find and kill all bugs before a product is released, they're still a fact of life. Bugs happen.
But I am going to criticize them for how long this bug has remained unfixed. The KB article is dated October 2, 2003, so they've officially known about this bug for almost three years. This is a serious bug - it causes applications to stop responding or over-utilize the CPU, leading to crashes or decreased performance. In other words, this bug makes Windows developers look bad.
Microsoft, please fix this bug. You ship WinINet.dll with Internet Explorer, so you could include the fix with IE7. Windows developers need to know that they can rely on your APIs, and long-standing critical bugs in your APIs make us leery of relying on you.
Update: I just confirmed that this bug still exists in Windows Vista Beta 2.
Nick, have you posted something along these lines to our friends over at the IE blog?
Posted by: Jason J. Thomas | Friday, June 09, 2006 at 10:32 AM
He he. I was wondering when someone else was going to be hit by this. My reaction was pretty much the same as yours:
http://www.awasu.com/weblog/?p=213
BTW, don't even think about trying to change the user's HTTP setting. We tried it for a while and (upon reflection, rightly so) got spanked for it. It apparently breaks Windows Update under certain circumstances and can interfere with intranet logins.
Posted by: Taka | Friday, June 09, 2006 at 11:14 AM
Taka, thanks for letting me know I'm not alone here :) In your blog you asked people to install a specific upgrade which fixes this problem - how exactly did you fix it?
Posted by: Nick Bradbury | Friday, June 09, 2006 at 11:28 AM
>>> how exactly did you fix it?
I didn't. That upgrade turned off (in code) the "Always use HTTP 1.1 even if the program is saying to absolutely, positively, definitely, without fail, use HTTP 1.0" registry setting but a few people reported problems because of it. You can search our forums for more details (I'm not going to link to anything because some of it is somewhat less than complimentary :-)).
My research suggested that it would be safe to do this but I included a debug switch to disable it. In hindsight, I should've done it the other way around: leave the problem active and tell people how to fix it (manually) if it surfaced. It was partly a psychological issue since I came across it almost immediately after 2.1 had been released and I was frantic because I thought it was because of something I had done.
AFAIK, there's no way to fix this other than to ask people to manually turn off the HTTP 1.1 setting. Luckily, I've never seen it again.
Posted by: Taka | Friday, June 09, 2006 at 11:39 AM
The other option is to use something other than WinInet which is flakey at best. At work, we ended up using the rather excellent LibCurl to get around many issues with wininet.
Posted by: Dan | Friday, June 09, 2006 at 11:52 AM
Dan, overall I've been pleased with WinINet, and I've got an awful lot of code invested in it, so I'd hate to dump it at this point.
Posted by: Nick Bradbury | Friday, June 09, 2006 at 12:43 PM
Yeah, I've been having those kinds of issues with the latest build of FD. It not only spikes to 100% - but 100% across all four of my processors (double core Intel with HyperThreading). Not to mention, the update all feature "once an hour" doesn't seem to be sticking, but that may be an unrelated bug report.
Posted by: Chris Pirillo | Friday, June 09, 2006 at 03:19 PM
Nick, we're taking a look at this. WinINET has undergone major updates for IE7, so it's interesting that you're still hitting this.
Do you have any repro URLs which consistently reproduce this problem? In working on Fiddler (http://www.fiddlertool.com) I haven't encountered any major sites which prematurely close chunked bodies, so it would be great to understand where you're hitting this problem.
Thanks!
Posted by: EricLaw [MSFT] | Friday, June 09, 2006 at 04:01 PM
Thanks for checking into this, Eric. Here are two feeds I see the problem with:
http://www.beingkatie.com/wp-rss2.php
http://meyerweb.com/eric/thoughts/rss2/full
Posted by: Nick Bradbury | Friday, June 09, 2006 at 04:08 PM
Nick, I am so sorry this thing has caused you grief! For Vista, and going out with IE7 on XP/Win2K3, we have fixed a LOT of WinInet bugs, including a major cleanup of the cache.
As you noted, this particular bug can be difficult to reproduce, so I really appreciate the URLs. I reactivated the bug. Hope we can ask you for some help if we get stuck on it again.
If you're using WinInet or WinHTTP in your app, my team would be grateful if you could take some time to send us your input. Check out our blog for more on that.
You can also file bugs against WinInet (or any other of our components) via our connect site at http://connect.microsoft.com/wndp. Well-triaged bugs are always gratefully appreciated. For http client issues, it helps to make sure you can telnet on port 80 to the destination before shooting the WinInet messenger.
-David Powell
Product unit manager, Windows networking developer platform
Posted by: DavidPow [MSFT] | Friday, June 09, 2006 at 04:43 PM
Nick,
Long time ago I asked you if you were planning better support for Firefox, i.e., not to rely on Internet Explorer for displaying feed content. You said you were considering it, but it has never happened. Obviously, as pointed out here, the Internet Explorer is solution is not free of bugs; on the contrary, for years it has caused people a lot of grief without any solution to look forward to.
I hope you are still considering implementing Firefox as an alternative to IE.
Jeff
Posted by: Jeff | Friday, June 09, 2006 at 05:04 PM
Jeff, an embedded Mozilla has been available for quite some time - see http://nick.typepad.com/blog/2004/05/hidden_feature_.html
Truth be told, though, the embedded Mozilla engine is far more buggy than IE, which is why it's an unsupported feature. I may be annoyed at MS for the WinINet bug, but regardless, they've done a far better job than Mozilla.org at making it easy to embed their browser.
Posted by: Nick Bradbury | Friday, June 09, 2006 at 05:17 PM
David, thank you for posting here - I'm very pleased to hear that this bug has been reactivated. Please feel free to contact me about this (or any other) WinINet issue.
BTW, I've just subscribed to the WNDP feed and filled out the Web Client API planning survey.
Posted by: Nick Bradbury | Friday, June 09, 2006 at 05:21 PM
You're welcome, Nick, and thanks for taking the time on the survey. We DL'd FeedDemon and were able to cause the hang. Will drop you a line when we know more.
Posted by: DavidPow [MSFT] | Friday, June 09, 2006 at 07:35 PM
Thanks for the URIs, Nick! Yup, these servers are definitely violating RFC2616 by failing to send the required "0" which terminates the chunked body.
(These pages are even sending "Keep-Alive" headers, which obviously isn't going to happen since they kill the connection.)
We'll look into our handling of this invalid behavior.
Posted by: EricLaw [MSFT] | Friday, June 09, 2006 at 07:57 PM
I can't say for sure, since I'm not an expert in server behavior, but my guess is that the RFC2616 violation is happening because meyerweb has, of late, been just terminating connections without warning. I'll get half a page to load, and then it just stops. If the same thing is happening with RSS feeds, then I'd guess that the termination is so abrupt no terminating 0 is emitted.
I think this might also be why Safari keeps giving me "lost network connection" error messages, though again, that's a guess. And not somethinig you Windows guys probably care much about anyway.
I would definitely do something different with handling, EricLaw, though I'll put in a plea to PLEASE keep things in the realm of generating an error, even a nice descriptve one that users could share with site owners. And not spiking the CPU.
Posted by: Eric Meyer | Saturday, June 10, 2006 at 10:41 AM
Great to see MSFT taking this issue seriously. IE 7/Vista could be months away so a fix soon would be appreciated.
On the other hand FeedDemon has really blossomed lately. Well done Nick!
Posted by: Peter Tilbrook | Saturday, June 10, 2006 at 11:48 PM
Nick, sounds like Mozilla.org is behind the curve on a stable embedded capability--how about Opera? I've grown to really like Opera, very fast and clean--seems like approaching Opera (even to suggest they provide this capability, if they don't already) would give customers more options.
...and thanks to both Nick and Microsoft for hopping on this so fast!
(I have also experienced the CPU spiking periodically, but it seemed to "get better" when I uninstalled Windows Defender Beta 1--WD Beta 2 seems okay as far as the CPU spiking goes. Don't know if there's any "real" relationship between WD and the CPU spiking, but I did find the Beta 1 problematic.)
Posted by: David Sims | Monday, June 12, 2006 at 07:55 AM
I had no idea that Nick was this famous that Microsoft jumps in to fix the bug like that. So basically, Microsoft employees read your blog daily or was it the syndication that did it?
Posted by: jj | Monday, June 12, 2006 at 01:12 PM
Nick, thanks for highlighting the meyerweb feed as a problem.
I removed it from my list of feeds, and now I can enjoy feeddemon without the cpu spikes.
I'm a happy guy again.
Posted by: GW | Monday, June 12, 2006 at 03:03 PM
The meyerweb feed may have given some folks grief but it was helpful getting to the bottom of this thing. Definite bug in the parser code handling improperly formed chunked responses. Fix is pretty straight-forward and has FeedDemon running. Nick, can you please shoot me an email? We saw something else, while looking at this, which we wanted to run past you. Thx! -David
Posted by: DavidPow [MSFT] | Monday, June 12, 2006 at 05:01 PM
David, I'll follow-up by email.
Posted by: Nick Bradbury | Monday, June 12, 2006 at 09:13 PM
Just to close the loop on this thing, we are pretty certain we've fixed the underlying bug. Our WinInet team got to the bottom of the bug before the sites Nick referenced made their changes. I doubt the fix made it into IE7 beta 3 on XP, but it should be in the final version when IE7 releases and should be in RC1 of Windows Vista (unless something unexpected happens).
Posted by: DavidPow [MSFT] | Monday, July 03, 2006 at 06:59 PM
Can I share some resources with you?
Posted by: clifford | Thursday, July 06, 2006 at 01:00 AM