My wife’s computer was stuck in a Windows boot loop. We’d get the Windows 7 boot screen, and it would display a single pixel of the Windows 7 logo, then reboot itself endlessly. Booting in safe mode made it fail on classpnp.sys.
Any number of things can cause this, and it usually happens after you swap a motherboard. Enabling AHCI turned out to be the fix. Enabling AHCI also can be easier said than done, but I figured it out. She’s running Windows 7 (for now) but these same tricks should also work for Windows 10.
What is SSD native command queuing (NCQ)? Think of it as a technology to make SSDs more efficient.
I had trouble installing Windows 7 from USB on an Asrock Q1900M motherboard. It was the most difficult time I’ve had in years. Creating a bootable USB stick from my Win7 DVD went flawlessly, and the Asrock booted off it just fine by hitting F11 to pull up the boot menu, but then Windows prompted me for a driver, and when I navigated to the drivers directory that Asrock provided, none of the drivers would load. The mouse didn’t work either, and the only reason the keyboard worked was because I still use PS/2 keyboards.
The solution was to go into the UEFI, dive into the USB configuration, and disable USB 3.0. After I did that, Windows could see the USB drive and other USB devices just fine. This issue is likely to get more common as time goes on.
Mechbgon.com, the same place that published the outstanding guide to application whitelisting I mentioned last week, also has a guide to general security when building Windows PCs.
I think he overvalues UEFI and Internet Explorer 10, but if everyone followed his advice, there’s no doubt in my mind we’d be much more secure than we are right now. Although I mildly disagree on a couple of points, he has some outstanding advice in there.
The guide hasn’t been updated for Windows 10 yet, but most of what he says, if not all of it, will still apply and won’t be all that different to set up.
In the wake of Truecrypt’s sudden implosion, someone sent me a link to this curious blog post. I can see why many people might find the timing interesting, but there are a number of details this particular blog post doesn’t get correct, and it actually spends most of its time talking about stuff that has little or nothing to do with Truecrypt.
What’s unclear to me is whether he’s trying to say the industry is deliberately sabotaging Truecrypt, or if he’s simply trying to make a list of things that are making life difficult for Truecrypt. His post bothers me a lot less if it’s just a laundry list of challenges, but either way, the inaccuracies remain. Read more
A security professional’s nightmare happened to AMI this week. Tons of confidential data, including the source code for the UEFI BIOS for Intel Ivy Bridge-based systems and an AMI-owned private key for digital signatures, turned up on a wide-open FTP server for all comers to download anonymously. This AMI BIOS breach has numerous implications.
The implications are nearly limitless. To a malware author, this is like finding a hollowed-out book at a garage sale stuffed with $100 bills with a 25-cent price sticker on the front. If you’re a budding security professional, count on being asked in job interviews why you need to protect confidential information. The next time you get that question, here’s a story you can cite.
Rupert Murdoch doesn’t understand the difference between piracy and linking. So I’ll explain it in terms any middle-school-aged kid should be able to understand.
UEFI is a technology that forces a computer to only load a digitally signed operating system. This has some security benefits, as it makes parts of the operating system unbootable if they become infected, since the viruses won’t be digitally signed by a reputable vendor.
Great idea, right? From a security perspective, absolutely. The more attack vectors for viruses we can eliminate, the better off we’ll be. But Microsoft’s policy on ARM systems shows how it can be abused.