I loved this movie. If you want a non-stop thrill ride, step right up.

And bring extra underwear.

If you want to know what was whispered at the end of the movie (after the credits), then read below.

SPOILER! DO NOT READ PAST THIS POINT IF YOU DON’T WANT TO SPOIL WHAT’S AFTER THE CREDITS.

According to the despoiler Cloverfield wiki, it’s saying “It’s still alive.”, but it’s being played back backwards, so it kinda sounds like “Help us” played forward. Creepy!

Xobni (inbox backwards) is an add-on for Outlook that seems to fill in all the missing spaces that Microsoft forgot about:

Looks pretty spiffy. I really want to get into the beta, and you probably do too if you use Outlook. Click this link to check it out:

I’ve been having really infrequent “random” blue screens/freezes ever since I got my new computer back in July. I finally tracked the cause to either be high disk I/O or high network I/O. I replaced my network card with a PCI-E Intel gigabit card, but that didn’t solve the problem. I was in Visual Studio the other day, and went to get latest on a project, and boom, blue screen.

It sometimes isn’t just a big blue screen of death, though. Other times it just freezes my entire operating system for 15–20 seconds, then it “catches up” with itself.

Looking at my Windows event log, I see a lot of entries like this:

Source: nvstor32
Event ID: 129
Level: Warning
Message: Reset to device, \Device\RaidPort0, was issued.

These messages seem to indicate a problem with my nVidia-based SATA chipset. Searching around “the Google”, I find other users in similiar situations. They all suggest turning off Native Command Queing (NCQ) in the nVidia drive controller’s properties:

I’ve done that now and rebooted, and it seems to have fixed the problem. Funny enough, under XP (on this same machine) I have never had the random lockups or event log entries, so it appears to be a Vista-specific problem.

So, who’s to blame? Is it nVidia? I’m running the latest nForce drivers for my chipset (nVidia 650i SLI MCP), which at the time of this blog entry is 15.08. Is it Microsoft’s fault? Are they doing something funky in the newer drive code that could be causing this?

Who knows. All I know is that I have to disable a potentially performance-helping feature in order to not crash my machine. Maybe Scott Hanselman’s run into this on his very similiar quad core rig? Oh well. That’s technology for you. As long as it’s not corrupting my data, I guess.

This is something that I’ve known for a while, but always seem to forget when it comes to actually implementing it in my code.

When catching an exception, most people catch it as a variable, such as “ex” and then just do a “throw ex” and throw that exception back up the chain. This is probably not what you want. When the stack trace/error information comes back from that exception, it will show as having occurred where your “throw ex” was. This isn’t really helpful if your “try” block contains a lot of code.

Instead, you should just simply write “throw”, without passing a specific exception. This allows the stack trace to show the original location of the error (instead of where you caught the exception and threw it again.) This information is much more helpful when debugging..

And now you know too!

I love this rendition; something very pure and calming about it.