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.
