12/16/2000

Last Updated on April 18, 2017 by Dave Farquhar

Troubleshooting Windows NT and Outlook. This one had me totally stumped. We have a PC that’s always been a little flaky, but very recently Outlook just stopped working reliably. Access violations every 5-20 minutes, always at the same address, became the norm. In addition, it would claim to run out of memory every time you tried to read anything other than a plain-text message.

I traced the latter problem to a corrupt normal.dot file; he was using Word as his e-mail editor and as his format for fancy messages.

Finally, I coaxed another error message out of it while logged in with an administrative account: Unable to find or register vbscript.dll. Fine. Time to uninstall, run Eraser 97 to get rid of the last of those bits, then reinstall both Office 97 and Outlook 98.

Vbscript.dll still didn’t register, so I grabbed a copy off a working PC, dropped it in WinntSystem32, and issued the command regsvr32 vbscript.dll to register it. It took.I launched Outlook 98, Word 97, and Internet Explorer 5, since that combination seems best able to coax whatever errors out of Outlook I’m going to get. I configured Outlook to go read my mail account via IMAP and waited. Access violation once again.

So I loaded a program we have from Seagate Software, called Modules.exe I believe. It tells you exactly what’s loaded in memory and at what address. Being able to count in hexadecimal doesn’t get you any dates, but it sometimes helps you troubleshoot a problem. Plus it lets you make jokes about how much more fun it makes you at parties. So I sort by memory address, look at the ranges, and find the culprit. I forget the name of the DLL offhand, but the description Modules gave was “Outlook Network Folders.” Net Folders. Net Folders: one of the best but most poorly implemented ideas Microsoft ever foisted upon the unsuspecting masses.

So I copied that DLL over from the properly-working machine, then used the command-line utility fc.exe to compare them–if they’re different, I’ve found my culprit. I compare them, and find they’re identical.

That leaves two possibilities: Either the OS is corrupt beyond repair and just needs a clean re-install from scratch, or we’ve got a hardware problem. I find it suspicious that the problem always occurs at the same address, so I take the address, translate it into decimal using Windows’ calculator, then divide it by 1024 and then by 1024 again to get the address in megabytes rather than in bytes, and I get… 1221-something. Ouch. In a machine with 64 MB of RAM? So I went and found a programmer to confirm whether I was running through the right mathematical process. Indeed I was. He asked what kind of memory translation Intel PCs and Windows NT do (he’s a VMS programmer).   Then I remembered NT uses a 4-gigabyte address space, regardless of how much physical memory is there. So much for getting a number between 0 and 64 that I could use to determine which DIMM in the system was bad.

So instead, I just swapped the DIMMs. The problem went away. A smoking gun! Problem is, which of the two was bad? I can’t just leave it that way, because eventually something else will break.

Popping out RAM Stress Test , from the unfortunately-named Ultra-X, Inc., is the best way I’ve found to conclusively find a bad module. So I ran it for a couple of hours. Nothing. So I left it to run over the weekend. Hopefully that will turn up the problem by the time I return to the office on Monday.

And of course the PC in question is the one on the desk of one of our most important executives. Figures.

A minor change. Seeing as I have a growing number of British readers, still cursed with dialup connections, and since I tend to write really long, I switched to a three-day view rather than the seven-day view I’ve been using. Older pieces are of course accessible through the calendar and through the Best of this Page link, both to the left.