Eddy's occasional random thoughts

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.)

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:

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.

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:

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:

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.

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.

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.)

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...