File corruption on Windows XP freeze the whole OS

I just spent 8 hours tracking down a nasty problem on IE 8 that constantly caused my entire OS (Win XP SP3) to freeze after a few minutes of using IE. As a former MS employee who worked at MS for 9 years, I care a lot about Microsoft and want to help out whenever I can. I submitted the issue to Microsoft and I am posting it to help anyone who may encounter the same issue.

Basically, over last few days I found that my computer would start to freeze grandually after using IE 8 for a while. Typically, IE 8 would first stop responding first, then Outlook and Firefox would stop responding. Start menu would also freeze. Task manager would continue to work for a little longer. Cmd windows would mostly works longer. When that happens, I had no choice but force power off. In the last few days, I had multiple instances of this problem with increased frequency. Sometimes during reboot, the OS would run chkdsk and correct some bad file indexes, but the problem persissted.

Today I had enough of it and decided to track it down. I tried to remove many of my programs and stop various services and shell hooks but none worked. Finally I decied to uninstall IE 8 beta reluctantly. However, uninstall IE 8 made things worse because now IE7 would freeze the OS within 5 seconds. Eventually I found that if I log in as a different user and use IE (now IE 7) and things worked fine. So I ran"chkdsk /R" and it finally found clutsters in file \Document and settings\\Locals~1\TEMPOR~1\Content.IE5\index.dat. Note this fix was found on stage 4 of 5 of chkdsk. This should have been cautght before previous chkdsk that the system automatically ran after crashed, but apprently the system only performs "chkdsk /f" which does not perform step 4,5.

Anyway, I now recall that I had similar problem back in the days when XP first shipped while I worked at Microsoft. I think this problems could be better handled if system performed chkdsk /r instead of chkdsk /f when system repeately crash. In addition, the OS should handle such file corruption better when it happens. That can be done because the File subsystem, problems that aren't performing IO can still function and detect and monitor such issues.

Cheers,

Wei Zhu

A Prototype Facebook Widget

We at the Facebook Connect team are very happy to see the developer community’s interests in creating widgets for Facebook Connect. Widgets are very important for Facebook Connect because the developers community can make it very simple for thousands of web sites to quickly add Facebook Connect to their sites. In addition, our developer community would be able to create many more new features that we can do on our own.

Some people have expressed desires to enable Facebook Connect on Blogger but encountered some difficulties in creating a cross domain channel page using the sample HTML on a blogger site according Facebook’s developer wiki site. This is because all pages on a Blogger site share the same HTML template and there is no way to create a separate page with just the HTML page in cross domain channel page.

There is a workaround for this issue. I created a prototype Blogger widget to illustrate it. You can see the widget at work on this blogger site. You can also follow this link to add the widget to you Blog site. The principle applies to other web sites with limited ability to modify HTML/JavaScript support as well.

You are welcome to study the code for this prototype and freely copy/modify/distribute it for your use without any conditions.

How to Work Without a Separate Cross Domain Channel Page?

Facebook Connect requires a cross domain page on a site’s domain to enable that site to communicate with Facebook. The cross domain page really is just a very simple HTML page that loads a simple JavaScript code. Having a dedicated cross domain page that is fast to load and can be cached on browser client is desirable for performance. However, if there is no way to create a dedicated cross domain page with the minimum HTML markup specified in our dev wiki, we can substitute with almost any page on a web site as long as we can run the necessary JavaScript code on that page. For this prototype, we just use the same page where the widget runs as the cross domain channel page. My little trick is to signal its usage by adding a query parameter “fbc_receiver=1” in the url. For example, when this page http://funwithconnect.blogspot.com/2008/12/prototype-facebook-widget.html runs, we specify http://funwithconnect.blogspot.com/2008/12/prototype-facebook-widget.html?fbc_receiver=1 as the cross domain channel url. When Facebook Connect create a hidden iframe to http://funwithconnect.blogspot.com/2008/12/prototype-facebook-widget.html?fbc_receiver=1, the JavaScript code widget_loader.js will detect that by checking window.location and run the code normally used in a dedicated page.