Category Archives: Windows

Windows 2000 0x0000007B INACCESSIBLE_BOOT_DEVICE

With luck, you’ll never need any of the information below. If you do, (a) you have my sympathy, and (b) you’re welcome!

One of my clients has an aging Microsoft IIS installation comprising a variety of Windows 2000 & 2003 servers (SQL, IIS, Domain Controller, File Server, Linux VMWare) running on a mixture of Dell server hardware.

The main IIS installation runs on Windows 2000 Server on a Dell Poweredge 1950 using a Dell SAS 5/iR disk controller, to which are connected two SATA drives running independently (not RAID-ed). In July, the controller card failed catastrophically, rendering the server useless.

Fortunately, though this is old hardware, we were able to source a replacement controller card on eBay. Less fortunately, when I installed the new controller and attempted to boot from it, the server crashed a few seconds after displaying the Win2K splash screen with the dreaded blue screen of death:

Not great. After some investigation, I realised that though the replacement looked identical in all respects to the failed card (even the discrete components were positioned identically on the PCB), it had a slightly newer BIOS. This, it appeared, was sufficient for Windows to treat the controller card as a new, unrecognised device.

If you have to replace a disk controller on a Windows server, the usual advice is to install the new controller first, allow Windows to detect it, install any needed drivers, then — and only then — shut down, remove the old controller, and connect the hard drives to the new controller. Windows then has the needed drivers installed to allow it to boot Windows successfully.

Of course, in this scenario we didn’t have that luxury – the old controller was dead, so Windows wouldn’t boot at all. We needed to somehow install the updated drivers on the Windows system disk offline.

This turned out to be … tricky! Here are a few of the things I tried before figuring it out. (Needless to say, I copied the disk onto a fresh drive and performed my experiments on the copy. This ensured the original was always available if I needed to start over.)

1. Update controller drivers – FAIL

I downloaded updated drivers for SAS 5/iR controller from Dell’s website (here), extract drivers, manually copy driver files to Windows c:\winnt\system32\drivers folder, overwriting the older versions with the same name. This made no difference at all.

Then I discovered the C:\WinNT\NLDRVS sub-folder which holds the core third-party drivers used by Windows before the whole plug & play subsystem is up and running. This contains a series of numbered sub-folders, one for each driver. Again, I updated this to use the latest versions of the driver files, and again it made no difference.

2. Repair Windows Installation – FAIL

Next, I attempted a Windows 2000 repair, which was a lot harder than I expected.

After tracking down the original Windows 2000 installation CD, I was unable to press F6 to install additional drivers from floppy (remember that?) because the PowerEdge 1950 has no floppy drive. Windows won’t recognise a USB flash drive at this point either.

There are hardware floppy emulators around that will accept a USB memory stick and present the contents as a floppy drive using the old 34-pin floppy cable standard. Unfortunately, the PowerEdge doesn’t have an internal header to connect such a device to. You can also buy floppy drives with a USB interface but I didn’t have one of those to hand (or any floppy disks to use with such a device).

Eventually, I discovered nLite, an excellent utility that lets you build a custom Windows installation CD which includes your selection of third-party drivers, service packs, and other customisations. I also found WinSetupFromUSB which lets you install a Windows installation CD on a USB stick in such a way that even the Windows 2000 Installer can successfully boot from it. (Some deep magic is used to make this work).

Between these, I was able to create a slip-streamed Windows 2000 SP4 installation CD with the latest Dell SAS 5/iR drivers pre-installed. Booting with this, I could get to the Repair Windows menu, find my Windows installation, and let the automatic repair try and fix it.

This was also unsuccessful – the automatic repair didn’t notice that the drivers it had booted with were different to the ones pre-installed on the original Windows disk, so it didn’t update them.

3. Perform an in-place Windows upgrade – Partial Success

By now, having spent a lot of effort trying various things, I figured there was only one thing for it – perform an in-place upgrade of Windows 2000 using the process outlined by this TechRepublic article. This is essentially a new Windows installation on top of the existing install. Windows is smart enough to replace the system files with fresh versions while preserving all existing third-party software and user profiles.

In principle, this allows you to resolve any hardware-related Windows glitches without having to re-install all your application software. This sounded good, because the mission-critical software running on this particular server is complex and the original designers and implementers were long since gone, leaving no documentation behind them. Recreating it from scratch on a clean Windows installation would have been unthinkable.

The re-install process went smoothly, albeit slowly, and once completed, Windows booted successfully. Hurray! Job done, right?

Well, not quite. The original installation had somehow ended up with the WINNT folder on E:\ while the tiny 2 GB FAT16 boot partition was on C:\. After the re-install, WINNT was located on C:\, along with Program Files and other system folders. This, of course, broke lots of things.

I was able to fix most of them by adding a scheduled task to SUBST drive E:\ to drive C:\ at startup, which made most of the system much happier. A few services started before this remapping occurred, and I located those in the Registry and updated their path references by hand. Yes, this is all ugly and horrible, but by this point, I just needed to get things working by any means!

(Word to the wise: be careful with removable USB backup drives, which usually grab the first available drive letter. If that happens to be E:, it stops the drive letter mapping working correctly and you’re back to square one.)

Microsoft Office was still a little unhappy, but became much happier after I carried out a Repair Install. I also had to re-assign appropriate drive letters to some of the data partitions.

Finally, after all of this …. IIS started correctly, websites were accessible, and all was right with the world! Hurray, again!

4. When is a success not a success?

Not so fast. One of the critical components of the website was the ability to upload formatted Word documents which were then automatically converted to XML for processing by the content management system. This wasn’t working correctly; in fact, it wasn’t working at all.

The issue seemed to be related to a custom COM object that had been developed for the project, and a method in this object was failing during the conversion of the Word document. Everything I could see indicated it was somehow connected to the Microsoft Office installation (since presumably Word itself was involved in the conversion).

I spent more than a week trying to get to the bottom of this. I re-registered all COM objects and relevant DLLs, checked the system and application logs for errors, enabled IIS debugging, etc – all the usual things you would expect. When I dug deeper, using Microsoft’s ProcMon tool, the issue seemed to be related to an instance of Internet Explorer that was launched during the conversion.

After many hours pouring over ProcMon, IIS and Event logs, checking for unexpected failures buried in the midst of the many, many expected failures, I had to admit defeat. The server was working, but it wasn’t working reliably. It also had a tendency to hang random services during startup, and Windows Update refused to start, neither of which inspired confidence.

5. The Easy Way

By this stage, and with the client’s patience starting to reach its limits, I decided to use the knowledge gained working through the above to have another go, starting from scratch with the original disk again.

A chance remark on a discussion forum about SCSI adapter BIOS signatures being used by Windows to help identify the correct drive led me to a rarely visited part of the Windows 2000 registry known as the CriticalDeviceDatabase.(This no longer exists on modern versions of Windows).

Further research brought me to Michael Albert’s invaluable page on manually adding a mass storage device to an existing Windows installation. As one commenter rightly said, “Never delete this page!” The information it contains is invaluable, and not easily found elsewhere. So, thank you Michael!

The registry key HKEY_LOCAL_MACHINE / System / Control / CurrentControlSet / CriticalDeviceDatabase contains a series of sub-keys for all the devices needed to boot Windows. Third-party controller cards are referenced here by their PCI vendor, device and (crucially) subsystem code.

First, I needed to get the PCI code for the SAS 5/iR controller. On most Windows installations, you can visit Device Manager, open the Properties pages for the controller, and under the Details pane select Hardware IDs. However, on Windows 2000 this information isn’t so easily available. Instead, you need to run MSINFO32 and find the controller there, usually under SCSI devices.

When I ran MSINFO32 on my flakey Windows re-installation, the SAS 5/iR entry looked like this:

Checking Regedit on the same machine, I could see the following matching entry in the registry:

[HKEY_LOCAL_MACHINE\CurrentControlSet\Control\CriticalDeviceDatabase\pci#ven_1000&dev_0054&subsys_1f091028]
"Service"="SYMMPI"
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"

However, there was a second, almost identical, entry:

[HKEY_LOCAL_MACHINE\CurrentControlSet\Control\CriticalDeviceDatabase\pci#ven_1000&dev_0054&subsys_1f061028]
"Service"="SYMMPI"
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"

The only difference is the subsystem code, which has changed from 0x1f061028 to 0x1f091028. I concluded that the additional entry was the one used by the old controller card, and that it had survived the in-place Windows upgrade. For reasons best known to themselves, Dell must have revised the sub-function code when they updated the controller’s BIOS, possibly to provide an easy way for the driver to identify hardware with additional capability or some obscure hardware fix.

I went back to the original disk and copied the registry System hive from \WINNT\SYSTEM32\CONFIG\SYSTEM to my work computer, then loaded it into RegEdit by selecting HKEY_LOCAL_MACHINE, then using Load Hive and entering a temporary sub-key name (W2K-Recovery) to allow me to access it.

Drilling down there, I could see registry keys for ControlSet001 and CurrentControlSet002 but no CurrentControlSet. This is normal when editing an offline registry hive — CurrentControlSet is created dynamically by the operating system but is not part of the hive itself. Instead, I checked under the Select key which confirmed that the ‘Current‘ selection was set to 1 (indicating CurrentControlSet001). And sure enough, under CurrentControlSet001 / Control / CriticalDeviceDatabase, there was an entry for subsystem 0x1f061028 but not 0x1f091028.

I made a fresh clone of the original Windows drive, then manually added the CriticalDeviceDatabase entry for 0x1f091028 without changing anything else. (Again, I performed this by loading the System hive offline into RegEdit on my main work PC, making the modifications, then unloading it again and copying it back to the WINNT folder on the target disk.)

After this, the new drive booted straight into Windows with no issue. As it was the original Windows installation, everything was back to exactly the way it was before the disk controller died.

As with everything Windows related, an ounce of knowledge is worth a pound (or stone!) of experimenting! If you’ve made it this far, hopefully the information above will save you some wasted time and effort.

Default route keeps vanishing on Windows 10

A number of my PCs have a persistent problem with the default route disappearing when the system is restarted. Since I use Remote Desktop to control most of these machines remotely, it’s rather annoying; if the PC reboots, I no longer have remote access.

I hoped it would correct itself when I upgraded to Windows 10, but it’s still happening. In fact, it’s much worse — Win10 feels it has carte blanche to reboot to install upgrades without asking my permission first and when it does, I have to visit the PC to reset the default route, or find someone to do it for me.

This all started a year or two ago, with a particular Windows 7 update (I’m not sure which one). The only common factor is that all the affected PCs use static IP addresses with a manually configured default route. It doesn’t occur when DHCP is used. Most of them also have multiple network adapters.

While I have a workaround using a startup script to manually re-add the missing route, it’s awkward to run this with the elevated command privileges needed to change the default route.

Google suggested various solutions, including:

  • Editing the network adapter and switching it to DHCP, exiting, then going back in and switching it to static again. This needs to be done twice to work.
  • Resetting the TCP/IP stack (by running netsh int reset from an elevated command prompt). This is quite drastic.

I tried both of these but neither fixed it for me.

Today, I found something that *did* work. I’m recording it here in case it helps someone else.

  • Run RegEdit and navigate to Computer\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
  • Go through each of the interface GUIDs in turn.
  • One of them will have an IPAddress field matching your main network interface. On this one, confirm that there is a REG_MULTI_SZ field called DefaultGateway containing a single text line with the IP address of your default route. If it’s not there, create it. Similarly, there should be a DefaultGatewayMetric field, also REG_MULTI_SZ, containing the single string ‘0’.
  • On all the other interface GUIDs, delete any DefaultGateway and DefaultGatewayMetric fields entirely.

After completing these steps, restart your PC. The correct default route should now be configured.

Windows 7 filesharing limit

I have a Sonos music system at home, and it’s great — I use it to make music stored on my Windows 7 Media Center system accessible throughout the house, among other things.

One of the nice things about Sonos is that it’s really easy to setup. I just point its music library at a network Share on my Media Center system and it automatically keeps everything indexed and up to date. Every now and again, however, I go to play a music track and I’m told it can’t find it. Specifically, it can’t access the file using the network share path, even though the file is there and I can play it fine locally on Media Center.

Recently, I finally figured out what was going on – a simple but not-very-well-publicised limitation built into Windows 7 Home Premium which restricts the resources used to manage network file shares. If you have a number of PCs in your house, as I do, all accessing shares on a particular PC, you can run out of resources. When this happens, any further attempts to access the share will fail. Not good!

Happily, there is a straightforward fix – Alan Lamielle describes it on his blog.

The short version is to find this registry key on the Windows 7 machine:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache

and change the following registry key from ‘1’ to ’3′:

HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Size

Then restart the ‘Server’ service (or restart Windows itself if you prefer) and everything will be back to normal again.

Since making this change, I haven’t had a single recurrance of the problem – happy days!

Fixing Visual Studio 2010 keyboard text selection

Short version: does shift-selecting blocks of text in Visual Studio, Word, Outlook, Notepad or other Windows apps mysteriously cancel your selection from time to time? The problem may be to do with your keyboard’s PS2 to USB adapter. Skip to the end for an easy fix.

I spend a lot of time editing text. Sometimes, this is in Word or Vim, but mostly it’s in Visual Studio’s code editor. So, when something I’m used to breaks, something I do so often that it’s hard-wired into my fingers, it gets my attention.

I often select blocks of text by holding down Shift, holding Cursor Down until the block of text has been selected, and then pressing Cursor Up to move back up a line or two. When I’m working quickly, I often press Cursor Up before releasing Cursor Down. And until recently, this would work perfectly – the Cursor Up stroke would take precedence over the repeating Cursor Down and things would smoothly come to a halt.

I started a new project recently which needed Visual Studio 2010 (I’d been using VS2008 until then). I installed VS2010 on a fresh development PC and pretty quickly noticed that whenever I tried to select a block of text, it would end up unselected again. Selecting it a second time, more carefully, worked fine. During periods of heavy editing, I might do this operation several times a minute, so this was DEEPLY AGGRAVATING.

I figured out that things worked fine as long as I released Cursor Down before pressing Cursor Up while making the selection. Unfortunately, training my fingers to do this was a lot harder than I expected, so the problem continued. Since I was only working on the VS2010 PC a couple of days a week, I was able to live with it. I checked Google, of course, but nobody else seemed to be suffering from this problem. I even used the Spy++ development tool to monitor keyboard messages going to the Visual Studio window, but nothing seemed amiss.

Over Christmas, I rebuilt my home office, incorporating some new monitors, KVMs, moving things around, etc. Soon after, I noticed the problem had spread to my main development PC. Worse, it turned out that applications other than Visual Studio were now being affected. Even Visual Studio 2008, which had been fine up until now, was suffering, as was Notepad, Outlook, and pretty much any application that accepted multi-line text input!

What was going on here? I checked a couple of my other PCs — some of them were doing it, some of them not. Was this some sort of strange new virus with an unanticipated side-effect? Several full virus checks (all clean) suggested not. Both Windows 7 and Windows 8 systems were showing the problem, but I had other similar systems that were clear, as was Windows 2012. More intriguingly, when I connected to an afflicted system using remote desktop, the problem vanished. I even considered the issue might be related to a keyboard switch I was using to share a single keyboard & mouse between several PCs, but where I had such a setup, some of the PCs on the switch were fine, others were not.

At this point, I reckoned the cause must be some system utility I had installed on some but not all of the PCs, or possibly a Windows update. An audit of all such software didn’t point to any culprits, however. And the problem continued to sit there, annoying the heck out of me on a daily basis.


Until finally, today, a break-through! I decided to connect an old PS/2 keyboard to my main PC at the same time as the USB KVM switch I was using day-to-day — and using the old keyboard, the problem didn’t occur! I then connected the PS/2 keyboard to a USB port, using a cheap PS2 to USB adapter, and the problem returned. It was something to do with the KVM after all.

The next step was to go back to Spy++ again and do some A/B comparisons. I used Notepad as my test application — it’s so simple that I figured there would be very little noise to get in the way. (I briefly had no output from Spy++, until I realised it could only monitor 32-bit applications on my Win7/64 PC; I fixed this by copying the 32-bit version of Notepad.exe across from a Win7 x86 system and monitoring that.)

Here’s the pertinent output, showing the key sequence SHIFT, Down (held down to repeat several times), Up, release Down, release Up.

First, with the keyboard connected via USB:

P WM_KEYDOWN nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:0 fUp:0
P WM_KEYDOWN nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:1 fUp:0
P WM_KEYDOWN nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:1 fUp:0
P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:0 fUp:0
P WM_KEYUP nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:1
P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:0 fUp:0
P WM_KEYUP nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:1
P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:0 fUp:0
P WM_KEYUP nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:1
P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:0 fUp:0
P WM_KEYUP nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:1 fUp:1
P WM_KEYDOWN nVirtKey:VK_UP cRepeat:1 Code:48 fExtended:1 fAltDown:0 fRepeat:0 fUp:0
P WM_KEYUP nVirtKey:VK_UP cRepeat:1 Code:48 fExtended:1 fAltDown:0 fRepeat:1 fUp:1
P WM_KEYUP nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:1

Now the same sequence, using the PS/2 keyboard connected directly to the PS/2 port:

P WM_KEYDOWN nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:0 fUp:0
P WM_KEYDOWN nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:1 fUp:0
P WM_KEYDOWN nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:1 fUp:0
P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:0 fUp:0
P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:0
P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:0
P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:0
P WM_KEYDOWN nVirtKey:VK_UP cRepeat:1 Code:48 fExtended:1 fAltDown:0 fRepeat:0 fUp:0
P WM_KEYUP nVirtKey:VK_UP cRepeat:1 Code:48 fExtended:1 fAltDown:0 fRepeat:1 fUp:1
P WM_KEYUP nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:1
P WM_KEYUP nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:1 fUp:1

There are two significant differences: the USB input seems to repeat keys by continually releasing and re-generating the keystroke (even though I had the Down key held down continually); more significantly, it generates an up-stroke for the Shift key as soon as I press Cursor Up (or indeed any other key, I discovered), before generating the Up keystroke — essentially, the keyboard was not supporting N-key-rollover when connected via USB.

This second point is what was causing the problem, since if you select a block of text using Shift and then press Up on its own, it does indeed cancel the selection.

Okay, so now we have the cause – how to fix it? I knew from previous testing that a genuine USB keyboard didn’t seem to exhibit this problem, so it must be something to do with my PS2 to USB adapter (actually, two different types, both with the same problem). I speculated that it might have something to do with the keyboard repeat speed — perhaps Windows was simulating repeated keys in the USB driver if it thought the attached keyboard couldn’t handle this itself, or perhaps the PS/2 keyboard’s repeated codes were being remapped by the USB converter cable.

Next stop was to Control Panel -> Keyboard -> Speed where I tried setting the keyboard repeat speed to both its slowest and fastest setting. Amazingly, either setting fixed the problem completely! It seems that all you need to do is set the repeat speed to something other than the default; this magically makes things start behaving properly.

To confirm, I repeated my test with Spy++ and sure enough, the USB-connected keyboard is now correctly sending repeated KEY_DOWN codes and no longer sending a KEY_UP for Shift in advance of the Up keystroke being pressed. My guess is that this is a quirk of the built-in Windows USB keyboard driver, rather than something in the device itself, since identical behaviour occurred with two separate PS2 to USB converters.

So problem solved: I had adjusted the keyboard speed setting on some of my PCs, but not on others which is why the problem appeared to be so random.

Outlook 2003 ate my mail

Yesterday, my Outlook 2003 hit the 2 GB limit on its PST file, and almost caused me to lose some important email.

To make me feel better, I’m describing the circumstances here. While I doubt anyone else affected will read this before suffering the same fate, they may at least gain some comfort after the fact from knowing they are not alone…

Anyway, the scenario goes like this. Outlook 2003 has a documented 2 GB limit on PST files (i.e. your Inbox and direct sub-folders). Unlike earlier versions of Outlook, which would happily corrupt your PST file with no warning if you exceeded the 2 GB limit, Outlook 2003 now traps this and (eventually) displays an error message saying the file is full.

There are two side effects that are not so obvious. The first is relatively benign: any messages in your outbox remain there after successful transmission, because there was no room to move them to Sent Items. Thus, you mistakenly think they haven’t been sent for some reason and waste time trying to send them again; the recipient often ends up with multiple copies.

The more serious bug, and the one that really annoyed me, is that when Outlook downloads new messages, it realises it has nowhere to store them … and just throws them away. My account is configured to leave messages on the mail server for two days after download, but I expect most users stay with the default account settings, which delete messages as soon as they are downloaded. Such users would likely not even be aware that they had lost mail, since it is irretrievably gone, with no record that it even existed. Certainly, Outlook gives no indication that anything is amiss.

Because this happened to my wife a couple of months ago, I knew to check my mail server’s webmail interface for lost messages, and sure enough, there were several sitting there. When I freed up space on Outlook and downloaded my mail again, it happily ignored those messages, since it considered them already fetched, even though it had discarded them at the time.

Unfortunately, I forgot to check my secondary account’s webmail interface as well, so only became aware of yet more missed messages when someone followed up to see why I hadn’t responded.

Come on Microsoft, how hard would it have been to do this right??

(I’d upgrade to 2007, but I can’t stand the new ribbon strip.)

Vista audio glitch on Sony Vaio V505CP

My personal laptop is a Sony Vaio V505CP. It’s almost five years old, but after upgrading it to 1.5 GB RAM and a 160 GB hard drive, it does a good job of running Windows Vista SP1. I use it mainly when I’m out on consulting jobs or travelling, so I don’t need anything more powerful.

A month or two back, I noticed that whenever I played music, the audio would glitch every 20-30 seconds. The mouse pointer also froze briefly during the glitches. This was something new — it was working fine after the original upgrade to Vista SP1. Today, I finally got around to investigating the cause.

For those in a hurry: the culprit was NDIS.SYS, the network driver. Simply turning off the built-in wireless adapter (easily done with a switch on the front of the Sony’s case) made the glitch go away. I can live with this for now, since I rarely use wireless and stream music at the same time; normally, I leave the wireless enabled all the time, just in case I might need it, but it’s not a big deal to turn it off.

So how did I figure this out? Here are the steps I followed, including dead ends (the journey is often as interesting as the destination).

My first port of call was Windows Task Manager. I usually start here, simply because Task Manager is standard on every Windows PC. In this case, it showed a big CPU spike whenever the glitch occurred, but unfortunately, Task Manager itself froze during the glitch so I couldn’t identify what process was responsible.

The next tool to try was Process Explorer from SysInternals, a wonderful tool for all kinds of system probing. It includes a dummy task entry for DPC (Deferred Procedure Calls) and so I could see that during glitches, DPC was particularly active, responsible for almost all the additional CPU usage.

Deferred Procedure Calls are used whenever a process needs to make a system call, but the system is busy doing something important like handling an interrupt. The system call is queued until the interrupt completes, and all outstanding calls are then executed in sequence — hence the brief jump in CPU activity.

Some Googling brought me to a handy tool called DPC Latency Checker, which graphs DPC usage over time. Using this confirmed the theory:

DPC Latency Checker graph

The red peaks indicate unusually long DPC latencies, which will cause system problems. Unfortunately, the checker didn’t tell me the cause of these, but I knew it was probably a badly written device driver. The checker’s website suggested using Microsoft’s RATTv3 developer tool to identify the culprit.

I hadn’t come across RATTv3 before, but it’s very useful — if you’re running Windows XP, that is. It records the latency of each and every device driver’s interrupt calls, correlated over time, and identifies the bad ones for you. Unfortunately, it doesn’t work too well under Vista.

Back to Google, where I found a thread suggesting Microsoft’s new Performance Toolkit as a good Vista alternative. This does everything RATTv3 can do, and a lot more besides.

Update Dec 2015: this is now part of Microsoft’s Windows Assessment and Deployment Kit (ADK) — it still works on Windows 7, despite Windows 8.1 references.

One thing to watch out for: after installing the toolkit, all the files end up in “C:\Program Files\Microsoft Windows Performance Toolkit”. I suggest copying them to C:\XPerf for convenience, since the installation folder is not added to the system path automatically.

After installing, you can begin a new capture by opening a command prompt in the toolkit folder and typing:

   xperf -on DiagEasy

to begin tracing. Then let the system run for a minute or two, until the glitch has occurred. Next, turn off tracing and convert the results to a file suitable for viewing:

   xperf -d trace.etl

Finally, view the accumulated results:

   xperf trace.etl

Pretty easy! Doing this produced a summary page with a ton of detail, most of which I didn’t need (CPU usage, disk i/o, etc.) The thing I was interested in was DPC activity, which it showed as a graph like this:

XPerf DPC summary display

The peaks in the graph show unexpectedly high DPC levels. By selecting one of those peaks and right-clicking, I was able to display a summary of all the driver activity that had contributed to the peak:

XPerf DPC summary of device activity

From this, it was clear that NDIS.SYS was the culprit, with a worst-case latency of more than 200 ms. (I repeated the test several times to confirm this, and it was consistently in top place.)

So mystery solved. From here, it was an easy step to try disabling the network adapters to see if that fixed things — and turning off the wirless adapter did the trick.

So when I have a chance, I’ll upgrade my wireless driver and hopefully that will sort it out permanently. For now, though, I’m just glad to have properly working audio again.

Windows Vista select-all bug

I’ve been using Windows Vista for a few months now, and am still finding that for every nice new feature I like, there is a change of behaviour or missing element that I dislike just as much. Ah, progress…

Last night, however, I encountered a new bug which is both minor and infuriating: the ability to select multiple files in Windows Explorer vanished. Using the mouse to drag-out a selection box, holding down Shift or Control, and even trying to choose Select All from the Edit menu are all disabled. It’s hard to describe just how annoying it is not to have this simple capability.

It turns out this is a well known Vista bug, first reported back in the Vista Beta days, and there are three solutions. Two are well-documented, the third is much more difficult to find. Naturally, the third solution was the one that I needed.

For convenience, here they are (in order of simplicity).

1. Go into Tools -> Folder Options -> Views and choose Reset Folders (also available under “Organise -> Folder & Search Options”. You may need to do this from within multiple Explorer Windows before it finally works.

2. Alternatively, run RegEdit and delete all keys under this one:

HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell

(i.e. Bags, BagsMRU, and MuiCache) in their entirety. Do this with no Windows Explorer windows open; ideally, with Windows Explorer killed in Process Manager before you delete the keys.

3. When neither of the above two methods works, run this FixSingleSelect VBScript and it will sort it out – at least, it did for me.

I’m frankly stunned that Microsoft have (a) allowed a bug with such wide-spread impact to make it through to final release, and (b) not issued a patch to address the problem.

Fixing Windows XP’s sluggish behaviour

ICPUG is one of the oldest computer organisations in the UK, having recently celebrated its 25th anniversary. Almost every year since around 1992, I’ve attended the annual ICPUG computer weekend at the Queens Armes hotel in the village of Charmouth on the Dorset coast.

I’m just back from this year’s event, which was as entertaining as ever (talks ranged from helicopters to pure maths to safe-cracking in Nigeria, and there was even some computing thrown in for good measure). One of the most useful things I came away with, however, was a simple Windows XP that can dramatically improve responsiveness on many systems.

The Start menu on XP has a Documents sub-menu that conveniently lists the last 10 or so documents which have been worked on – very handy if you want to go back and edit a recent file. XP creates this menu from the most recent document shortcuts from the hidden ‘Recent’ folder in your User profile.

However, XP has no mechanism to automatically empty the Recent folder; instead, the more folders, files and documents you open, the more shortcuts accumulate here. On my own system, there were about 1600 shortcuts listed (including many duplicates), dating back to 2004.

Simply emptying out this folder can produce a notable improvement in response speed for things like opening new browser windows, double-clicking document files, and even opening disk folders. I tried it on my system, and the effect was immediate – it felt as fast as a brand new XP installation again.

Because the folder is hidden, the easiest way to get to it is to select Run from the Start menu, then enter:

%HOMEPATH%\Recent

as the command to run. This will open the Recent folder and you can see how many shortcuts are listed. Then a simple Select All followed by Delete will get rid of them for once and for all.

Credit for this tip must go to Brian Grainger, webmaster of the ICPUG UK site; thanks Brian!

(As a final footnote, the Queens Armes has been sold to new owners as of May 24, 2007, and I believe the name will be changing to Abbotsville or Abbotshead.)

Why Windows Vista is not written in .NET

I recently came across an article at security website Dark Reading which explains why Vista isn’t written in .NET.

There are a few different reasons given, but the main one is that Microsoft have a lot of hardcore C++ OS programmers who didn’t want to switch to C#. Because C# is type-safe, it’s a lot harder to do some of the standard C tricks of peeking and poking memory locations, tweaking bits in registers, etc.

This is a shame, because while that type checking can be frustrating at times, it does give an awful lot of protection from malicious coding techniques. Given the rate at which Microsoft publishes Windows Security Updates, you’d have thought they’d be very keen to adapt a more secure computing environment.

Another reason given was performance: since .NET code is pseudo-interpreted, it is not as efficient as native C/C++ code. That’s a red herring though – my experience with .NET has been that it runs more than fast enough for almost anything you’re likely to do with it. Like any environment, you can easily write bad code that runs like a dog; you can also write good code that runs very fast indeed.

And as if to prove my point, the current non-.NET betas of Vista run incredibly slowly, at least on my Athlon 2400 system with 1 GB RAM and a very fast Radeon graphics card. Intel must be rubbing their hands with glee…

WinAmp, Quicktime and Internet Explorer

I use Winamp as my default MP3 player for Internet Explorer. Every now and again, Apple’s Quicktime player seems to hijack the file association, so that when I download MP3 files off the web, they play using the Quicktime embedded media player (which I dislike).

None of the obvious ways of undoing this hijacking seemed to work. Today, however, I came across a method that does work:

  • Load Microsoft’s Windows Media Player
  • Under Tools -> Options -> File Types, select MP3 Audio File as one of the filetypes used by WMP and hit Apply. This does some magic that unhooks Quicktime from Internet Explorer and replaces it with Windows Media Player.
  • Now if you re-run WinAmp and tell it to reregister its filetypes, it will subvert the Windows Media Player settings, and it will once more become the default MP3 player for Internet Explorer.

Simple when you know how…