Udostępnij za pośrednictwem

Generic Troubleshooting: "Is it still a problem?"

  • Artykuł

I've been doing this support thing for a while now.

Frequently, the basics are what get overlooked when troubleshooting an issue, particularly an issue that seems complex on the surface.

Often, though, you'll find that the detailed techniques lead you back to a fairly basic set of rules, the most basic of which is:

Everything's either a file issue, or a settings issue, or just how the software works (by bug or by design).

If something seems unlikely to be a file (corrupted or incorrect file) or settings issue, it could easily be a bug (that is, given the same conditions, you'll be able to reach the same outcome). But if you think you might have hit a bug, what's the most efficient way of addressing it?

Obviously, to find someone else has addressed it already!

So, the Temporal rule of Troubleshooting: try it with the most recent version available.

(this doesn't necessarily mean "try Word 2007 if 2003 doesn't work", I mean "within the same major version").

 

Today, for example, I was looking at a memory dump (which you usually tend to do at the pointy end of a troubleshooting process, and I'm not going to show working or why these two are relevant), and found these *cough* classics:

0:000> lmvmurlmon
    Loaded symbol image file: urlmon.dll
    Image path: C:\WINNT\system32\urlmon.dll
    Image name: urlmon.dll
    Timestamp:        Wed Aug 04 17:56:37 2004 (411096B5)
    File version:     6.0.2900.2180
    Product version:  6.0.2900.2180
...
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft® Windows® Operating System
    InternalName:     UrlMon.dll
    OriginalFilename: UrlMon.dll
    ProductVersion:   6.00.2900.2180
    FileVersion:      6.00.2900.2180 (xpsp_sp2_rtm.040803-2158)
    FileDescription:  OLE32 Extensions for Win32
    LegalCopyright:   © Microsoft Corporation. All rights reserved.

0:000> lmvmmsxml3
start    end        module name
    Loaded symbol image file: msxml3.dll
    Image path: C:\WINNT\system32\msxml3.dll
    Image name: msxml3.dll
    Timestamp:        Wed Aug 04 17:59:24 2004 (4110975C)
    CheckSum:         00138815
    ImageSize:        00130000
    File version:     8.50.2162.0
    Product version:  8.50.2162.0
...
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft(R) MSXML 3.0 SP 5
    InternalName:     MSXML3.dll
    OriginalFilename: MSXML3.dll
    ProductVersion:   8.50.2162.0
    FileVersion:      8.50.2162.0
    FileDescription:  MSXML 3.0 SP 5
    LegalCopyright:   Copyright (C) Microsoft Corporation. 1981-2003

 

What does that tell me? Well, lots! Like: this particular machine isn't up to date on IE and XML security patches. Internet Explorer security patches are cumulative, so installing one tends to refresh the majority of the browser software (side bonus: this can also resolve file-level issues, like a corrupted or incorrect DLL).

From that, you can infer that it's probably not up to date on a bunch of stuff. We make it pretty easy to apply security updates these days, and if the security patches aren't up to date, chances are there are non-security patches missing too, and so on.

So: My standard response to any binary implicated in a reproducible problem is to look for and then apply the latest version available (from memory, urlmon was updated this month, and msxml3 sometime since mid-2007).

Once we've applied the latest updates, we'll know whether we actually have more work to do, or whether we're just covering old ground.

So, short version: Try the latest version first.

See the big potential time saving there?

Comments

  • Anonymous
    January 01, 2003
    Haha - I get involved at around the time that memory dumps become useful! WindowsUpdate isn't always realistic, but it is very often the best place to start.

  • Anonymous
    April 28, 2008
    The comment has been removed