Site icon Nick Bradbury

Microsoft, Please Fix this WinINet Bug!

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.

Exit mobile version