The mystery of the gobbledygook folder

My buddy Michael sends a worried e-mail:

I’ve got a question/concern:

I found the attached .txt file in a weird folder on my C: drive.

It has me a bit concerned, b/c it’s such a detailed log of some serious changes on my machine.

The folder was named “6d3f48932a458452fc06ece98b60” and is dated 11/19/2006.

One possible clue: I installed the new IE somewhere around this date– but my concern is that I’ve found several of these similar folders & txt files on Renee’s computer, and I haven’t upgraded her IE.

WTF is it? Does it mean anything to you? Is it nothing, or something bad?

I have those on several machines here. They’re perfectly normal, if a bit baffling. The best clue was the name of the attached file:


It’s easy enough to break that down:

  • The .log extension means this is a log file, in text format, documenting changes that were made to the system.
  • The -enu bit at the end means it was in the English (U.S.) language.
  • KB927978 refers to a Microsoft Knowledge Base article number.
  • And if you look for that article, you find out that it’s entitled “MS06-071: Security update for Microsoft XML Core Services 4.0”, which pretty neatly takes care of the msxml4 part at the beginning of the name.

The long, gobbledygook number is a security precaution. If you write a patch to a known location on every one of a few hundred million PCs, then the bad guys know to target that location. By creating a system-generated name for the folder, it’s impossible for an attacker to target the files in that location.

If you’ve got one or more of these folders hanging around, you can safely delete it.

Technorati tags: , ,

10 thoughts on “The mystery of the gobbledygook folder

  1. Sometimes it’s not that easy. For example, I have one from Apr 11 called “7dd69b57d98e25e1fb79faf29da8.” It contains a folder called “wcu” (apparently Windows Component Update) — but it cannot be deleted, access is denied.

  2. Rick, open a Command Prompt window (Start/Run, type cmd, press Enter) and change the prompt to that folder. Now type the following command:

    cacls .

    (Note the space and period at the end of the command.)

    Press Enter.

    What permissions are on that folder?

  3. It returns this rather strange output. In case the formatting doesn’t make it, the last two lines are greatly indented (this is the H drive we’re talking about, BTW, of no significance to Windows–which is on the D drive–except that H:\ is where I keep the pagefile):

    H:\7dd69b57d98e25e1fb79faf29da8 BUILTIN\Administrators:F

  4. Ah, OK. I think I have an idea what’s going on. Was this volume (drive letter) created using an earlier version of Windows? Did you then upgrade to a different version? Which version of Windows are you running now?

    Basically, you need to take ownership of the folder before you can delete it. The Unknown Account security identifiers (SIDs) belong to accounts you created with a different Windows version, and your current version doesn’t recognize them.

  5. This system has been on XP for its lifetime (about three years), and it was a clean install then. Now, I do have a separate dual-boot going with Vista, though it was never installed to the H volume (a physical drive unto itself), which I only use for backup and transitional storage (and pagefile).

    So this could be the result of the Vista beta or XP, but I was thinking XP because of the similarity to what can be seen with its security updates.

    To take ownership of the folder, I right-clicked it, clicked Properties, and then was momentarily confused why the Security tab wasn’t there. It’s been years since I’ve thought about this kind of thing, but I found that “Use simple file sharing” in Explorer’s Folder Options had to be disabled first. Once in the Security tab, I gave ownership of the folder and its contents to my account, at which point I could see what was beneath the “wcu” folder. Six subdirectories:


    Which contained files like dotnetfx.exe (23MB), wpf.msi (13MB), Indigo.exe (6MB), msxlm6.msi, etc. About 45MB of installers in all.

    I checked my MS Update history and didn’t see anything listed for Apr 11, so this must have been a separately downloadable .NET update (2.0 it seems) I did back then that didn’t clean up after itself in a big way. I know it wasn’t a botched install, since I’ve always upgraded .NETs smoothly and never had a problem with them. It couldn’t have been Vista, since .NET is built-in there.

  6. Rick, this isn’t necessarily a Vista issue. The same thing could happen in XP.

    The permissions you saw that were originally assigned to Unknown Account are supposed to be assigned to the built-in Users group on your machine. That’s a well-known group with a SID that doesn’t change between installations, so it shouldn’t be affected when you reinstall Windows (even a different version). I have no idea why the permissions got messed up, but it sounds like you’ve fixed it.

  7. Why are these damn loggings not in c:/security// so I don’t ever see them?!
    And what use do loggings have if you can just throw them away? Why need them anyway?

  8. Two questions actually –
    1. Can i disable this logging feature?
    2. My friend with the same config notebook does not see these logs (even though he assures me his windows is automatically updated – the same thing which shud be creating logs for him too) .. was there something he/i missed in setup?

Comments are closed.