Why do we need to copy/paste "fxc.exe" from Bin/10.0.XXXXX.0/x86/ to Bin/x86/ directory in the Windows 10 SDK folder? RRS feed

  • Question

  • The "Bin/x86" and "Bin/x64" folders are located at:

    C:\Program Files (x86)\Windows Kits\10\bin\x86
    C:\Program Files (x86)\Windows Kits\10\bin\x64

    "Bin/10.0.XXXXX.0/x86" and "Bin/10.0.XXXXX.0/x64" folders are located at:

    C:\Program Files (x86)\Windows Kits\10\10.0.XXXXX.0\bin\x86
    C:\Program Files (x86)\Windows Kits\10\10.0.XXXXX.0\bin\x64

    When debugging GPU shaders and rendering pipeline processing using Direct3D, Visual Studio reported the "fxc.exe" is missing or is not found, and recommends anyone seeking "fxc.exe" to reinstall Windows 10 SDK.

    It should've been flexible to accommodate the Windows 10 SDK's Build Version numbering schemes into account in the directory lookup. I don't see anything mentioning about "fxc.exe" requiring to be copied/pasted into the Bin/x86/ folder directory until I looked it up on Stack Overflow.

    My understanding is that files and binary executables packaged within software development kits, especially official kits distributed by vendors, operating system maintainers, and hardware manufacturers, should not be touched by end users. "fxc.exe" is an exception, and in my personal opinion, this is a dangerous exception to this rule.

    It also hinted that many other binaries and executables in the Windows 10 SDK's folder directories may all have this problem, where the folder directory lookup is hard-coded into only seeking out. 

    Will future Windows 10 SDKs be allowed to let Visual Studio look up where the binaries and executables are, including a lookup in the 10.0.XXXXX.0 folders?

    Monday, April 22, 2019 12:02 PM

All replies

  • The thing is, the C++ build process uses some executables from the Windows SDK directory. If your Direct3D usage is via C++, then you should know these.

    The executables that the C++ build process uses from the Windows SDK directory are MIDL.exe, MT.exe and RC.exe. If you digitally sign your executables then you will find signtool.exe here too. So I am kind of surprised that it finds some critical build tools correctly but others it fails to find.

    As far as I know, Visual Studio should generally use the Windows SDK executable path to find things. The project properties default to:

    Notice how the second component is the $(WindowsSDK_ExecutablePath) macro? For this configuration, this expands to:

    So the version does get taken into account here.

    My suggestion would be

    1) Verify that you are having this problem with your project in Visual Studio 2019 16.0.2 (the latest version at the time of writing) or Visual Studio 2019 Preview (16.1 Preview 1 at the time of writing). This is to check that if this has been found to be a bug, then it could have been fixed.

    2) Create a completely new project. Without touching the project's executable path, try to create a sample that shows this behaviour. It doesn't need to be a full sample, just complete enough to show that Visual Studio fails to find fxc.exe.

    3) If doing all of this shows that Visual Studio fails to find fxc.exe, then through Visual Studio 2019, report it as a bug.

    But I will mention that a naïve test on my end shows that Visual Studio 2019 can compile HLSL shaders without any issues using the 18362, 17763 and 17134 SDKs. These were tested because these are the versions that I have installed.

    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Monday, April 22, 2019 2:50 PM
  • It can compile and build HLSL shaders just fine, and I can see my build output executable. I used a simple Conway's Game of Life compute shader, and can see the Conway's Game of Life being rendered.

    But I'll have to check to make sure whether it is something else that caused the change to the configurations. Thanks for verifying that on your end, Visual Studio can detect the Windows 10 SDK binaries.

    Another thing is, which is something I may need to point out, is my project was originally created in Visual Studio 2017, in which this issue may not be fixed at the time. Now I'm using Visual Studio 2019, it may be possible Visual Studio 2019 is keeping the original Visual Studio 2017 project configurations intact, and didn't reroute the directory lookup properly.

    This is the Stack Overflow question I found that helped me resolve my issue prior to this thread:


    Monday, April 22, 2019 3:06 PM
  • Hello Tom_Befrugal,

    It seems before version 16299, SDK use C:\Program Files (x86)\Windows Kits\10\bin as install path. And from 16299 (maybe from 15063 but I don't install SDK of this version, so I can't check it.) it use C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\ path that with exact version information. I found this because I installed SDK of version 14393 but there is no \Windows Kits\10\bin\10.0.14393.0\ path. And also you can see that Windows 8 and 8.1 have no exact version information in SDK install path.

    I use VS2017 version 15.8.8, it does add right SDK path relate to your target SDK version. When I target 14393 it adds C:\Program Files (x86)\Windows Kits\10\bin\ path while I target 16299 it adds C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\ path as WindowsSDK_ExecutablePath.

    So what's your VS2017 version and SDK target version?

    Best regards,


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, April 23, 2019 4:05 AM
  • Hello Rita,

    I'm already on Visual Studio 2019, uninstalled Visual Studio 2017, and I'm targeting Windows SDK version 10.0.17763.0 at the moment. I can indeed see the $(WindowsSDK_ExecutablePath) is targeting the correct directory for 10.0.17763.0. In fact, in Visual Studio 2019, there's a new macro that would always target the directory with the latest installed build version. I'll need to read up on this macro a bit more.

    With that said, it may be possible that I've just encountered this issue without realizing this, and now, I may need to update all involved project properties page to make sure it is being targeted correctly.

    For the time being, I had the project properties configured so that it is checking the correct SDK directory. Once I get home, I will need to double-verify whether other Visual Studio projects are affected, and I'll update them when necessary.

    Thanks to all for the responses.

    Wednesday, April 24, 2019 6:06 PM