Memory Could Not Be Read…

It seems I’m stuck in the realm of stupid software lately. Or rather stupid programmers.

Well, since I don’t seem to do anything creative these days (which by the way — it really pisses me off), I’d better not fight it anymore and just go with the flow.

I recently had to reinstall Windows on a Compaq nx9010. Despite the fact the CNET review states that it runs very cool, this particular one blew out heat like a steam locomotive, with the fan noise appropriately loud to complete the image. Other than that, it seemed to run pretty decent with a fresh installation.

Err… strike that. After one reboot prompted by the installation of some driver, winlogon greeted me with the following:

Pressing OK, Cancel, or the close button would promptly cause a BSOD (weren’t they supposed to be history starting with Windows XP?) As long as the error box was left open everything seemed to work just fine, but of course there was no way to give the computer back to the user that way. So I put my forensics gloves on and started digging through the pile of shit…

The problem description and resolution on the Microsoft Support page shed no light whatsoever.

For starters, the article was originally written for Windows 2000 and later edited to include a so-called “resolution” for Windows XP too. Then, the alleged cause:

This behavior occurs because the operating system does not allocate a large enough buffer for the maximum string length permitted. When the data is greater than the buffer size, the Winlogon service terminates abnormally and your computer generates the error message.

Well, wouldn’t it have been more honest on their part to just say: “We are very stupid“? OK, let’s move on to the resolution, since we’ve had our explanation of the cause.

To resolve this problem, obtain the latest service pack for Windows XP.

Really? I’m using Windows fuckin’ XP with integrated SP2! Even more, before seeing the dreadful error I had successfully applied all the updates proposed by Windows Update!

The Knowledge Base article just keeps getting better. From the Status section:

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the “Applies to” section. This problem was first corrected in Windows 2000 Service Pack 1.

Corrected the Microsoft way, of couse…

I was really busy that day, so I chose the easy way out and re-installed Windows (easy because of the great utility nLite, mind you, which allowed me to easily create a completely unattended install disc). Everything seemed just fine at the beginning. I have of course re-applied the updates, started to install the device drivers, then BAM! After one reboot, the horrible error box was back!

I’m going to cut it short now, but after the third installation I have managed to narrow the suspects circle to the device drivers, and then to the chipset driver downloaded from the HP support site! So for the fourth installation I’ve skipped this particular one, and installed the producer’s driver (Intel). Which, lucky for me, worked without a glitch.

The moral: my opinion about Microsoft’s programmers hasn’t changed a bit. It’s just that on my list of unbelievably unprofessional dudes at Microsoft I have added their Quality Assurance department, as well as Documentation Writers.

Well, to be fair actually, not all Microsoft programmers are morons.

For example, I have great respect for Mark Russinovich, the creator of SysInternals utilities that saved my ass on countless occasions. As a quick example, the great Process Monitor helped me solve a situation where Excel took 2 minutes to display its main window after starting, or to open a workbook after issuing the command. It turned out it was trying to write a temporary file in a folder under the user’s local account directory which for unknown reasons had erroneous permissions. And although the system responded with “Access Denied”, it kept trying for hundreds of times before giving up two minutes later!

But to be cheeky to the end, he’s a fairly new addition to the Microsoft’s team, after years of knowing the insides of Windows better than most of its creators. A kind of exception that confirms the rule :).

Cheers.