Macro definition clash between directx headers and winerror.h

Question

I'm on windows 7 using Visual Studio 2012.

When I compile I get a lot of macro redefinition warnings caused by winerror.h versus dxgi.h, dxgitype.h, d3d11.h, d3d10.h; for example DXGI_STATUS_OCCLUDED, DXGI_STATUS_CLIPPED, DXGI_STATUS_NO_REDIRECTION etc.

I suppose this is because the windows sdk 8 is installed. How can I avoid this? Is there a way I can exclude these new libraries from my project?

Please share the order of includes. Also why do you want to use d3d10 and d3d11 in the same file include structure ? — Ram, Sep 30 '12 at 16:56
I tried removing everything but d3d11.h, which in turn includes dxgi.h and dxgitype.h — キキジキ, Sep 30 '12 at 17:06
You are mixing headers from different SDK versions. Don't do that. — Hans Passant, Sep 30 '12 at 17:59

score 17 · Answer 1 · answered Oct 15 '12 at 05:42

17

I ran into this issue compiling SlimDX with Visual Studios 2012 on Windows 8. Windows SDK includes are inherited by default so they load after manually defined project include directories. To fix it add the Windows SDK as the first include directory. $(WindowsSDK_IncludePath)

answered Oct 15 '12 at 05:42

gradbot

13,732
5
36
69

Thanks, I was following some much more complex instrutions. These were what I needed! – aPerfectMisterMan Jul 19 '13 at 17:32
Maybe removing references to DirectX SDK is the **right** way to go but this solution is so fast and neat. ^^ – NPS Jan 03 '14 at 01:22

score 13 · Accepted Answer · edited Jun 20 '20 at 09:12

I ran into this problem using Visual Studio 2012 Express on Windows 8; however, my errors were almost exactly the same, and the fix is centered around the Windows SDK. This was in MSDN (see #5):

D3DX is not considered the canonical API for using Direct3D in Windows 8 and therefore isn't included with the corresponding Windows SDK. Investigate alternate solutions for working with the Direct3D API.

For legacy projects, such as the Windows 7 (and earlier) DirectX SDK samples, the following steps are necessary to build applications with D3DX using the DirectX SDK:

a. Modify the project’s VC++ directories as follows to use the right order for SDK headers and libraries.

Open Properties for the project and select the VC++ Directories page.

Select All Configurations and All Platforms.

Set these directories as follows:

Include Directories: $(IncludePath);$(DXSDK_DIR)Include

Library Directories: $(LibraryPath);$(DXSDK_DIR)Lib\x86

Click Apply.

Choose the x64 Platform.

Set the Library Directory as follows:

Library Directories: $(LibraryPath);$(DXSDK_DIR)Lib\x64

b. Wherever "d3dx9.h", "d3dx10.h", or "d3dx11.h" are included in your project, be sure to explicitly include "d3d9.h", "d3d10.h" and "dxgi.h", or "d3d11.h" and "dxgi.h" first to ensure you are picking up the newer version. You can disable warning C4005 if needed; however, this warning indicates you are using the older version of these headers.

c. Remove all references to DXGIType.h in your project. This header doesn't exist in the Windows SDK, and the DirectX SDK version conflicts with the new winerror.h.

d. All D3DX DLLs are installed onto your development computer by the DirectX SDK installation. Ensure that the necessary D3DX dependencies are redistributed with any sample or with your application if it is moved to another machine.

e. Be aware that replacement technologies for current uses of D3DX11 include DirectXTex and DirectXTK. D3DXMath is replaced by DirectXMath.

I can't say for sure, but I think the Windows 8 SDK might be your problem. It may be a bit of a pain, but using the fix above will help make your code require less dependencies as well as making it compatible with both Windows 7 and Windows 8.

Thanks for the extensive answer. Since I switched to windows8 I wrote everything from scratch so I had no problems. Fortunately it was easy to replace d3dx with DirectXTK and FW1FontWrapper. I'll mark this as the accepted answer, it will be useful for people habing the same problems. — キキジキ, Jun 01 '13 at 15:40

Aggrobatics · Answer 3 · 2018-04-12T14:25:53.743

(Yay, my first answer on Stackoverflow)

Found a, hopefully good, workaround to the issue: Make your own header-file, that includes Windows.h (D3D11 includes that anyways), undefines windows macros and includes D3D11.h. Include this header instead of D3D11.h. Note: Obviously this prioritizes D3D11 versions of definition, over those of Windows.h

// D3D11-NoRedefs.h
// Includes D3D11.h without redefinitions from Windows!
#pragma once

#include <Windows.h>

#pragma region Undefine Windows Macros
// Only undefine, if DXGIType.h has not been included yet
    #ifndef __dxgitype_h__
        #undef DXGI_STATUS_OCCLUDED
        #undef DXGI_STATUS_CLIPPED
        #undef DXGI_STATUS_NO_REDIRECTION
        #undef DXGI_STATUS_NO_DESKTOP_ACCESS
        #undef DXGI_STATUS_GRAPHICS_VIDPN_SOURCE_IN_USE
        #undef DXGI_STATUS_MODE_CHANGED
        #undef DXGI_STATUS_MODE_CHANGE_IN_PROGRESS
        #undef DXGI_ERROR_INVALID_CALL
        #undef DXGI_ERROR_NOT_FOUND
        #undef DXGI_ERROR_MORE_DATA
        #undef DXGI_ERROR_UNSUPPORTED
        #undef DXGI_ERROR_DEVICE_REMOVED
        #undef DXGI_ERROR_DEVICE_HUNG
        #undef DXGI_ERROR_DEVICE_RESET
        #undef DXGI_ERROR_WAS_STILL_DRAWING
        #undef DXGI_ERROR_FRAME_STATISTICS_DISJOINT
        #undef DXGI_ERROR_GRAPHICS_VIDPN_SOURCE_IN_USE
        #undef DXGI_ERROR_DRIVER_INTERNAL_ERROR
        #undef DXGI_ERROR_NONEXCLUSIVE
        #undef DXGI_ERROR_NOT_CURRENTLY_AVAILABLE
        #undef DXGI_ERROR_REMOTE_CLIENT_DISCONNECTED
        #undef DXGI_ERROR_REMOTE_OUTOFMEMORY
        #undef D3D11_ERROR_TOO_MANY_UNIQUE_STATE_OBJECTS
        #undef D3D11_ERROR_FILE_NOT_FOUND
        #undef D3D11_ERROR_TOO_MANY_UNIQUE_VIEW_OBJECTS
        #undef D3D11_ERROR_DEFERRED_CONTEXT_MAP_WITHOUT_INITIAL_DISCARD
        #undef D3D10_ERROR_TOO_MANY_UNIQUE_STATE_OBJECTS
        #undef D3D10_ERROR_FILE_NOT_FOUND
    #endif
#pragma endregion

#include <D3D11.h>

Please let me know what you think, and do not hold back on criticism. I am new to this and know that this is quite brute force and probably risky.

just a typo: if you comment out the `#pragma region Undefine Windows Macros` line, you should also comment out the `#pragma endregion` line. Or remove the `//` from the first pragma.. — Michael, Apr 11 '18 at 11:31
Thanks @Michael. The #pragma region has been uncommented. For any user of an IDE other than Visual Studio: please bear in mind that #pragma region is a VS-command and may try to compile as code in other IDEs. It's just a command used to collapse chunks of code and help with structure — Aggrobatics, Apr 12 '18 at 14:26

score 0 · Answer 4 · answered Oct 02 '12 at 15:21

I changed the settings and included the directx from inside Windows Kits\8.0 .

Actually I wanted instead to ignore it and use the windows headers and libraries I used before, but maybe it doesn't make a lot of difference.

The only thing is that now I have no longer access to the d3dx utilities.

score 0 · Answer 5 · answered Oct 16 '15 at 14:06

Another quick-fix - quick, as in 'probably not the best long-term solution' - is to change the "platform toolset" under Solution/Properties/General - in my specific case I selected "Visual Studio 2015 - Windows XP (v140_xp)" instead of "Visual Studio 2015 (v140)".

score 0 · Answer 6 · answered Feb 20 '20 at 01:39

0

Winerror.h includes DXGIType.h and Visual Studio found the DirectX SDK DXGIType.h instead of the Windows SDK one.

Following user2400203's answer, and renaming C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include\DXGIType.h worked for me.

answered Feb 20 '20 at 01:39

Tom Huntington

2,260
10
20

Macro definition clash between directx headers and winerror.h

6 Answers6

Linked