Best-of-Breed Apps Aren’t Always Best for Vista

OK, I have to start this blog with a confession: I’m an inveterate system tinkerer, and am always looking for something better for my system (if not for something rated as the best of its kind). For example, this approach has led me to skip using a good all-around security suite in favor of picking the best elements of each kind by itself (anti-virus, anti-spyware, firewall, anti-spam, rootkit detector, intrusion detection/prevention, system file and state monitoring, and so forth).

Because of the growing number of items on that list that must be managed individually, its size is proving to be a more and more powerful argument for installing and using a security suite, however, and is slowly and surely dragging me in that direction.

In the wake of some recent difficult experiences with Vista firewalls, I find myself questioning this decision. I recently learned about the Matousec.com Firewall Challenge and ended up taking its top two rated firewalls for a spin, more or less because they were the highest-rated items on that list. In both cases, I had to uninstall this software on my Vista machines in three to five days after installing them, because each of these two firewalls wouldn’t coordinate or cooperate with other software I need to run, including Carbonite Internet backup, Spyware Doctor, Acronis Backup, and so forth. In fact, I had to cope with at least one blue screen (BSOD) on each system daily, while I went through the sometimes laborious process of figuring out what was causing these crashes to occur. Just to make things more interesting, I have all of these things scheduled to run in the wee hours of the morning because I’m not at the machine. For both firewalls, however, my absence helped to provoke each crash, because they would ask me what to do about offending software items or behaviors, then the system would hang after I didn’t answer within an hour or two…

Invariably, the bluescreen messages themselves mentioned issues with memory access. Because I’d had problems with the RAM (and placement of DIMMs) on my production machine’s motherboard, this set me off down a false trail of memory module testing and swapping that took about three days for me to figure out that RAM was not a factor in my troubles. Next, I had to dust off my crash dump reading skills, and refamiliarize myself with the Windows debugger windbg.exe. This in turn led me to discover that Microsoft now makes its debug symbols libraries available via a Web link (hooray!!) thereby ending my recurring and vexing issues with symbol resolution. Although it’s probably still a good idea to download and install a local symbol library on your Vista PC, by including the URL as shown in the following screenshot, you can avoid the headaches sometimes associated with making all your symbol references current, complete, and correct.

Note the URL reference at the end of the Symbol path string

A URL reference to the Microsoft Download Library lets
WinDBG users reference a current symbol library that MS maintains.

Once I could read the crash dump files, I quickly learned to turn to %systemroot%Minidump to look for my mini-dump files. If you get involved in more serious crash debugging, don’t forget to visit the Startup and Recovery window inside the System Properties item in Control Panel: Start, Control Panel, System, Advanced System Settings, Settings button in the Startup and Recovery pane. Be sure to select “Kernel memory dump” as your Write debugging information selection, as shown in the next screenshot, to produce maximum detail and diagnostic data (you’ll have to crash again, and write a new dump file before this information becomes available, though):

For the most detail, select kernel memory dump as shown, rather than small memory dump

Windows Vista calls mini-dumps “small memory dump (64 KB)” when identifying
dump files by type, but you want a kernel memory dump for maximum detail.

In looking at one of my recent crash dumps, as shown in the next screenshot, analysis (using the command string !analyze -v;r;kv;lmtn) reveals that a module named sandbox.sys is the source of the illegal memory reference that provokes the bluescreen in this case. A little online research showed me that my problem was far from anomalous, and that no fix had been made available as yet. This led me to abandon yet another firewall, and left me facing a true Hobson’s choice—namely, did I want to use a less effective firewall that left my system running, or keep using a more (or most) effective firewall, and incurring a daily BSOD? Sheer practicality, and the presence of a hardware firewall on my network periphery spurred me to make the first of those two choices, though I’d much rather have been able to make the second one.

A mini-dump shows which module provokes the BSOD

Even without all the details, the mini-dump
points out which module provoked the bluescreen
(click thumbnail for full image)

Ideally, I’d like to be able to have my security cake and eat it too, but perhaps I’m asking too much, given the complexities of all the different software that I’m trying to use in concert. There’s just too much dissonance amongst the individual elements involved for things to work smoothly, so I’ve been forced to ratchet some of my security component choices down in the interests of keeping my system up and running. If anybody knows of a better alternative, or a better approach to fixing this problem, please share it here. In the meantime, I’ve gone back to some tried and true, if less capable, alternatives.

Facebooklinkedin
Facebooklinkedin

Leave a Reply

Your email address will not be published.