DIFXAPI, KnownDLLs and old versions


  • I've encountered a problem (luckily on only a few machines) while deploying a Windows 7 64-bit application that uses DIFXAPI.DLL and DriverPackageInstall. The function fails with ERROR_BAD_ENVIRONMENT. The documentation isn't clear on what exactly this means, and it's even less clear on how to go about fixing it.

    A little more background: I include the redist difxapi.dll from the WDK alongside the application, however since DIFXAPI.DLL is listed under KnownDlls the local copy will not get loaded (see After a lot of head-scratching, I traced the issue: the user's copy DIFXAPI.DLL wasn't the same as the one from the DDK that I was shipping. Both were listed as version in their version resource; the one from the user's system was 497K, the one from the DDK was 503K.

    But the problem remains: The DIFXAPI copy in the SYSTEM32 directory is heavily protected by Windows and only TrustedInstaller can update it and the local copy I ship won't be loaded because of KnownDlls.

    So far, the best "workaround" that I have (and I use the terms best and workaroud loosely) involves tinkering with permissions and then renaming the DIFXAPI.DLL in SYSTEM32, rebooting, installing, renaming DIFXAPI.DLL back, resetting permissions, and rebooting again. This is clearly unworkable and there has to be a more sensible solution.

    I would appreciate any pointers or ideas on how to go about solving this. Is there perhaps an official Microsoft blessed application that can properly update DIFXAPI.DLL?

    Wednesday, October 24, 2012 12:37 AM


  • That answers my question somewhat, thank you Jason.

    It's involved to actually muck around with DIFXAPI.DLL (and that's a great idea) but perhaps that's what actually happened. It wouldn't be the first time bad installers trample all over the system and copy crud on top of stuff that's already there - bleh. Since this has only occurred on a couple of systems, I'm happy to just assume that's what happened.

    I'll make some inquiries and see if I can figure out how their DLL was replaced. 

    Thanks for helping out.

    Tuesday, October 30, 2012 8:54 PM

All replies

  • what os and architecture are you seeing this on?

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, October 24, 2012 3:10 PM
  • The difxapi.dll in system32 is intentionally not the same as the one in the WDK and as such is not the same size.  You should not ever be tampering with it, nor with any other protected windows components/files.

    When you say a "Windows 7 64-bit application" does that mean you are hitting this error on a Windows 7 machine, or is this a program you compiled for Windows 7 that you are trying to run on Windows 8?

    Which version of the WDK did you get the redist difxapi.dll from?  How are you loading difxapi.dll for use in your application?

    Wednesday, October 24, 2012 4:54 PM
  • I appreciate the speedy reply; This is on 64-bit Windows 7 w/ SP1. The program in question is compiled as a 64-bit program.
    Friday, October 26, 2012 5:49 PM
  • Jason, 

    I appreciate the answer; I have no intention of mucking around with any protected Windows components and/or files. I did test on my own test system, in an effort to understand what was happening, and see if it's something I was doing wrong or something specific to the user's install, but I do not consider replacing the DLL with the one from redist to be a solution. Indeed, I'm posting this because I want the right and correct solution. 

    This error popped up on a Windows application, compiled as 64-bit, running on 64-bit Windows 7 SP1. The DIFXAPI.DLL is the redist version that came with 7600.16385.1, lists itself as version 2.1 and has an MD5 cheksum: 1A2E5109C2BB5C68D499E17B83ACB73A. If it helps any, the DIFXAPI.DLL from the user's system also lists itself as 2.1 and has am MD5 sum of 64F7E836866B3878B63D377F975FC4A1.

    I include the redist version of the DLL with my application install, and it's located in the application folder, along with the application that uses it. But if I understand the KnownDLL semantics, that's pointless anyways, as the DLL won't ever be loaded from any location other than the System Directory.

    As for how I'm loading DIFXAPI: I don't, per se. I rely on the loader to link the necessary DLLs; I just link with the relevant .LIB file that comes with the WDK and just directly call DriverPackageInstall. 

    I would appreciate any additional insight that you can offer. If I can provide you with any additional information please let me know.

    • Edited by nbougalis Friday, October 26, 2012 6:19 PM Add some more information
    Friday, October 26, 2012 6:11 PM
  • I guess that's true (and would be fairly easy to check if that's the case - the signature would only result in changes at the tail-end of the file, as Authenticode signatures are appended to the end of the binary). But I think the fact that when, on a fresh Windows 7 SP1 install, things work fine with the default DIFXAPI, or with the DIFXAPI that comes with the WDK, and don't when using the user's copy of the DIFXAPI.DLL suggests that there's more at play here than just a signature.
    Friday, October 26, 2012 6:32 PM
  • You say you only see this on some machines.  What is the difference between the machines you see this on versus the machines you don't?  Is your application being run in compatibility mode?  Have you verified that the version of difxapi.dll included in the OS is the one being loaded and not the redist copy you include? 

    You say that on a fresh Win7 SP1 install, things work fine with the default DIFXAPI but don't work when using the user's copy of DIFXAPI, what do you mean?  What is the 'default' difxapi, and what is the 'user's copy'?

    Monday, October 29, 2012 5:39 PM
  • This issue has cropped up on a couple of customer machines. As for what's different, beyond the standard set of differences that you would expect between machines belonging to different people (such as different software installed) the only common difference that I've been able to track down seems to be the DIFXAPI.DLL in their system directory, which I have verified as the one that is being loaded.

    This is what happened:

    Once this was reported, I setup a test system with a fresh Windows 7 SP1 install (same SKU as the user's) - nothing else on it. The install worked successfully. I tried installing some of the same software that the user had on his system to duplicate the issue but could not. I read on MSDN that an incorrect version of DIFXAPI.DLL could cause the ERROR_BAD_ENVIRONMENT, so I asked the user to send me his DIFXAPI.DLL so that I could ran some basic sanity checks (i.e. does it have the usual DLL structure, do the exports appear correct, and is it a 64-bit DLL?) and everything checked out fine.

    Meanwhile a second user reported this issue. I asked for the usual troubleshooting details and cross-checked but didn't notice any similarities between their systems; I requested that this second user send me his copy of DIFXAPI.DLL and noticed that both users had identical DIFXAPI.DLL files.

    So on a hunch, I replaced the copy in my test machine's system directory with the copy the user sent me, and rebooted. Yes, I know this isn't actually recommended and shouldn't be attempted, but it was the only similarity I could see and I figured I should test as many things as possible before coming on the fora for help.

    After rebooting and verifying that the user's copy of the DIFXAPI.DLL was loaded I could replicate the error: DriverPackageInstall would, indeed, return ERROR_BAD_ENVIRONMENT. As an extra test, I checked whether using the redist version of DIFXAPI.DLL would work: I copied the redist version of DIFXAPI.DLL into the system directory and rebooted, verified that it was loader, ran the program and things worked just fine.

    So to summarize:

    • Things work fine when using the DIFXAPI.DLL that comes with Windows 7 SP1
    • Things work fine (or at least seem to work fine) when using the redist DIFXAPI.DLL that comes with the 7600.16385.1 WDK
    • Things do NOT work when using the DIFXAPI.DLL that these two users had in the system directory.

    To be clear: I am not advocating that people mess around with the DIFXAPI.DLL or anything like that. I am just trying to understand what the issue could be and how to go about correcting it so that the users can run the software they purchased and I can resolve & close the tickets assigned to me.
    • Edited by nbougalis Monday, October 29, 2012 6:47 PM
    Monday, October 29, 2012 6:44 PM
  • Yes, it would be good to find out where their version of difxapi.dll comes from.  It sounds like somehow they probably have a version of difxapi from before the RTM version of the Windows 7 WDK.  Versions prior to that would return ERROR_BAD_ENVIRONMENT when run on Windows 7.  What could be happening here is that perhaps these users are installing software that was written for Vista (or earlier) which is before there was a difxapi included as part of the operating system.  As part of the installation, the software may have been copying out difxapi to system32 for whatever reason.  Now that there exists a windows component in that location, the installer may be forcing an old version over on top of it, resulting in these users ending up with the wrong version of difxapi.dll in system32.  The installer would have to go through the trouble of taking ownership and changing permissions so it could perform the copy (like you had to do manually) which seems unlikely, but it would explain what you are seeing.
    Tuesday, October 30, 2012 8:42 PM
  • That answers my question somewhat, thank you Jason.

    It's involved to actually muck around with DIFXAPI.DLL (and that's a great idea) but perhaps that's what actually happened. It wouldn't be the first time bad installers trample all over the system and copy crud on top of stuff that's already there - bleh. Since this has only occurred on a couple of systems, I'm happy to just assume that's what happened.

    I'll make some inquiries and see if I can figure out how their DLL was replaced. 

    Thanks for helping out.

    Tuesday, October 30, 2012 8:54 PM
  • We are experiencing exactly the same problem in our installer. When we call DriverPackageInstall, ERROR_BAD_ENVIRONMENT is returned. We have verified that the version from system32 is being loaded and it seems to be different from the one from "normal" Windows 7 installation or WDK. This difference is not in the digital signature or some headers - compared by binary comparison utility, they differ in many locations.

    The problem is that we are receiving more and more complains from the users over time.

    Could you please share with me if you managed to fix the issue and how?

    Wednesday, April 17, 2013 9:03 AM
  • Answering my own question - a couple of workarounds:

    1. Add difxapi.dll to the the following registry entry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ExcludeFromKnownDlls (simple administrative access is required - no changing defualt permissions) and reboot. Then restart the installer - it will now load local version of difxapi.dll, supplied in your installer

    2. Maybe better solution, not requiring changing global state for local problem. Provide two copies of difxapi.dll with your installer. First, LoadLibrary("difxapi.dll") - this will either load your local (on Vista, for example), or system standard (on non-corrupted Windows 7 installations). Call DrivePackageInstall. If it returns ERROR_BAD_ENVIRONMENT _AND_ it is Windows 7, repeat everything, but this time call LoadLibrary("another_copy_of_difxapi.dll"). The last test for Windows 7 is to probably reduce compatibility issues with future versions of Windows.

    • Proposed as answer by Cyber111 Wednesday, April 2, 2014 3:24 PM
    • Unproposed as answer by Cyber111 Wednesday, April 2, 2014 3:24 PM
    Wednesday, April 17, 2013 1:35 PM
  • We just ran is tho this issue with one of our customers. They had Windows 7 64-bit and the DifxApi.dll in the System 32 directory was from 9/2/2009. I had then run sfc.exe /scannow to check and repair the system files. The dll was replaced with the version form 7/3/2009 and after a reboot our installation worked fine. Not sure where the dll came from but this was a quick and easy solution.

    Wednesday, April 2, 2014 3:27 PM
  • Thank you all of you! Our installer met this issue yet.
    Tuesday, September 23, 2014 5:16 AM