Le Chatelier's Principle in action: Administrative overrides

Today we have another example of Le Chatelier's Principle as interpreted by John Gall: Every system resists its proper functioning.

There was a video card manufacturer which was using the AppInit_DLLs key so that they could inject their DLL into every process. I have no idea why. Perhaps to get a nice bonus.

In Windows Vista, the AppInit_DLLs registry key was deactivated for both engineering and security reasons. Oh no! Undeterred, the video card manufacturer issued an update to their driver so that in addition to adding themselves to AppInit_DLLs, they also set the administrative override switch that re-enabled the feature. Boom, they probably got a second bonus for that.

Another lesson from this story is that if you provide an administrative override to restore earlier behavior, then you never really removed the earlier behavior. Since installers run with administrator privileges, they can go ahead and flip the setting that is intended to be set only by system administrators.

Comments (43)
  1. Michael Kohne says:

    Again, I call for a name and shame policy at Microsoft! When MS becomes aware of this kind of BS, they should be announcing the perp far and wide. One of the problems these days is that few people have any idea why things are so screwed up. If MS would help by pointing the finger when appropriate, it wouldn;t hurt the situation.

  2. Joshua says:

    AppInit_DLLs has one use. Patching up security flaws for which MS has not yet released a patch without touching the binaries and thereby breaking future updates.

  3. Myria says:

    @Joshua: PsSetLoadImageNotifyRoutine is better suited to that task than AppInit_DLLs.  For one thing, AppInit_DLLs cannot fix security holes for services that do not load user32.dll.

  4. Joshua says:

    @Myria: When's the last security remotely exploitable hole in Windows API reachable but not through user32.dll?

  5. smf says:

    Maybe windows defender should start highlighting problems like these.

  6. Hans says:

    @Peter Ferrie

    I wish this is not the same video card manufacturer which had since a certain driver version introduced the "cursor freeze" problem.

  7. Jonathan Hamilton says:

    @Michael Kohne: "Typical Microsoft, shifting the blame to their customers."

  8. The way I am parsing this story, it sounds like we put out a feature, someone started using it, but we don't know why, then we turned the feature off because we didn't like it (but without giving a reason why), but left a way to turn it back on, and we are now expressing our shock and amazement when the people who used it turned it back on.

    So I'm missing something.

    What are the security and engineering reasons for disabling AppInit_DLLs? In particular, how can turning off AppInit_DLLs be a security feature, when using AppInit_DLLs requires administrative access in the first place?

    What was the video driver using the feature for? In particular, what did the .dll do once it was loaded?

  9. Gabe says:

    I don't know what DLLs other people are referring to, but there is a popular vendor that loads a D3D shim DLL via this method. Since this is such a problem, MS should work with this vendor to come up with a solution that doesn't involve loading self-signed DLLs into every process.

  10. mikeb says:

    I really hate device drivers that insist on being more than device drivers.  Please give me a package that just has the driver software that lets the system use the device.  If you want to throw in a bunch of window dressing, put that in another installation package - don't force it on me.

  11. Ken Hagan says:

    @smf: "Maybe windows defender should start highlighting problems like these."

    Why pick on defender? Every AV vendor ought to highlight issues like these and those that don't should be named and shamed in the trade press.

    Given how widespread the problem of malware appears to be, it continues to amaze me that there is an apparent conspiracy of silence when "mainstream" vendors use the same set of dirty tricks. With all the history of anti-trust, I can actually understand that Microsoft are in a difficult position when it comes to calling out third-party vendors for bad coding, but the other AV vendors have no excuse.

  12. Kyle says:

    I have seen such AppInit DLLs cause access violations in a program that I work on.  Nothing like explaining to a customer that even though the access violation occurs *in* our program, it's not actually *caused by* our program.

  13. Engywuck says:

    semi-fitting: I just these days had a problem with HKLM...winlogonuser*init*. Some program managed to not only install itself there like malware would, but *also* to use a folder non-readable to most users to add there. Result was that logon was directly followed by logoff for nearly everyone. Quite nice on a terminalserver...

    Do I need to mention that this program is used for "enterprisy" features, so the "someone probably got a nice bonus" quite likely is true here, too?

  14. Dom says:

    @Michael Kohne -  'it wouldn;t hurt the situation' - It wouldn't help either.

    @Maurits [MSFT] -  'In particular, how can turning off AppInit_DLLs be a security feature, when using AppInit_DLLs requires administrative access in the first place?' - Installers run as admin, regular user innocently installs a program which add entries here. Suddenly 'random' programs start crashing and all bets are off. And don not forget that any program launched with admin now has a chance to execute this dll as admin.

  15. @Dom: not sure you understood my point...

    > Installers run as admin

    Some do, yes; fine.

    > regular user innocently installs a program which add entries here

    User innocently runs malicious code, elevated? Oops. The malicious code now owns their system. It can install a service, it can inject code into running processes, it can do all kinds of nasty things directly. AppInit_DLLs isn't much of a concern at this point; the game's already over.

    > Suddenly 'random' programs start crashing and all bets are off.

    At this point programs crashing is the least of your worries.

    > And don not forget that any program launched with admin now has a chance to execute this dll as admin.

    You mean, the bad .dll gets another chance to run every time you launch another program elevated? I suppose that's a nice convenience for the author of the malicious code, but they don't really need it; they can launch their own long-lived processes from the installer without relying on the user to run other processes later, and they can arrange for their code to be run again on logout/login or reboot.

    So AppInit_DLLs is not of much use to malware vendors. It is apparently of value to the video driver vendor, though. I'm curious as to why.

  16. Matt says:

    @Maurits: "It is apparently of value to the video driver vendor, though. I'm curious as to why."

    If it's the video card driver I'm aware of which does this, it's so it can hook DirectX in usermode. This gives it the opportunity to speed up a couple of hotpaths through DirectX to its video driver (e.g. it could map video memory into usermode so polygons sent to the videocard don't need to go via the multiple indirect calls in DirectX usermode, kernelmode, the shader pre-translation path in kernel mode and the syscall boundary).

    Speeding up graphics operations - by practically any and all means necessary - is a fairly major goal of graphics card vendors. And personally if Microsoft is going to give them a way to do this and then retract that reason without giving the graphics card vendors a good reason why they shouldn't re-enable it, of course they're just going to turn it back on! If this gives your graphics card a 5% boost in performance compared with your rivals on the market, you'd be mental not to!

  17. Peter Ferrie says:

    There *continues* to be a video card manufacturer which is using the AppInit_DLLs registry key, even on Windows 8.1, and it is known to cause all kinds of problems.

  18. foo says:

    Well I checked my Windows 7 work computer and saw the registry settings exactly as described in the article. But the DLL in question resides in the System32 directory, so in theory (cough) as long as the DLL itself is secure then it is protected from being replaced by some sort of airtight hatch. But why still the need for the DLL, especially after a number of years? (Rhetorical question... I can googles that for myself, and now refreshing before posting I see Matt helped with that, and maybe it's no longer needed and I just don't update my work computer's graphics software as often as I should).

  19. cheong00 says:

    @Hans: Don't know, but if you're talking about A brand, I heard people successfully makes the problem go away after they disabled the "vertical sync" option in the video card's advanced settings.

  20. cheong00 says:

    @Ken Hagan: I found some antivirus already doing something similar.

    For example, the antivirus always prompt that my P2P software could make my browsing speed slow... Thank you, I've set the max upload/download limit so it won't affect me. Please go away.

    Funny that this P2P software is the only piece of software that invoked that warning, and there are other well known software the could cause problems but all were ignored. I bet someone is getting real nice bonus on that.

  21. cheong00 says:

    Sorry, I just checked and it should be N brand that the vertical sync fix is about.

  22. ChrisR says:

    @Ken Hagan: Additionally, it really irritates me that the AV vendors will gleefully block useful software because it is self-signed (or not signed at all), but they will allow all this **** to intentionally make systems more vulnerable, just because it has been downloaded by a lot of people and/or is signed.

  23. Kai Schätzl says:

    N brand fits, it's the one known injecting via AppInit. A few years ago it caused crashes in IE after a major version upgrade of IE.

  24. vova says:

    Why don't commenters tell the brand name?

  25. ender says:

    I just checked my computers, and it appears that the green videocard vendor uses AppInit_DLLs, and the blue (which only does integrated graphics) one ones doesn't. I don't currently have access to any computer with the red manufacturer's cards, so I couldn't check that one.

  26. smf says:

    @Ken Hagan:Why pick on defender? Every AV vendor ought to highlight issues like these and those that don't should be named and shamed in the trade press.

    I was assuming that at the point you installed the driver you'd probably still be using defender. But also Microsoft are in control of defender and they are in the best position to make the decision on what is bad programming practise.

  27. GregM says:

    "Why don't commenters tell the brand name?"

    Because it's against the rules here.

  28. Joker_vD says:

    Hmm, I wonder if using abbreviations of brand's names okay? E.g., "IBM" instead of "International Business Machines Corporation"?

  29. Soonts says:

    I have an idea why, and it’s not about bonuses.

    They are using this feature for better support of GPU switching. They were first to invent that, and Windows still does not provide adequate support for this feature (e.g. per-application policy saying which GPU to use).

    ["I got a bonus for doing something unsupported and outside sound engineering practices in order to get this feature working." -Raymond]
  30. Kai Schätzl says:

    It's rather a video *chip* manufacturer. And who of the bazillion small card manufacturers does actually code drivers? Is N now clear enough?

  31. alegr1 says:

    >This is true, but they are probably in the worst (legal) position to start naming names.

    Microsoft needs to start using their legal department for the good. I suppose they have people capable of drawing a letter that tells politely to go F themselves.

  32. Joshua says:

    ["I got a bonus for doing something unsupported and outside sound engineering practices in order to get this feature working." -Raymond]

    Which is a different claim from all previous cases of "nice bonus for that feature" where the feature itself was unsound where in this case only the implementation was.

    [True, but I kind of also use "nice bonus" to cover "I violated sound engineering practices in order to get a bonus." -Raymond]
  33. Random User 948573 says:

    Maurits, really it is the same "security" dangers any time an unexpected DLL is injected. "Perfectly harmless" DLL being injected into _everything_ has bizarre interaction with some other vendor's process that would normally have just thrown an AV or something, and now we have an EoP, or a disclosure, etc.

  34. Ken Hagan says:

    @smf: "But also Microsoft are in control of defender and they are in the best position to make the decision on what is bad programming practise."

    This is true, but they are probably in the worst (legal) position to start naming names. Then again, none of the other AV vendors seem willing to take the risk. When "a well known company" that happened to own a record label was caught distributing root kits on CDs a few years ago, it was notable that *none* of the AV vendors either before or after the revelation were willing to flag it up as malware. Even when the parent company accepted that it was a bad thing and withdrew it, still no-one was willing to criticise.

    @cheong00 & ChrisR: Yes. It's almost as though the entire AV business is just a scareware racket.

  35. "Every system resists its proper functioning."

    Every system resists Microsoft and its perception. Microsoft is something that people find useful but never lovely. So, the burden of convincing them to go "Microsoft Way" is on Microsoft. Generally, the perception is that:

    "Microsoft resists the proper functioning of every system."

  36. cheong00 says:

    @alegr1 : Spending time of legal department on issues caused by individual commenters of blog posts doesn't sound like the best use of it.

  37. Engywuck says:

    I just noticed that on our servers providing Terminal Service functions with the C brand there's also a AppInit_DLLs "hook", and in another part of the registry, under their own name, there's a whole lot of sub-keys under the key "AppInit_DLLs", providing support for flash, printing, seamless integration, etc. (according to the names of the keys). In a version designed for 2008R2, so well after the AppInit_DLLs was deprecated/turned off. Seems to be quite widespread...

  38. q says:

    ["I got a bonus for doing something unsupported and outside sound engineering practices in order to get this feature working." -Raymond]

    Normally I agree with you, but this time I'm not sure it's a good argument. Basically you are saying that Microsoft has an authority to prevent technological innovation. (I'm assuming Const82's explanation of the purpose of the discussed gimmick). I agree that the solution chosen by the graphics vendor is not a good one from the engineering standpoint, but what they are to do? The feature (dynamic graphics card switching) is really very useful. In the ideal world, they would have talked with Microsoft and jointly established an API suitable for the purpose; however more than one Windows release happened since graphics card switching was invented, and there's no suitable API, so I guess Microsoft doesn't see any value in it for itself.

    This reminds me of the time when I worked for a company building a 3rd-party Bluetooth stack for all kinds of Windows. In Vista we wanted to integrate with its new BT stack: provide some new profiles (for which there is a documented way) and support BT 3.0 (for which there isn't). The answer we got from Microsoft: "No, we don't plan to support BT beyond 2.1 in the BT core in the foreseeable future. No, we can't give you documentation for the core driver. No, we won't allow a 3rd-party driver to replace our core driver. Feel free to ship entire BT stack if you want 3.0".

    OK, we did ship the entire stack (of course, with its own GUI and with its own private API, for rejoicing of future apps writers who now have to support one more unique API).

    But we had a customer who wanted MS API-compatible stack, so we shipped another version which included two minifilter drivers (one to go below the MS BT core driver and one above) which bolted on the support for BT 3.0. Good engineering? No, but what are the choices?

  39. cheong00 says:

    @immibis: This happens a lot. But more often the case will be that, on the next reboot, the computer suddenly fail to boot. This is because the antivirus is so help that, when it cannot delete the file, it'll attempt to delete it on the next boot time.

  40. immibis says:

    Suppose one antivirus program detected this video driver as potential malware.

    Antivirus: "nvatigma32.dll is possible malware. Remove?"

    User: *clicks Remove*

    Antivirus: "File removed." *reboots*

    User: *goes to play a game*

    Game: *runs really slowly*

    User, to friends: "Hey everyone, don't use Awesome Antivirus 3000 Ultimate! It'll make your computer really slow!"

  41. Joshua says:

    It is obvious that q understands the forces involved.

  42. alegr1 says:


    Microsoft BluTooth is pathetic. Microsoft BT mouse can't keep paired with Microsoft BT stack. And this is in Windows 8. You would have though they got things working.

    Microsoft Intellimouse software suffers from insane wheel scrolling speed. And it's been suffering from it for many many years, with no fix in sight.

  43. q says:


    To be honest, Bluetooth architecture is much to blame here. It's overcomplicated in many places and underspecified in some places, and there is just too many possibilities to get something wrong. Bluetooth SIG tries to help by organizing quarterly UnPlugFests, global interoperability testing events where vendors get together and test their devices or software against each other in whatever combinations they are interested. But it's physically impossible to test everything against everything, so some bugs or quirks stay in for a long time.

    I rather liked Microsoft's Vista and Win7 BT stack architecture; it's major problem was that it was stuck at BT 2.1 for many years. Their GUI choices seemed weird in some places, but at least it was consistent. :)

    It seems that they implemented BT 4.0 in Windows 8, which might explain new issues. (I'm not in that field anymore so I don't know for sure.) Though I'd have thought iterop with own trademark devices should be on top of the list...

Comments are closed.

Skip to main content