Why You Don’t Need to Copy and Paste from the System Shim Database (And What Happens If You Do Anyway)

I hear about a bug now and again with Compatibility Administrator [CompatAdmin]. It always surprises me when I hear about the bug, because you can only hit it if you are trying to do something that there is no point in doing (which is why we never caught it before).

Here's how you reproduce the bug.

In CompatAdmin, expand the System Database, then expand Applications. Pick an application at random, right click, and select copy. Now, go to a custom shim database, and paste this application and its shims. When you go to compile the shim database (which happens when you save it), you get this really weird error:

Compatibility Administrator
There was a problem in executing the compiler. The database could not be created successfully
The database file might be write-protected.

Now, the part about the compiler problem is correct - the suggestion that it may be write protection is not. So, we could do better with the error message, and we could also not give it in the first place. So, we have a bug filed against it. But here's the point.

You never need to manually apply shims from the system shim database. They are already there. They are already applied. We have 5,646 application entries sitting there waiting for you to install the application. As soon as we find the matching information, we start shimming - with no action required by you. We haven't just given you a collection of known fixes to discover and re-use, we've just outright fixed them.

Because, hey, when you go to run Barbie Pet Rescue, we don't want you to have to go fumbling around with CompatAdmin. We want to get you rescuing pets as quickly as possible.

Comments (13)

  1. Zooba says:

    I have found previously (under Windows XP, haven’t attempted under Vista) that some of the built-in shims weren’t suitable. I had a custom database for the applications into which I’d copy/paste/modify the system shim database. I don’t recall ever seeing this error, so does compiling a modified shim not cause it?

    (I can’t remember the exact reason the built-in shim didn’t work, but I imagine it was probably due to lack of administrator rights. That seems to break most old programs 🙁 )

  2. cjacks says:


    I have honestly never tried on XP, so I don’t know if things are different. What I normally do is just create a completely separate entry that adds the additional shims that I need for the scenarios we didn’t cover in sysmain.sdb, rather than copy and paste so I end up with duplicate copies of what is already there.



  3. Aaron Margosis says:

    @Zooba – As far as I know, the app shims provided in XP don’t help apps with LUA bugs (i.e., app works as admin but fails as "LUA" (limited user account)).

    @Chris – Is it just a coincidence that you chose my second favorite example out of thousands of shimmed apps?  (Second only to Barbie Pet Sematary!)

  4. curious says:

    some apps fail on 64 bit flavor while pass on 32 bit. so is there anyway to write a shim for 64 bit apps?

  5. sg says:

    Running Windows XP SP3:  ACT 5.0 doesn’t work to create a new custom database.  It always gives the error message described above when trying to save a new database.

    1. Launch Compatibility Administrator

    2. Create New | Application Fix…

    3. Fill in a name and vendor.

    4. Browse to select an exe file.

    5. Select a compatibility mode (e.g. None).

    6. Select a compatibility Fix (e.g. WOWCFEX_FORCEINCDPMI)

    7. Select a couple program attributes (e.g. MODULE_TYPE and 16BIT_MODULE_NAME)

    8. Finish

    9. Save

    "There was a problem in executing the compiler. The database could not be created successfully

    The database file might be write-protected."

    Okay, the same steps worked in ACT 4.0.  If you open the same sdb created in ACT 4.0 and try to resave it with ACT 5.0, it’ll give the error above.

  6. cjacks says:


    Where are you trying to save the database to? Did you launch Compatibility Administrator elevated? If you launch it non-elevated (default) and try to save the database to a protected location, this is the way we display access denied.


  7. sg says:


    I’m running on Windows XP SP3, using an account in the Administrators group.  It doesn’t matter where I try to save the file – it’s not a protected location problem.


  8. cjacks says:

    Well, it’s fair to assume that I can’t repro your issue, since the steps you’ve given are generic, and I use the tool for a living and I know it actually does work. You’re selecting a 16-bit fix, so I’d make sure you’re using it against a 16-bit exe. Other than that, if you can target a specific fix against something I’m likely to have (like Adobe or Office or Sysinternals or something like that) then perhaps we can narrow this down. Otherwise, I’m just going to have to keep guessing since I have no repro, and me just randomly guessing is not working so well thus far. (Sometimes I’m a good guesser, but apparently not today.)

  9. sg says:


    It works on 32-bit apps, such as Office.  I thought it might be a problem with NE files, but I found some that work… so not that.  Unfortunately, I have a few 16-bit programs that I need to make fixes for, and they all don’t work in ACT 5.0 (they do work in ACT 4.1).  One’s a database engine that I could send you.

    I need to include a UAC fix for Vista.  That’s why I’m trying to use ACT 5.


  10. cjacks says:

    If you’ve got a 16-bit app where we can repro inability to shim, then we’ll definitely have a look at it. (You may not get all of the new UAC stuff, as they tend to go after 32-bit APIs that the 16-bit app isn’t calling, but you should be able to add it as an entry into the SDB.)

  11. sg says:

    Okay, how do I send it to you?


  12. cjacks says:

    Send me a link to where I can download it.

Skip to main content