This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(150.4, 75%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBT%3C/text%3E%3C/svg%3E)
I am building a x64 project, i am using
#pragma comment(linker,"/manifestdependency:"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'"") for using InitCommonControlsEx(&InitCtrls)
After the build , when i check the exe using dependencies walker ,I see only commctl32 is loaded as 32- bit, which probably is causing the exe application to fail with error 0xC000007B.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(201.6, 57.00000000000001%, 29%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMY%3C/text%3E%3C/svg%3E)
If you create a new MFC dialog project, will the error occur? Dialog project framework file uses
#ifdef _UNICODE
#if defined _M_IX86
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"")
#elif defined _M_X64
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"")
#else
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
#endif
#endif
Is there any update?
@Bevan Thomas, we haven't heard from you in a while. Is there anything new with this issue?
,I see only commctl32
Guess, why it's named commctl32, because it is 32 bit and before you ask: No 64 bit avaible, even because the libary is more the 100 hundred years old.
I got an error like this
"A component version required by the application conflicts with another component version already active. Conflicting components are:. Component 1: C:\Windows\WinSxS\manifests\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.4355_none_60b8b9eb71f62e16.manifest. Component 2: C:\Windows\WinSxS\manifests\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.4355_none_a865f0c28672571c.manifest."
So, i am thinking it exists for both, also i checked winsxs folder there were two folder for commctl32 one amd64 and other x86
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(262.40000000000003, 13%, 35%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDR%3C/text%3E%3C/svg%3E)
Much like the 64 bit system directory is C:\Windows\System32? (Assuming that Windows is installed on C).
No, the 32 is a hold over from when there was a need to distinguish between 16 bit and 32 bit libraries. The names ended up sticking due to ease of portability. The commctl32.dll in System32 is matches the system architecture, so x64 on x64 versions of Windows, ARM64X on Arm64 versions of Windows and x86 on x86 versions of Windows.
The versions in the SxS directories match the platform spelled out in the directory name and manifest. So yes, commctl32.dll v6 on x64 systems have an x64 version.
@Olaf Helper I got this error,
"A component version required by the application conflicts with another component version already active. Conflicting components are:. Component 1: C:\Windows\WinSxS\manifests\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.4355_none_60b8b9eb71f62e16.manifest. Component 2: C:\Windows\WinSxS\manifests\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.4355_none_a865f0c28672571c.manifest."
So, I am thinking there exist both versions.Also, I checked WinSxs folder. I found two folders containing the commctl32 one amd64 and other x86.
What happens if you change the #pragma directive to use processorArchitechture='*" ? And to avoid confusion the correct name for the common controls DLL is comctl32.dll (only 1 'm').
@RLWA32 Same, i tried with * this too
Can you give us more information about your project?
By specifying processorArchitecture='*' the system should create an activation context that loads the version of comctl32 that matches the bitness of your process. Since the 0xC000007B error continues to manifest it seems to me that your problem may be unrelated to comctl32.dll. The output of the dependencies walker utility may be a red herring.
LdrpProcessWork - ERROR: Unable to load DLL: "C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.4355_none_a865f0c28672571c\COMCTL32.dll", Parent Module: "C:\Windows\System32\COMDLG32.dll", Status: 0xc000007b
Getting this error
Parent Module: "C:\Windows\System32\COMDLG32.dll", Status: 0xc000007b
There is an apparent mismatch between the bitness of your process and the dlls it is attempting to load.
Something is wrong with how your project is configured/building. Can you share a demo that reproduces the problem?
By any chance are you using a 32-bit version of Windows?
Trying to start a 64-bit executable on 32-bit Windows produces a different error.
Hi @RLWA32 ,Sorry for the late reply. I was able to find the issue using gflags .So, basically the comctl dll was not present in winsxs folder , I reinstalled visual studio redistributable(x86) and then it was working fine.
I was able to find the issue using gflags . I reinstalled visual studio redistributable(x86) and then it was working fine.
It seems you were not actually building a 64-bit executable if re-installing the 32-bit redistributable resolved the problem. However, I find this a bit confusing since the common controls library (comctl32.dll) is a system dll and the related SXS versions are also system files.
Anyway, I have changed my comment suggesting that you use gflags to an Answer that you can accept to close the issue.
I suggest you use gflags.exe to show loader snaps for your application. This should be done on the "Image File" tab. See my answer to this question - https://zcusa.951200.xyz/en-us/answers/questions/1359836/using-gflags-show-loader-snaps-with-visual-studio
After you have done this run your application under the Visual Studio debugger and examine the messages in the Output pane. I think they will help you identify the problem.