What Modules Do I Need to Include when Configuring Shim Parameters?

A question came up in the comments of one of my posts, and I think the answer is important enough to elevate to more than just another comment (and I didn't even answer completely in that quick response).

When you are configuring a shim and press the "Parameters" button, we've talked about the "Command line" option for several shims, but we've kind of glossed over the "Module name" entry. When we're applying shims, we are modifying the IAT of all statically linked modules, and we also have to intercept calls to GetProcAddress for dynamically linked modules.

Which modules do we need to be sure to include? That's easy - just go one stack frame above the API call you want to intercept.

Which modules aren't included already? Well, that's somewhat more complicated. So, let's just walk through the list to see what might get cut along the way.

First, we automatically exclude anything that sits in system32. So, if you want to have something included that sits in this directory, you have to specifically include it. (That, by the way, is why you have to include msvbvm60.dll for shimming VB6 apps - because the runtime sits in system32, and most calls land in the runtime before they hit the APIs we want to intercept.)

Next, we have a global include and exclude list. Here, we can add back in some modules, or remove some modules from consideration that aren't sitting in system32. This list of modules is not documented anywhere. Conveniently, however, it turns out that there's a little bug right now that prevents the global exclude list from being processed, so the number of additional modules excluded is 0. But we may fix this bug (or we may not, if this causes apps to break because shims are no longer applied - I'm not sure about that right now), so it's good to know that this processing exists. I'll be sure to document the list if that comes to pass.

Then, the shim itself has an include and exclude list. You'll see that if you launch Compatibility Administrator with the (super-secret, undocumented) /x command line switch - here, we include modules to overrule global exclude list and system32 exclusion, or exclude modules that aren't in system32 or the global exclude list (were it being processed) which we want to make sure we don't shim.

Finally, the application of a shim to a specific program has an include and exclude list. You can include a module to overrule any earlier excludes (system32, global, or shim-specific) and exclude a module if there's something we didn't rule out yet where shimming turns out to be bad.

It would be interesting to have the equivalent of Resultant Set of Policy for shim modules, but alas, nothing of the sort exists today. Instead, you generally rely on investigating if a particular module calls the API and either does or doesn't walk through the shim code. But hopefully these rules can shed some light on why a shim may not appear to be wired, and adding in a module can provide a quick fix to resolve the issue.

Comments (5)

  1. Aaron Margosis says:

    LUA Buglight and Standard User Analyzer can help here – the call stacks will show you what module called into the Windows APIs…

  2. Ivan says:

    Do these included/excluded modules have to be in the same process, or can they include other processes too?  (I have an application that calls multiple child applications that all need to be shimed in the same way as the first process)

    What is the syntax for including additional modules? (e.g. must this be a fully qualified path?)


  3. cjacks says:

    Hi Ivan,

    Regarding child processes – I figured that was worth promoting to a full post. You’ll find that here:


    The syntax for including modules is just the name of the dll – no path. For example, to include the VB virtual machine, include "msvbvm60.dll".



  4. ABC says:

    hi chrish,

    When we are cretating the SDB files, at one place it will ask you f0r which Operating System Mode do u want to select?…

    we genrally used to select WindowsXPSP2 mode. is it necessary to select this mode(if we are migrating to the vista?)..If I select this mode, what does it mean?……this application will work in a similar lines on vista like how it was working on XP?, is it?…

    thanks in advance for your guidance.


  5. cjacks says:

    You don’t need to select any mode – I almost always select "none" and then apply the shims I need.

    The mode is just a collection of shims. You can see which shims it contains in Compatibility Administrator.

Skip to main content