[GRLUG] Windows XP buggy driver or hardware problem.

[Michael Mol]

On Wed, Aug 12, 2009 at 1:52 PM, <peyeps at iserv.net> wrote:
>> ? I think there
>>> is something that I won't let talk to the network in the background
>>> someplace that grabs control and won't let go until it can phone home.
>>
>> If it's in the background, and it's in userspace (and virtually
>> everything in Windows is) it can't easily do something like that.
>> That'd be ridiculously stupid behavior for any sort of monitoring
>> software, anyway; There's no point for such software to draw attention
>> to itself.
>>
>> What do you mean by blocking network access to it?
>>
>
> Microsoft Windows, in my experience, expects to have network resources
> available to it, and applications using Windows follow the same pattern.
>
> I am running Jetico Firewall, which pops up any time:
>
> One application invokes another.
>
> An application wants access to the network.
>
> Any time it visits a new IP address.
>
> The first time an application wants access to the network, I can grant
> access, but then after that, it will pop up if that application wants
> access to a particular IP adddress.
>
> I can give it one time access or tell it to remember.
>
> There are a number of applications, ie Notebook, that expects access to
> the network, but since I am not using it to edit or read documents on
> anything but stuff that is on the local hard drive, network access is not
> needed.  So I told the firewall to block access for that application.

You mean Notepad?  Notepad does not itself require network access.  It
does, however, use the Common Dialogs component of Windows, which get
activated whenever you browse to open a file in the vast majority of
applications.  That browsing will trigger Windows' networking systems
when it displays, for example, the "My Network" *icon*, even if you
don't immediately browse into it.  If you have any network drives,
it'll query the network subsystems for that as well.  Additionally,
the file open/save dialogs use the Windows Shell, which is the same
browsing and file listing component you see when you use Windows
Explorer.  As a result, *all* installed Windows Shell Extensions,
which can include anything from compressors to TortoiseSVN get pulled
in, and any of those shell extensions may be trying to gain network
access.

Here's the rub...the Windows Shell is a COM component. At the
execution level, calls into it are very similar to calls into any
other library; Anything a COM component does appears in the same
address space and as part of the same process as what uses the COM
component.  Long and short of it?  Without attaching a debugger,
having debugging symbols and looking at the call stack when the
suspicious activity is triggered, you can't tell if the activity is a
misbehaving program or shell extension.

>
> But there are some things that seem to get pouty if they don't have access
> to the network, and refuse to respond.

Sure.  A lot of crappy third-party software is like that.  I haven't
seen XP completely reject keyboard and mouse input as a result of
software getting pouty over network access, unless that software was
doing something incredibly stupid with libraries like DirectX.  XP,
for all its Microsoft heritage, doesn't come with any 1st-party
userland software I've seen do that.

>
>>I suspect you've got a buggy hardware driver, particularly if sleep
>> states might be involved.
>
> I don't think sleep states are involved because I've had it happen to me
> when I open an application or go to save data to a file.

See my bit above about shell extensions.

>
> Possible buggy hardware driver, but if I'm not changing the OS, the
> hardware driver shouldn't be broken.

My motherboard shipped with buggy network drivers that were causing
packet corruption.  I didn't discover this until I was debugging
rhythmic streaks of corruption in a UDP video stream. Windows Update
didn't have a fix, but downloading and installing the relevant driver
from Realtek's website did fix it.

> I will grant you that hardware can
> break, but software doesn't break.  If you have enough pieces and
> combinations, eventually something will mis-match.   Just exactly how many
> problems will I introduce if I go and update all my hardware drivers?
> Or, if I only have one driver that is bad, which one should I update?  I
> could update the video driver, but is the risk worth the reward?

It's possible that new drivers could cause problems, but I haven't
seen that happen.  Additionally, XP allows you to roll back driver
updates under the Device Manager, so you can go back if you need to.

>
> What steers me away from the hardware is that there seems to be no problem
> with my Ubuntu, though I suppose the windows install that came with the
> system might be making use of something Ubuntu is not using.

I'm not saying it's a problem with the hardware itself, but that it
may be a problem with flaky drivers.  I've seen that happen more than
once.  Heck, ATI's 3D acceleration drivers have never been
particularly stable.


> So should I spend time and effort troubleshooting an very erratic problem
> or simply reboot into a different partition.  (I will grant you that there
> is a hard drive partition I don't write to with Ubuntu, so it is
> conceivable that there are some bad disk segments on my NTFS partition.)

Erratic or not, going with a low-cost known-temporary solution just
means you're going to have to go with a low-cost known-temporary
solution again later, and later, and so on.  And the integral of
low-cost over time is high-cost, and you're still lacking a permanent
solution.

Spend the time to get a permanent fix.  Update your drivers.  Identify
and remove unnecessary shell extensions.  Allow access to Windows
Networking, or disable it entirely in Control Panel.  Run Windows
Update to deal with other instability and security issues.  Or switch
away from Windows entirely.

(But if you don't switch away from Windows entirely, run Windows
Update first, and don't block network access while it's running.
Anything you might install today, both userland software and updated
drivers, is perfectly within its rights to expect up-to-date, patched
infrastructure.)


-- 
:wq