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.

http://www.atasteforthetheatrical.com/

It looks amazing. I saw it on the big screen tonight in front of I Am Legend, and I can’t wait to see the film next year.

Let’s put a smile on that face!

These are supposed international one-sheets. First one comes from Collider, the second comes from AlloCine. First heard about (appropriately enough) via FirstShowing. At first I thought it was fake (because just the Batman one was posted, and it just seemed strange.) But now I get the concept, after seeing the other “Joker” poster. Pretty darn cool, and whoever’s responsible for them did a great job.